News for hackers. Stuff that matters.
Re:A different take on S-expressions by somewhereoutth on Wednesday June 18, 2025 @02:38PM (#44312277)
dispense with the parentheses:

  (eq (mul (a a)) (pow (a 2)))
becomes

  eq
    mul
      a a
    pow
      a 2
Re:A different take on S-expressions by danielrico on Wednesday June 18, 2025 @03:41PM (#44312742)
Lispython

I should trademark this name.

Re:A different take on S-expressions by tmtvl on Wednesday June 18, 2025 @04:38PM (#44313097)
That's Wisp, I don't care for it, but people who really like to assign semantic meaning to precise counts of invisible characters may find it interesting.
Re:A different take on S-expressions by derriz on Wednesday June 18, 2025 @05:11PM (#44313307)
Absolutely no counting is required at all so I think your joke falls a little flat.

Our visual system has the ability to detect implied straight lines (and other simple geometric outlines) from very small clues.

Therefore "seeing" the vertical lines implied by the indentation is effortless - so it's immediately obvious which elements belong to each other.

Indentation is an incredibly valuable "brain" hack that manages to instantly communicate hierarchy, not something to be sneered at.

We have no such innate ability to match parenthesis - determining hierarchy in a jumble of open and close parenthesis requires precise counting or, typically these days, tool/editor/IDE support.

Re:A different take on S-expressions by XorNot on Wednesday June 18, 2025 @06:39PM (#44313891)
I also don't know why this is treated as controversial either: the first thing every project does is declare a canonical code formatting aka whitespace layout and start rejecting patches which don't follow it.
Re:A different take on S-expressions by thaumasiotes on Wednesday June 18, 2025 @06:19PM (#44313756)
> Absolutely no counting is required at all so I think your joke falls a little flat.

Really? How do you see the difference between "TAB" and "SPACE SPACE TAB"?

Re:A different take on S-expressions by xigoi on Wednesday June 18, 2025 @06:50PM (#44313952)
The solution to that is easy: do not use tabs.
Re:A different take on S-expressions by thaumasiotes on Wednesday June 18, 2025 @10:20PM (#44314868)
That is not the approach taken by any system that I know of that uses semantic whitespace. Tabs are meaningful in Python and make, and in fact required in make.
Re:A different take on S-expressions by xigoi on Thursday June 19, 2025 @03:34AM (#44316367)
Haskell and Nim are both indentation-sensitive languages that only allow spaces as indentation.
Re:A different take on S-expressions by derriz on Thursday June 19, 2025 @09:05AM (#44318345)
That’s a design flaw of ASCII inherited by UNICODE not an argument against using indentation to portray hierarchy. I’m sure there are alternative UNICODE characters which render almost indistinguishable from “(“ also.
Re:A different take on S-expressions by agumonkey on Wednesday June 18, 2025 @05:14PM (#44313332)
there's a hybrid form (sweet-expressions ? i forgot), top-level terms are parens-free

    eq (mul a a)
       (pow a 2)

    defun min (a b)
      (if (a < b) a b)

IIRC the hack to support this at read time was minimal, and it made a big impact in terms of "mainstream appeal"
Re:A different take on S-expressions by em-bee on Wednesday June 18, 2025 @08:32PM (#44314420)
the elvish shell uses the syntax in the first example:

    > eq (* 3 3) (math:pow 3 2)
    ▶ $true
(function definitions on the other hand uses smalltalk/ruby style blocks)
Re:A different take on S-expressions by marcosdumay on Wednesday June 18, 2025 @09:41PM (#44314713)
IMO, make some syntax element that means "each line indented from this one has one single element, unless indented further".

    eq :
        mul a a
        pow a 2

    defun min (a b) :
        if (< a b) a b
That means you can also have haskell-like continuations:

    seq :
        eq (mul a a)
            (pow a 2)
        eq 4 3