3 ms·

I don't like the term parserless in this context. its not like you can just mmap an lisp source file and cast it to the Ast type from the article. Parsing some

by zokier 3y ago

I don't like the term parserless in this context. its not like you can just mmap an lisp source file and cast it to the Ast type from the article. Parsing something might be trivial but its still parsing

082349872349872 3y ago
in that case, pretend I wrote "grammarless" (in the examples above —which missed the prologs— I'm pretty sure the parsing is trivial on the order of "you can see everything that handles 'parsing' without needing to scroll a window", and in several of those examples it'd still be true even if your windows were only 25 lines long)
- whartung 3y ago
  > in that case, pretend I wrote "grammarless" Gonna call you out on that as well. Forth, sure. Forth is...Forth. But Lisp is not grammarless. Smalltalk is not either. The Lisp reader, notably Common Lisp, is a non-trivial piece of code. The Common Lisp lambda list, as a language construct, is not trivial either. (Dare I mention the CL LOOP macro?) Just because everything is "a list, symbol, or constant" does necessarily make the parsing problem trivial. It SEEMS simple, but then you get into it, and you find you fall into the weeds.
  - rewmie 3y ago
    It seems those in this discussion arguing that they don't need a parser or a grammar simply aren't aware they're implementing ad-hoc parsers and grammars but doing it poorly.
    - 082349872349872 3y ago
      Not only am I exactly aware of that, I am even advocating it. OP wants to write a hobby language, not reimplement Common Lisp. If OP wants sexprs, they can get quick-and-dirty sexprs by: (1) substituting spaces around each paren in the input (2) breaking input up into a list of whitespace separated words (3) folding over the resulting list (by looking at its parens) into a tree Sure, that's done poorly. However, it takes under 15 minutes (and under 15 lines?) to get them past their sticking point, and if the rest of their language (especially the part that differs from all other languages) actually turns out to be worth pursuing, they can always implement (or import) a real —or at least a better— reader later. See https://news.ycombinator.com/item?id=36593060 https://news.ycombinator.com/item?id=36593060
      - rewmie 3y ago
        > If OP wants sexprs, they can get quick-and-dirty sexprs by: You know what it takes to implement a parser for s expressions? E := atom | '(' *E ')' With atom expanding to all data types you wish to support. Let's presume using a parser generator is an insurmountable task for someone developing a parser. In a hand-rolled packrat parser, this whole grammar is implemented with a couple of functions. Is writing two functions too much work for someone wanting to write their own parser? Your ad-hoc trick is much more work than actually implementing a proper, maintainable parser.
        carapace 3y ago
        FWIW, I've done it both ways. The ad-hoc trick is cromulent.
- rewmie 3y ago
  > in that case, pretend I wrote "grammarless" You are always parsing a grammar. It seems you simply aren't aware of it. Every single time you write code that expects to find a certain type of token after another type of token, you have a grammar.
mostlylurks 3y ago
"Not parsed ahead of time" might be the better qualification. At least in some forths you can cease parsing the file (in the "outer interpreter") at any point and perform any kind of computation or IO that you've previously defined, and based on that do whatever you want with the rest of the text of the source file (or just the next couple of tokens if you want), including parsing it manually in some other manner than what the outer interpreter would do by default. I haven't gone that deep in lisp, but I hear reader macros allow something similar, though perhaps they might be more restrictive by requiring a transformation into valid lisp trees / values, whereas forth allows you to just do whatever, and if that happens to have the side effect of adding new functions to the dictionary, so be it.

by zokier 3y ago

082349872349872 3y ago

in that case, pretend I wrote "grammarless" (in the examples above —which missed the prologs— I'm pretty sure the parsing is trivial on the order of "you can see everything that handles 'parsing' without needing to scroll a window", and in several of those examples it'd still be true even if your windows were only 25 lines long)

whartung 3y ago
> in that case, pretend I wrote "grammarless" Gonna call you out on that as well. Forth, sure. Forth is...Forth. But Lisp is not grammarless. Smalltalk is not either. The Lisp reader, notably Common Lisp, is a non-trivial piece of code. The Common Lisp lambda list, as a language construct, is not trivial either. (Dare I mention the CL LOOP macro?) Just because everything is "a list, symbol, or constant" does necessarily make the parsing problem trivial. It SEEMS simple, but then you get into it, and you find you fall into the weeds.
- rewmie 3y ago
  It seems those in this discussion arguing that they don't need a parser or a grammar simply aren't aware they're implementing ad-hoc parsers and grammars but doing it poorly.
  - 082349872349872 3y ago
    Not only am I exactly aware of that, I am even advocating it. OP wants to write a hobby language, not reimplement Common Lisp. If OP wants sexprs, they can get quick-and-dirty sexprs by: (1) substituting spaces around each paren in the input (2) breaking input up into a list of whitespace separated words (3) folding over the resulting list (by looking at its parens) into a tree Sure, that's done poorly. However, it takes under 15 minutes (and under 15 lines?) to get them past their sticking point, and if the rest of their language (especially the part that differs from all other languages) actually turns out to be worth pursuing, they can always implement (or import) a real —or at least a better— reader later. See https://news.ycombinator.com/item?id=36593060 https://news.ycombinator.com/item?id=36593060
    - rewmie 3y ago
      > If OP wants sexprs, they can get quick-and-dirty sexprs by: You know what it takes to implement a parser for s expressions? E := atom | '(' *E ')' With atom expanding to all data types you wish to support. Let's presume using a parser generator is an insurmountable task for someone developing a parser. In a hand-rolled packrat parser, this whole grammar is implemented with a couple of functions. Is writing two functions too much work for someone wanting to write their own parser? Your ad-hoc trick is much more work than actually implementing a proper, maintainable parser.
      - carapace 3y ago
        FWIW, I've done it both ways. The ad-hoc trick is cromulent.
rewmie 3y ago
> in that case, pretend I wrote "grammarless" You are always parsing a grammar. It seems you simply aren't aware of it. Every single time you write code that expects to find a certain type of token after another type of token, you have a grammar.

mostlylurks 3y ago

"Not parsed ahead of time" might be the better qualification. At least in some forths you can cease parsing the file (in the "outer interpreter") at any point and perform any kind of computation or IO that you've previously defined, and based on that do whatever you want with the rest of the text of the source file (or just the next couple of tokens if you want), including parsing it manually in some other manner than what the outer interpreter would do by default. I haven't gone that deep in lisp, but I hear reader macros allow something similar, though perhaps they might be more restrictive by requiring a transformation into valid lisp trees / values, whereas forth allows you to just do whatever, and if that happens to have the side effect of adding new functions to the dictionary, so be it.