3 ms·
Cool idea with splitting function arguments into separate lines. It's a bit verbose, but avoids some of Python's old problems regarding what to do about inline
by 60654 7y ago
Cool idea with splitting function arguments into separate lines. It's a bit verbose, but avoids some of Python's old problems regarding what to do about inline lambdas.
But on the down side, now macros have to do string formatting (like adding indents and newlines) to produce output that is legible code, for example the "when" macro:
defmacro when input
fn blocks
ap "if"
++ z:indent-before 3
car blocks
++ "\n"
++ z:indent 3
car cdr blocks
++ "\n"
z:indent 3
"unit"
z:blocks input
That's one place where all languages that replace s-expressions with indentation seem to stumble equally: nested parens may look funny, but metaprogramming in lisps is delightfully easy because everything is a list and whitespace doesn't matter, so it's easy to produce and consume at compile time.
- nonsince 7y agoThis isn't a problem with the syntax, you could just have macros consume and produce lists and avoid this entirely. In fact, there already exist reader macros that implement pretty much exactly this syntax but for Lisp: https://docs.racket-lang.org/sweet/index.html https://docs.racket-lang.org/sweet/index.html
- 60654 7y agoRight, so you need to support mixing some lists in, to complement meaningful whitespace, the way sweet-expressions or SRFI-49 do. But that's exactly because the consequences of "whitespace only" syntax are too severe.