5 ms·
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 th
by 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 agow.r.t. macros, have you looked at Elixir, Rust, Sweet.js?
- klibertp 12y agoAnd 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 agoYep, 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.
- mrcsparker 12y agoI should have mentioned that precedence rules are pretty wacky. I wish that in the languages I have worked on that I could just ignore precedence and use parens, but operator precedence is expected.
- mamcx 12y agoMore or less my exact plan. Plus modules (like in ADA) or components, a way to do parallel/concurrent programing (CSP, Actors, Coroutines?).