[eadmund]

> It's not the parens persay, it's the fact that I'm used to reading up to down and left to right. Lisp without something like the clojure macro ->, means that I am reading from right to left, bottom to top - from inside out.

I’m not certain how true that really is. This:

    foo(bar(x), quux(y), z);

looks pretty much identical to:

    (foo (bar x) (quux y) z)

And of course if you want to assign them all to variables:

    int bar_x = bar(x);
    char quux_y = quux(y);
    
    return foo(bar_x, quux_y, z);

is pretty much the same as:

    (let ((bar-x (bar x))
          (quux-y (quux y)))
      (foo bar-x quux-y z))

FWIW, ‘per se’ comes from the Latin for ‘by itself.’

[AdieuToLogic]

One of the awesome things about LISP is it encourages a developer to think of programs as an AST[0].

One of the things that sucks about LISP is - master it and every programming language is nothing more than an AST[0].

:-D

0 - https://en.wikipedia.org/wiki/Abstract_syntax_tree

[almostgotcaught]

> encourages a developer to think of programs as an AST

can you imagine saying something like

> The fradlis language encourages your average reader to think of essays as syntax [instead of content].

and thinking it reflects well on the language................

[AdieuToLogic]

  can you imagine saying something like

  > The fradlis language encourages your average reader
  to think of essays as syntax [instead of content].

  and thinking it reflects well on the language

A reciprocating saw[0] is a great tool to have. It can be used to manipulate drywall, cut holes in various material, and generally allow "freehand cutting."

But it is not the right tool for making measured, repeatable, cuts. It is not the right tool for making perfect right-angle cuts, such as what is needed for framing walls.

In other words, use the right tool for the job.

If a problem is not best expressed with an AST mindset, LISP might not be the right tool for that job. But this is a statement about the job, not about the tool.

0 - https://en.wikipedia.org/wiki/Reciprocating_saw

[fc417fc802]

I think an alternative to paragraphs or some other organizational unit would be a more appropriate analogy.

The AST aspect of Lisps is absolutely an advantage. It obviates the need for the vast majority of syntax and enables very easy metaprogramming.

[all2]

The lisp is harder to read, for me. The first double paren is confusing.

    (let (bar-x (bar x))
         (quux-y (quux y)))
    (foo bar-x quux-y z)

Why is the second set of parens necessary?

The nesting makes sense to an interpreter, I'm sure, but it doesn't make sense to me.

Is each top-level set of parens a 'statement' that executes? Or does everything have to be embedded in a single list?

This is all semantics, but for my python-addled brain these are the things I get stuck on.

[kazinator]

The let construct in Common Lisp and Scheme supports imperative programming, meaning that you have this:

  (let variable-bindings statment1 statement2 ... statementN)

If statementN is reached and evaluates to completion, then its value(s) will be the result value(s) of let.

The variable-bindings occupy one argument position in let. This argument position has to be a list, so we can have multiple variables:

  (let (...) ...)

Within the list we have about two design choices: just interleave the variables and their initializing expressions:

  (let (var1 value1
        var2 value2
        var3 value3)
    ...)

Or pair them together:

  (let ((var1 value1)
        (var2 value2)
        (var3 value3)
    ...)

There is some value in pairing them together in that if something is missing, you know what. Like where is the error here?

  (let (a b c d e) ...)

we can't tell at a glance which variable is missing its initializer.

Another aspect to this is that Common Lisp allows a variable binding to be expressed in three ways:

  var
  (var)
  (var init-form)

For instance

  (let (i j k (l) (m 9)) ...)

binds i, j and k to an initial value of nil, and m to 9.

Interleaved vars and initforms would make initforms mandatory. Which is not a bad thing.

Now suppose we have a form of let which evaluates only one expression (let variable-bindings expr), which is mandatory. Then there is no ambiguity; we know that the last item is the expr, and everything before that is variables. We can contemplate the following syntax:

  (let a 2 b 3 (+ a b)) -> 5

This is doable with a macro. If you would prefer to write your Lisp code like this, you can have that today and never look back. (Just don't call it let; pick another name like le!)

If I have to work with your code, I will grok that instantly and not have any problems.

In the wild, I've seen a let1 macro which binds one variable:

  (let1 var init-form statement1 statement2 ... statementn)

[MayeulC]

I am not a Lisp expert by any stretch, but let's clarify a few things:

1. Just for the sake of other readers, we agree that the code you quoted does not compile, right?

2. `let` is analogous to a scope in other languages (an extra set of {} in C), I like using it to keep my variables in the local scope.

3. `let` is structured much like other function calls. Here the first argument is a list of assignments, hence the first double parenthesis (you can declare without assigning,in which case the double parenthesis disappears since it's a list of variables, or `(variable value)` pairs).

4. The rest of the `let` arguments can be seen as the body of the scope, you can put any number of statements there. Usually these are function calls, so (func args) and it is parenthesis time again.

I get that the parenthesis can get confusing, especially at first. One adjusts quickly though, using proper indentation helps.

I mostly know lisp trough guix, and... SKILL, which is a proprietary derivative from Cadence, they added a few things like inline math, SI suffixes (I like that one), and... C "calling convention", which I just find weird: the compiler interprets foo(something) as (foo something). As I understand it, this just moves the opening parenthesis before the preceding word prior to evaluation, if there is no space before it.

I don't particularly like it, as that messes with my C instincts, respectively when it comes to spotting the scope. I find the syntax more convoluted with it, so harder to parse (not everything is a function, so parenthesis placement becomes arbitrary):

    let( (bar-x(bar(x))
         quux-y(quux(y)))
    foo(bar-x quux-y z)
    )

[jasbrg]

> Why is the second set of parens necessary?

it distinguishes the bindings from the body.

strictly speaking there's a more direct translation using `setq` which is more analogous to variable assignment in C/Python than the `let` binding, but `let` is idiomatic in lisps and closures in C/Python aren't really distinguished from functions.

[eadmund]

You’re right!

    (let (bar-x quux-y)
      (setq bar-x (bar-x)
            quux-y (quux y))
      (foo bar-x quux-y z))

I just wouldn’t normally write it that way.

[krferriter]

The code is written the same way it is logically structured. `let` takes 1+ arguments: a set of symbol bindings to values, and 0 or more additional statements which can use those symbols. In the example you are replying to, `bar-x` and `quux-y` are symbols whose values are set to the result of `(bar x)` and `(quux y)`. After the binding statement, additional statements can follow. If the bindings aren't kept together in a `[]` or `()` you can't tell them apart from the code within the `let`.

[Koshkin]

I prefer that to this (valid) C++ syntax:

  [](){}

[int_19h]

You'd never actually write that, though. An empty lambda would be more concisely written as []{}, although even that is a rare case in real world code.

[all2]

This reminds me of the terror that is the underbelly of JS.

https://jsfuck.com/

[kibwen]

The tragedy of Lisp is that postfix-esque method notation just plain looks better, especially for people with the expectation of reading left-to-right.

    let bar_x = x.bar()
    let quux_y = y.quux()
    return (bar_x, quux_y, z).foo()

[wk_end]

Looks better is subjective, but it has its advantages both for actual autocomplete - as soon as I hit the dot key my IDE can tell me the useful operations for the obejct - and also for "mental autocomplete" - I know exactly where to look to find useful operations on the particular object because they're organized "underneath" it in the conceptual hierarchy. In Lisps (or other languages/codebases that aren't structured in a non-OOP-ish way) this is often a pain point for me, especially when I'm first trying to make my way into some code/library.

As a bit of a digression:

The ML languages, as with most things, get this (mostly) right, in that by convention types are encapsulated in modules that know how to operate on them - although I can't help but think there ought to be more than convention enforcing that, at the language level.

There is the problem that it's unclear - if you can Frobnicate a Foo and a Baz together to make a Bar, is that an operation on Foos, on Bazes, or on Bars? Or maybe you want a separate Frobnicator to do it? (Pure) OOP languages force you to make an arbitrary choice, Lisp and co. just kind of shrug, the ML languages let you take your take your pick, for better or worse.

[CyberDildonics]

It's not really subjective because people have had the opportunity to program in the nested 'read from the inside out' style of lisp for 50 years and almost no one does it.

[no_wizard]

I think the cost of Lisp machines was the determining factor. Had it been ported to more operating systems earlier history could be different right now.

[CyberDildonics]

That was 40 years ago. If people wanted to program inside out with lots of nesting then unfold it in their head, they would have done it at some point a long time ago. It just isn't how people want to work.

People don't work in postfix notation either, even though it would be more direct to parse. What people feel is clearer is much more important.

[int_19h]

It's not just Lisp, though. The prefix syntax was the original one when the concept of records/structs were first introduced in ALGOL-like languages - i.e. you'd have something like `name(manager(employee))` or `name OF manager OF employee`. Dot-syntax was introduced shortly after and very quickly won over.

[tmtvl]

De gustibus non disputandum est, I personally find the C++/Java/Rust/... style postfix notation (foo.bar()) to be appalling.

[kazinator]

TXR Lisp has this notation, combined with Lisp parethesis placement.

Tather than obj.f(a, b). we have obj.(f a b).

  1> (defstruct dog ()
       (:method bark (self) (put-line "Woof!")))
  #<struct-type dog>
  2> (let ((d (new dog)))
       d.(bark))
  Woof!
  t

The dot notation is more restricted than in mainstream languages, and has a strict correspondence to underlying Lisp syntax, with read-print consistency.

  3> '(qref a b c (d) e f)
  a.b.c.(d).e.f

Cannot have a number in there; that won't go to dot notation:

  4> '(qref a b 3 (d) e f)
  (qref a b 3 (d)
    e f)

Chains of dot method calls work, by the way:

  1> (defstruct circular ()
       val
       (:method next (self) self))
  #<struct-type circular>
  2> (new circular val 42)
  #S(circular val 42)
  3> *2.(next).(next).(next).(next).val
  42

There must not be whitespace around the dot, though; you simply canot split this across lines. In other words:

   *2.(next)
   .(next) ;; nope!
   .(next) ;; what did I say?

The "null safe" dot is .? The following check obj for nil; if so, they yield nil rather than trying to access the object or call a method:

  obj.?slot
  obj.?(method arg ...)

[ssivark]

And what about when `bar` takes several inputs? Postfix seems like an ugly hack that hyper-fixates on functions of a single argument to the detriment of everything else.

[int_19h]

It's not like postfix replaces everything else. You can still do foo(bar, baz) where that makes the most sense.

However, experience shows that functions having one "special" argument that basically corresponds to grammatical subject in natural languages is such a common case that it makes sense for PLs to have syntactic sugar for it.

[kibwen]

Look at the last line in the example, where I show a method being called on a tuple. Postfix syntax isn't limited to methods that take a single argument.