[brianclements]

Technically, this might be syntax, but as someone who is learning Racket (and programming) in the beginning stages, it's so much less syntax to remember then even python (underscore, double underscore, with, decorators, list comprehensions etc all have their own syntax nuances), the only syntax I see in Racket is the s-expression, the quote, and the dots. Everything else is just the flow of programming logic. It really does free my mind to work on the problem domain itself! Been enjoying SICP so much.

[Avshalom]

Racket doesn't get quite as bad (well it does but it tries to keep things looking like S-exps) but consider CL's Loop macro http://www.unixuser.org/~euske/doc/cl/loop.html loop is (from what I understand) idiomatic too. Yes it's a macro (so is (defun ...) though) but it's syntax a CLer needs to know in order to deal with CL in the wild. Format is famously even worse.

[adwf]

A lot of people abandon loop for precisely that reason (it's un-lispy) and use Iterate.

https://common-lisp.net/project/iterate/

Even the ITA/Google style guide says to avoid loop if possible:

https://google.github.io/styleguide/lispguide.xml#Iteration

[lispm]

But the ITERATE macro is syntax, too.

Almost every macro in Lisp provides syntax.

[adwf]

Yes, but I thought his point was more that whilst Lisp has a very easy, simple and regular syntax, ie. (func arg1 arg2 (func arg3)) and so on, it's less simple and regular when you get to the loop macro (loop arg keyword arg keyword...). Hence why I mentioned the Iterate library as something a lot of people use to get back to the regular syntactical appearance.

It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.

[lispm]

    (func arg1 arg2 (func arg3))

That's the syntax of function calls.

But Lisp has a few special forms and zillions of macros. Most of them are syntax.

Lisp has IF. What is the syntax of IF?

    IF form then-form else-form+

Lisp has COND. What is the syntax of COND?

    cond {clause}*
    clause::= (test-form form*) 
 

List has DEFUN. What is the syntax of DEFUN?

    defun function-name lambda-list [[declaration* | documentation]] form*

Now what is the syntax for LAMBDA-LIST?

    lambda-list::= (var* 
                    [&optional {var | (var [init-form [supplied-p-parameter]])}*] 
                    [&rest var] 
                    [&key {var | ({var | (keyword-name var)} [init-form [supplied-p-parameter]])}* [&allow-other-keys]] 
                    [&aux {var | (var [init-form])}*]) 

and so on...

> It's one of the strengths of Lisp imo; that you don't need to think much about how the parser is going to interpret your code (ie. missing semi-colons, whitespace, use curly brace here, square bracket there, etc.), just stick to (func arg1 arg2) and all you're left with is your own logic errors.

What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.

[adwf]

> What you describe is just the data syntax for s-expressions. Not the syntax of the programming language Lisp.

Exactly. The data syntax if what most people worry about. The names of the verbs (funcs/methods/etc.) may change from language to language, but the data syntax is what trips people up. I think Lisp has one of the simplest and clearest. There are very few cases of "oh you can't write that there, only nouns are allowed in that position".

I agree with your point, but I think we're arguing slightly different points here ;)

[breuleux]

It's debatable whether "simple and regular syntax" is a strength or a weakness. Lisp/Scheme might be too regular for their own good. Consider the following statements in Scheme, for instance:

    (lambda x (+ x x))
    (cond (> x 2) (+ x x))
    (if (> x 2)
        (do-this when-true)
        (also-do-this when-true))

They are syntactically correct (technically), but they are probably not what you meant. So you still have to pause and ask yourself how cond works... except the parser will not help you.

That is to say, a problem with s-expressions is that they are so regular that everything looks the same, and when everything looks the same, it can become an obstacle to learning. Mainstream languages are not very regular, but they are more mnemonic. I think Lisp works best for a very particular kind of mind, but that for most programmers its strengths are basically weaknesses.

[lispm]

    (if (> x 2)
        (do-this when-true)
      (also-do-this when-true))

In some other language:

    x > 2 ? doThis(whenTrue) : alsoDoThisWhenTrue();

Same problem. Maybe even slightly worse. For example it could be:

    x > 2 ? doThis(whenTrue) ; alsoDoThisWhenTrue();

To spot the difference between a colon and the semicolon: tough.

[aidenn0]

SBCL will warn or error at compile time on the first two, and there are similar issues to the third one in many languages; it's a semantics issue more than a syntactic issue.

[aidenn0]

An equivalent to iterate/loop where each compound form need be replaced by an anonymous function and each binding is replaced by a dictionary entry could be implemented completely as a function. Is this also new syntax?

If not, how is the macro different other than implicitly changing the evaluation?

for a more simple example, why is the idiom CALL-WITH-FOO (implemented as a function) not syntax while WITH-FOO (implemented as a macro) is? What precisely is syntax is somewhat nebulous (if I use a regex library in C, have I added syntax to the language? Regexes certainly are syntax, despite being wrapped in a C string).

[baldfat]

Even Racket says loops are unRacket like and so does R. I avoid loops at all cost and use list whenever possible.

[aidenn0]

Loop is idiomatic, but whether or not it is syntax is arguable, as it is implemented entirely as a macro.