5 ms·

Since Lisp has been around since 1960... Congratulations, you're only about 64 years late.

practal 2y ago
No doubt, brackets of course also convey structure. But I think indentation is better for visualising block structure. Inside these blocks, you can still use brackets, and errors like missing opening or closing brackets will not spill over into other blocks. And yeah, I am definitely coming for Lisp.
- llm_trw 2y ago
  I wrote a racket function that would need 35 levels of indentation ten minutes ago. White space isn't coming for lisps until we figure out 12 dimensional displays.
  - cjfd 2y ago
    Is a function that would need 35 levels of indentation a good idea? I have seen C code with about 12 levels of indentation and that was not too great.
    - llm_trw 2y ago
      What other languages use syntax for lisps use function applications for. Viz. the array reference a[0] in algols is a function application in lisps (vector-ref a 0). The same is true for everything else. Semantic white space in such a language is a terrible idea as everyone eventually finds out.
      - practal 2y ago
        Recursive teXt (RX) would be a great fit for Lisp, although I am more interested in replacing Lisp entirely with a simpler language rooted in abstraction logic. Note that RX is not like normal semantic white space, but simpler. It is hard coded into the text without taking its content into consideration. RX is basically nested records of text, making it very robust, but encoded as plain text instead of JSON or something like that.
        llm_trw 2y ago
        No it won't be. S-expressions are the simplest way to linearize a tree. Everyone thinks there's something better and the very motivated write an interpreter for their ideal language in lisp. The ideas inevitably have so much jank when used in anger that you always come back to sexp. Now if you discover a way to linearize dags or arbitrary graphs without having to keep a table of symbols I'd love to hear it.
        practal 2y ago
        > S-expressions are the simplest way to linearize a tree. S-expressions are one way to linearize a tree. Now, "simple" can mean different things depending on what you are trying to achieve. RX is simpler than s-expressions if you prefer indentation over brackets, and like the robustness that it brings. Abstraction algebra terms are simpler than s-expressions if you want to actually reason about and with them.
        llm_trw 2y ago
        In your own examples you're using both brackets and white space to delineate structure. This is complex because you need two parsers to even start working on the input stream and the full parser must know how to switch between them. In short: I get all the pain of semantic white space with all the pain of lisp s-exp's with the benefits of neither.
        kazinator 2y ago
        If you don't allow the indentation based parsing to be nested within a bracket-based expression, it doesn't look too bad. At the top level you have the indentation-based parser. When that sees an open bracket, it recurses to the regular parser which doesn't care about indentation.
        llm_trw 2y ago
        This works until you start using macros.
      - benatkin 2y ago
        An everyday example is the difference between JSON.stringify(data, null, 2) and a pretty printer like ipython or Deno.inspect. Having only one node per line reduces the amount of data that can be displayed. It's the same with code.
  - practal 2y ago
    Assuming this number of indentation is really necessary (which I doubt; maybe a few auxiliary definitions are in order?), obviously only the first few levels would be represented as their own Recursive teXt blocks.
    - llm_trw 2y ago
      >obviously only the first few levels would be represented as their own Recursive teXt blocks. This is not at all obvious.
      - practal 2y ago
        It is obvious to me, nobody would want to represent 35 levels of nesting by indentation. So I would represent the first few (2-4) levels in RX, and the rest by other means, such as brackets. Your language should be designed such that the cutoff is up to you, the writer of the code, and really just a matter of syntax, not semantics. Obviously, I (usually) would not want to write things like + * a b * c d but rather + a * b c * d or, even better of course, (a * b) + (c * d) I think of blocks more as representing high-level structure, while brackets are there for low-level and fine-grained structure. As the border between these can be fluid, where you choose the cutoff will depend on the situation and also be fluid.
        llm_trw 2y ago
        >Your language should be designed such that the cutoff is up to you, the writer of the code, and really just a matter of syntax, not semantics. I have more important things to think about in my code than when I switch between two dialects of the language. Especially since I get no extra expressive power by doing so. >Obviously, I (usually) would not want to write things like Or just use (+ (* a b) (* c d)) which is simpler that any of the example above. Then I can chose between any of: ( + (* a b) (* c d)) ( + ( * a b ) ( * c d ) ) Or whatever else you want to do. >As the border between these can be fluid, where you choose the cutoff will depend on the situation and also be fluid. It's only fluid because you've had XX years of infix notation caused brain damage to make you think that.
  - shakna 2y ago
    Wisp [0] is the big one talked about in Scheme land, and it wouldn't need 35 levels of indentation. Like the rest of Lisp-world, there's flexibility where you need it. For example, this shows a bit of the mix available: for-each λ : task if : and (equal? task "help") (not (null? (delete "help" tasks))) map λ : x help #f #f x delete "help" tasks run-task task . tasks [0] https://srfi.schemers.org/srfi-119/srfi-119.html https://srfi.schemers.org/srfi-119/srfi-119.html
- computably 2y ago
  > But I think indentation is better for visualising block structure. Which is irrelevant, because you can visualize code however you want via editor extensions. > And yeah, I am definitely coming for Lisp. An endeavor which is simultaneously hopeless and pointless.
  - practal 2y ago
    > Which is irrelevant, because you can visualize code however you want via editor extensions. Semantically, of course this does not matter. A block is a block, no matter if delineated by indentation or brackets. But RX looks better as plain text, and there is much less of a disconnect between RX as plain text, and RX as presented in a special editor (extension) for RX, than there would be for Lisp. > An endeavor which is simultaneously hopeless and pointless. Challenge accepted.

No doubt, brackets of course also convey structure. But I think indentation is better for visualising block structure. Inside these blocks, you can still use brackets, and errors like missing opening or closing brackets will not spill over into other blocks. And yeah, I am definitely coming for Lisp.

llm_trw 2y ago
I wrote a racket function that would need 35 levels of indentation ten minutes ago. White space isn't coming for lisps until we figure out 12 dimensional displays.
- cjfd 2y ago
  Is a function that would need 35 levels of indentation a good idea? I have seen C code with about 12 levels of indentation and that was not too great.
  - llm_trw 2y ago
    What other languages use syntax for lisps use function applications for. Viz. the array reference a[0] in algols is a function application in lisps (vector-ref a 0). The same is true for everything else. Semantic white space in such a language is a terrible idea as everyone eventually finds out.
    - practal 2y ago
      Recursive teXt (RX) would be a great fit for Lisp, although I am more interested in replacing Lisp entirely with a simpler language rooted in abstraction logic. Note that RX is not like normal semantic white space, but simpler. It is hard coded into the text without taking its content into consideration. RX is basically nested records of text, making it very robust, but encoded as plain text instead of JSON or something like that.
      - llm_trw 2y ago
        No it won't be. S-expressions are the simplest way to linearize a tree. Everyone thinks there's something better and the very motivated write an interpreter for their ideal language in lisp. The ideas inevitably have so much jank when used in anger that you always come back to sexp. Now if you discover a way to linearize dags or arbitrary graphs without having to keep a table of symbols I'd love to hear it.
        practal 2y ago
        > S-expressions are the simplest way to linearize a tree. S-expressions are one way to linearize a tree. Now, "simple" can mean different things depending on what you are trying to achieve. RX is simpler than s-expressions if you prefer indentation over brackets, and like the robustness that it brings. Abstraction algebra terms are simpler than s-expressions if you want to actually reason about and with them.
        llm_trw 2y ago
        In your own examples you're using both brackets and white space to delineate structure. This is complex because you need two parsers to even start working on the input stream and the full parser must know how to switch between them. In short: I get all the pain of semantic white space with all the pain of lisp s-exp's with the benefits of neither.
        kazinator 2y ago
        If you don't allow the indentation based parsing to be nested within a bracket-based expression, it doesn't look too bad. At the top level you have the indentation-based parser. When that sees an open bracket, it recurses to the regular parser which doesn't care about indentation.
        llm_trw 2y ago
        This works until you start using macros.
    - benatkin 2y ago
      An everyday example is the difference between JSON.stringify(data, null, 2) and a pretty printer like ipython or Deno.inspect. Having only one node per line reduces the amount of data that can be displayed. It's the same with code.
- practal 2y ago
  Assuming this number of indentation is really necessary (which I doubt; maybe a few auxiliary definitions are in order?), obviously only the first few levels would be represented as their own Recursive teXt blocks.
  - llm_trw 2y ago
    >obviously only the first few levels would be represented as their own Recursive teXt blocks. This is not at all obvious.
    - practal 2y ago
      It is obvious to me, nobody would want to represent 35 levels of nesting by indentation. So I would represent the first few (2-4) levels in RX, and the rest by other means, such as brackets. Your language should be designed such that the cutoff is up to you, the writer of the code, and really just a matter of syntax, not semantics. Obviously, I (usually) would not want to write things like + * a b * c d but rather + a * b c * d or, even better of course, (a * b) + (c * d) I think of blocks more as representing high-level structure, while brackets are there for low-level and fine-grained structure. As the border between these can be fluid, where you choose the cutoff will depend on the situation and also be fluid.
      - llm_trw 2y ago
        >Your language should be designed such that the cutoff is up to you, the writer of the code, and really just a matter of syntax, not semantics. I have more important things to think about in my code than when I switch between two dialects of the language. Especially since I get no extra expressive power by doing so. >Obviously, I (usually) would not want to write things like Or just use (+ (* a b) (* c d)) which is simpler that any of the example above. Then I can chose between any of: ( + (* a b) (* c d)) ( + ( * a b ) ( * c d ) ) Or whatever else you want to do. >As the border between these can be fluid, where you choose the cutoff will depend on the situation and also be fluid. It's only fluid because you've had XX years of infix notation caused brain damage to make you think that.
- shakna 2y ago
  Wisp [0] is the big one talked about in Scheme land, and it wouldn't need 35 levels of indentation. Like the rest of Lisp-world, there's flexibility where you need it. For example, this shows a bit of the mix available: for-each λ : task if : and (equal? task "help") (not (null? (delete "help" tasks))) map λ : x help #f #f x delete "help" tasks run-task task . tasks [0] https://srfi.schemers.org/srfi-119/srfi-119.html https://srfi.schemers.org/srfi-119/srfi-119.html
computably 2y ago
> But I think indentation is better for visualising block structure. Which is irrelevant, because you can visualize code however you want via editor extensions. > And yeah, I am definitely coming for Lisp. An endeavor which is simultaneously hopeless and pointless.
- practal 2y ago
  > Which is irrelevant, because you can visualize code however you want via editor extensions. Semantically, of course this does not matter. A block is a block, no matter if delineated by indentation or brackets. But RX looks better as plain text, and there is much less of a disconnect between RX as plain text, and RX as presented in a special editor (extension) for RX, than there would be for Lisp. > An endeavor which is simultaneously hopeless and pointless. Challenge accepted.