4 ms·
> There are other things which are also important, like destructuring of code, which a typical macro mechanism will support in some way. Destructuring doesn't
by xfer 9y ago
> There are other things which are also important, like destructuring of code, which a typical macro mechanism will support in some way.
Destructuring doesn't require it to be a list/s-expr. You can destruct ASTs in any language that supports pattern-matching.
> or you need to be able to feed this parser with different syntax definitions and have it runtime extensible.
That's what languages should aim to do. For example rust's procedural macros can transform a TokenStream to another TokenStream and doesn't have to satisfy Rust language parser. Although that doesn't extend to lexing.
> 'can' vs. usually done is a huge practical difference. s-expressions are not a standard input format for C compiler
I am not talking about a specific language compiler, but modern languages are heading in the right direction without using s-expr.
> Quasi-quotation is only a convenience feature - which is great, but they don't add any power to the language. Lisp can create the same effects without quasi-quotation.
Yes, but then you write your own macro-expander.
> operations on the data format can be supported in an text editor and then can be applied to both data and code
Yes, but they will not be very helpful without additional tooling.
> the code structure is not limited to what syntax a programming language parser implements or what an AST can represent
And you have lost the previous point, now your "code as data" is not so well-supported.
> the programming language implementation exposes this internal data in various stages to the user, which it then can conveniently use it. For example macros see this data and can transform it with the usual tools. Interpreters use it and can expose it to the developer. The compiler can use it as input. The pretty printer takes it as input to create textual representations.
True, but these all can be provided without s-expressions, the compiler just has to be designed properly into reusable modules.
Rest of your points just suggest that the tooling part is easier and simpler to do and understand, which ofcourse i agree with. But not all programmers prefer Lisp like syntax and most languages haven't really cared about it or see as undesired(macros bring some undesirable properties as languages like loop pop-up) flexibility.
- lispm 9y ago> Destructuring doesn't require it to be a list/s-expr. You can destruct ASTs in any language that supports pattern-matching. It's not about requiring. It's provided in Lisp. Macros already provide destructuring in their arglists. > That's what languages should aim to do. For example rust's procedural macros can transform a TokenStream to another TokenStream and doesn't have to satisfy Rust language parser. Although that doesn't extend to lexing. A tokenizer is not a language parser. > I am not talking about a specific language compiler, but modern languages are heading in the right direction without using s-expr. That's nothing new or modern. Code transformations and code representation has been used for decades. > Yes, but then you write your own macro-expander. No, quasi-quotations have nothing to do with a macro-expander. It's a general feature in Lisp - independent of macros. One alternative is to procedurally build up code. There is no functionality difference between `(a ,a) and (list 'a a) Both compute the same list structure. >> operations on the data format can be supported in an text editor and then can be applied to both data and code > Yes, but they will not be very helpful without additional tooling. There is nothing wrong with tool building. >> the code structure is not limited to what syntax a programming language parser implements or what an AST can represent > And you have lost the previous point, now your "code as data" is not so well-supported. But I gain a lot of flexibility. > True, but these all can be provided without s-expressions, the compiler just has to be designed properly into reusable modules. That's what Lisp already provides. > Rest of your points just suggest that the tooling part is easier and simpler to do and understand, which ofcourse i agree with. But not all programmers prefer Lisp like syntax and most languages haven't really cared about it or see as undesired(macros bring some undesirable properties as languages like loop pop-up) flexibility. All true.
- xfer 9y ago> A tokenizer is not a language parser. It's not a tokenizer it can transform a token stream to another token stream with a given function which can be some language parser/just rust code producing desired rust ast. > No, quasi-quotations have nothing to do with a macro-expander. My bad, i was confusing it with mixing evaluation.