6 ms·

Dale – A GC-less S-expression system programming language

123 points by omaranto 12y ago

andrewchambers 12y ago
I like the idea of giving macros type information so they can actually report usage errors in a decent way. The fact that it is is parsed top down means that all type information can be available. I have reservations about the thing as a whole though.
- tekacs 12y ago
  > I like the idea of giving macros type information so they can actually report usage errors in a decent way. You might also find interesting the Scala macro system (http://scalamacros.org/documentation.html http://scalamacros.org/documentation.html)
Dewie 12y ago
To me, the idea of a low-level[1] language with S-expression syntax seems appealing because it is both pretty fundamental machine-wise, and syntax-wise. Why not have a Lispy language as an underlying fundament? The syntax is both about/almost as simple as it gets, and the performance of the code is also more transparent. Not to mention that metaprogramming either using itself or a higher-level language seems more promising than the conventional low-level languages. [1] "systems language" has become too overloaded for my tastes.
- kazinator 12y ago
  Here is the thing: why not bootstrap that using a real Lisp though that does have GC? That is to say, you can have a notation which denotes some "systems" language that doesn't have GC and is static and whatnot. But the meta-programming over that notation (like macros) can be processed by a Lisp that does have GC. For instance, why make the compile-time code like macro-expanders suffer along with no GC? Of course that's been done. E.g. assemblers boostrapped using Lisp, and projects like ThinLisp. "While all of Common Lisp is available at system build time. the Lisp dialect available in production is a carefully crafted subset of Common Lisp. [http://www.thinlisp.org http://www.thinlisp.org] (Maybe Dale is actually structured similarly; so that perhaps "GC-less" refers to run-time only, not build time.)
  - Dewie 12y ago
    Sounds good to me.
  - abecedarius 12y ago
    Not to mention http://en.wikipedia.org/wiki/PreScheme http://en.wikipedia.org/wiki/PreScheme.
azinman2 12y ago
LISP-style syntax needs to die. Too many parentheses. Balancing {} can be annoying enough without having to worry about every single line with lisp-style (). Yey for python for stepping forward on this issue, minus points for their incorrect approach to (multiline) anonymous functions. (I know people will flame this and assume I'm trolling, but this is just my POV as someone who's programed in LISP and ~10 other languages for 20 years now).
- fizixer 12y ago
  "Smart" text editor should help with parentheses. Two ideas come to mind: - It should be aware of S-expression grammar, and actively monitor what the user is typing. (Think of it as an s-expression expert watching over your shoulder). - The line or code block that the cursor is on at a given time, could swtich to multiline view on the fly, with parentheses replaced with indentations, and some color coding. When you move cursor up using the arrow key, the multiline S-expression automatically collapses, and the one above expands. In any case, text editors need to be "fully" aware of the language, e.g., even if the editor does syntax highlighting, it is doing that based on the complete parsing cabability of the syntax, instead of just bunch of rules in editor's script (like vimscript in vim). It would also help if the source file is saved as an AST of the code, instead of raw code. This would also help with code formatting on the fly, and personalized settings for the user of the text editor (e.g., one use always prefers to see S-expressions in multiple lines, another always prefers collapsed view.) Going further. Text editor should allow you to replace any language token with your favorite token, e.g., '(' and ')' could be replaced with '{' or '}' or something else (or maybe even just indentations). As a user preference, not as something that is saved in the AST file. I hope to see something like this for C, something that I like to call "semantic C" programming. I guess I went off on a tangent.
  - tomp 12y ago
    One problem with storing AST are comments. There are ways to deal with them, e.g. Go's `fmt` tool will parse your code into an AST and output it again, but it doesn't leave all comments in the same space. But I agree that it's the way forward!
- 12y ago
Scaevolus 12y ago
These goals sound very similar to BitC. https://www.bitc-lang.org/ https://www.bitc-lang.org/ http://en.wikipedia.org/wiki/BitC http://en.wikipedia.org/wiki/BitC
- tokenrove 12y ago
  In the growing family of ML-inspired systems programming languages, it's worth mentioning ATS as well: http://www.ats-lang.org/ http://www.ats-lang.org/ A big difference here, though, is that AFAIK BitC removed macros, while both ATS and Rust have them in some form. Writing macros in an ML-like language doesn't really compare to writing them in Lisp, although in the case of Dale it's a little disappointing that the macro syntax looks more cumbersome than it could be.
bcg1 12y ago
Cool.

123 points by omaranto 12y ago

I like the idea of giving macros type information so they can actually report usage errors in a decent way. The fact that it is is parsed top down means that all type information can be available. I have reservations about the thing as a whole though.

tekacs 12y ago
> I like the idea of giving macros type information so they can actually report usage errors in a decent way. You might also find interesting the Scala macro system (http://scalamacros.org/documentation.html http://scalamacros.org/documentation.html)

Dewie 12y ago

To me, the idea of a low-level[1] language with S-expression syntax seems appealing because it is both pretty fundamental machine-wise, and syntax-wise. Why not have a Lispy language as an underlying fundament? The syntax is both about/almost as simple as it gets, and the performance of the code is also more transparent. Not to mention that metaprogramming either using itself or a higher-level language seems more promising than the conventional low-level languages. [1] "systems language" has become too overloaded for my tastes.

kazinator 12y ago
Here is the thing: why not bootstrap that using a real Lisp though that does have GC? That is to say, you can have a notation which denotes some "systems" language that doesn't have GC and is static and whatnot. But the meta-programming over that notation (like macros) can be processed by a Lisp that does have GC. For instance, why make the compile-time code like macro-expanders suffer along with no GC? Of course that's been done. E.g. assemblers boostrapped using Lisp, and projects like ThinLisp. "While all of Common Lisp is available at system build time. the Lisp dialect available in production is a carefully crafted subset of Common Lisp. [http://www.thinlisp.org http://www.thinlisp.org] (Maybe Dale is actually structured similarly; so that perhaps "GC-less" refers to run-time only, not build time.)
- Dewie 12y ago
  Sounds good to me.
- abecedarius 12y ago
  Not to mention http://en.wikipedia.org/wiki/PreScheme http://en.wikipedia.org/wiki/PreScheme.

azinman2 12y ago

LISP-style syntax needs to die. Too many parentheses. Balancing {} can be annoying enough without having to worry about every single line with lisp-style (). Yey for python for stepping forward on this issue, minus points for their incorrect approach to (multiline) anonymous functions. (I know people will flame this and assume I'm trolling, but this is just my POV as someone who's programed in LISP and ~10 other languages for 20 years now).

fizixer 12y ago
"Smart" text editor should help with parentheses. Two ideas come to mind: - It should be aware of S-expression grammar, and actively monitor what the user is typing. (Think of it as an s-expression expert watching over your shoulder). - The line or code block that the cursor is on at a given time, could swtich to multiline view on the fly, with parentheses replaced with indentations, and some color coding. When you move cursor up using the arrow key, the multiline S-expression automatically collapses, and the one above expands. In any case, text editors need to be "fully" aware of the language, e.g., even if the editor does syntax highlighting, it is doing that based on the complete parsing cabability of the syntax, instead of just bunch of rules in editor's script (like vimscript in vim). It would also help if the source file is saved as an AST of the code, instead of raw code. This would also help with code formatting on the fly, and personalized settings for the user of the text editor (e.g., one use always prefers to see S-expressions in multiple lines, another always prefers collapsed view.) Going further. Text editor should allow you to replace any language token with your favorite token, e.g., '(' and ')' could be replaced with '{' or '}' or something else (or maybe even just indentations). As a user preference, not as something that is saved in the AST file. I hope to see something like this for C, something that I like to call "semantic C" programming. I guess I went off on a tangent.
- tomp 12y ago
  One problem with storing AST are comments. There are ways to deal with them, e.g. Go's `fmt` tool will parse your code into an AST and output it again, but it doesn't leave all comments in the same space. But I agree that it's the way forward!
12y ago

Scaevolus 12y ago

These goals sound very similar to BitC. https://www.bitc-lang.org/ https://www.bitc-lang.org/ http://en.wikipedia.org/wiki/BitC http://en.wikipedia.org/wiki/BitC

tokenrove 12y ago
In the growing family of ML-inspired systems programming languages, it's worth mentioning ATS as well: http://www.ats-lang.org/ http://www.ats-lang.org/ A big difference here, though, is that AFAIK BitC removed macros, while both ATS and Rust have them in some form. Writing macros in an ML-like language doesn't really compare to writing them in Lisp, although in the case of Dale it's a little disappointing that the macro syntax looks more cumbersome than it could be.

bcg1 12y ago

Cool.