4 ms·

I agree. The parsing step is distracting. I have TONS of questions and all the tutorials do the parsing stuff, and stop at doing integer +/*-, maybe vars, maybe

by mamcx 12y ago

I agree. The parsing step is distracting. I have TONS of questions and all the tutorials do the parsing stuff, and stop at doing integer +/*-, maybe vars, maybe if, maybe basic functions! I'm doing one, and I'm only working on the AST. I take the idea from this blog: http://www.trelford.com/blog/post/interpreter.aspx http://www.trelford.com/blog/post/interpreter.aspx And from http://www.itu.dk/people/sestoft/plc/ http://www.itu.dk/people/sestoft/plc/. So I get rid of the parsing, and go directly at "how do type checking?", "How I map vars to the environment?", "How make the debugger???", "So, I can have a AST for INTS, BOOLS... now how let the user create your own types???", "How make possible to do macros? I'm not a LISP!", "I'm on F#. How lift the stuff F# already have to do not doing it again???", "What to do: Erlang actors or GO CSP? and how?", "How do pattern matching", "Auto-instrument the code interpreter with dtrace or similar, and why I think this is good?", "I wanna be a reactive language?", "I decide the language be relational. I strongly believe that is amazing. I don't know yet why and how prove it" and a huge list like this... I don't have a clean answer yet for some of this questions! Also, I get rid of the idea of make a compiler, and do a interpreter instead. That is another distraction. I suspect that if later on I turn the interpreter to a bytecode, the step to full compilation will be simple, and without solve several questions about the full language the task of rewrite both the parsing and the compiler is not cool.

mrcsparker 12y ago
I have written a few languages here and there. Hope this helps. They are all separate parts, and you can do them in any order you want. I like to think of the language as two parts - syntax and features. How do I want the language to look and what features do I want the language to have? The parser and lexer handle the syntax, and the AST handles the features. This way, I can play around with the syntax of the language a little later. I would start with a really simple language: - add expressions, proper infix support for arithmetic - variables - if / else / else if - scoping / functions - loops if you don't want to just use recursion then, you can get more advanced: - lambda expressions / first class functions / closures - namespaces or types - macros. if you can make nice looking lisp-style macros for an infix language i would love you write it as an interpreter, add an llvm backend. It should be fun. do a little at a time.
- Havvy 12y ago
  w.r.t. macros, have you looked at Elixir, Rust, Sweet.js?
  - klibertp 12y ago
    And Nimrod, and (Open)Dylan (which I feel really deserves more attention right now, it's far from being dead!). I don't know about Rust, but Elixir, Dylan and Sweet.js have Scheme-style, pattern matching based macro systems while Nimrod is a bit unique in having procedural macros conceptually closer to defmacro from some Lisps. There are also languages where functions can decide whether to evaluate their arguments or not, in the latter case making them work like macros. Io is an example of such a language. Anyway, infix languages with nice macro systems do exist, it's just that none of them became popular enough (yet?). Also, programmers tend to fear macros for some reason (probably because of they are in C and similar languages) which makes having macros rather low-priority feature for language designers. But it's perfectly possible to create a (very nice!) macro system for infix language and it's been done.
    - mamcx 12y ago
      Yep, I have look at nimrod, julia, and barely at dylan. My target syntax is more like python/julia/elixir, and all with relational programing as first-class. The thing I'm now is how implement macros (and how deeply), not the syntax, is kinda easy to see the way with lisp, but still not with more "normal" syntax. Also, I have tough (in a way to provide linq-like capabilities) if could be nice to have this = that (evaluate that and put on this) and this ::= that (get the AST on this and later evalualte this) and let decorate the functions with "fun(test:AST.LogicalOp)", so macros at runtime, not just compile time..
- klibertp 12y ago
  > - add expressions, proper infix support for arithmetic I'd suggest ignoring precedence rules completely here. It generally simplifies the grammar and parser considerably. It doesn't make the language unworkable, either, as long as you allow for grouping with parentheses - Smalltalk does this and it work rather well. I'd also try working with libraries like PyParsing first before attempting to use mammoth size parser generators. In my experience, especially for simple grammars, this way you can be done with parsing stage with minimum effort and concentrate on the "features" side.

by mamcx 12y ago

mrcsparker 12y ago

I have written a few languages here and there. Hope this helps. They are all separate parts, and you can do them in any order you want. I like to think of the language as two parts - syntax and features. How do I want the language to look and what features do I want the language to have? The parser and lexer handle the syntax, and the AST handles the features. This way, I can play around with the syntax of the language a little later. I would start with a really simple language: - add expressions, proper infix support for arithmetic - variables - if / else / else if - scoping / functions - loops if you don't want to just use recursion then, you can get more advanced: - lambda expressions / first class functions / closures - namespaces or types - macros. if you can make nice looking lisp-style macros for an infix language i would love you write it as an interpreter, add an llvm backend. It should be fun. do a little at a time.

Havvy 12y ago
w.r.t. macros, have you looked at Elixir, Rust, Sweet.js?
- klibertp 12y ago
  And Nimrod, and (Open)Dylan (which I feel really deserves more attention right now, it's far from being dead!). I don't know about Rust, but Elixir, Dylan and Sweet.js have Scheme-style, pattern matching based macro systems while Nimrod is a bit unique in having procedural macros conceptually closer to defmacro from some Lisps. There are also languages where functions can decide whether to evaluate their arguments or not, in the latter case making them work like macros. Io is an example of such a language. Anyway, infix languages with nice macro systems do exist, it's just that none of them became popular enough (yet?). Also, programmers tend to fear macros for some reason (probably because of they are in C and similar languages) which makes having macros rather low-priority feature for language designers. But it's perfectly possible to create a (very nice!) macro system for infix language and it's been done.
  - mamcx 12y ago
    Yep, I have look at nimrod, julia, and barely at dylan. My target syntax is more like python/julia/elixir, and all with relational programing as first-class. The thing I'm now is how implement macros (and how deeply), not the syntax, is kinda easy to see the way with lisp, but still not with more "normal" syntax. Also, I have tough (in a way to provide linq-like capabilities) if could be nice to have this = that (evaluate that and put on this) and this ::= that (get the AST on this and later evalualte this) and let decorate the functions with "fun(test:AST.LogicalOp)", so macros at runtime, not just compile time..
klibertp 12y ago
> - add expressions, proper infix support for arithmetic I'd suggest ignoring precedence rules completely here. It generally simplifies the grammar and parser considerably. It doesn't make the language unworkable, either, as long as you allow for grouping with parentheses - Smalltalk does this and it work rather well. I'd also try working with libraries like PyParsing first before attempting to use mammoth size parser generators. In my experience, especially for simple grammars, this way you can be done with parsing stage with minimum effort and concentrate on the "features" side.