Dale – A GC-less S-expression system programming language | Hacker News Reader

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

github.com

123 pointsomaranto33 comments

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

In the growing family of ML-inspired systems programming languages, it's worth mentioning ATS as well: 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.

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.

> 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)

Cool.

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.

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]

(Maybe Dale is actually structured similarly; so that perhaps "GC-less" refers to run-time only, not build time.)

Not to mention http://en.wikipedia.org/wiki/PreScheme.

Sounds good to me.

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).

I find it hard to believe you have done much lisp if you are complaining about balancing parens. If you had done a lot of lisp, then you would never care about balancing parens, because there are tons of context-aware tools that do it for you. Not just that - these tools [paredit, smartparens, etc.] make it impossible for one to ever unbalance parens because they're contextually aware.

To you and the other posters:

You still gotta read the code later. It's not just about input time. The () just cloud things up and can make it slower to understand what's going on IMHO.

This is just my opinion/brain, but I also dislike the RP-style notation. 3 + 5 is easier for me to read than + 3 5, especially when you start combining things like (/ 15 (* (+ 3 5) 4)).

I've not experienced that. I see the indentation more than the parens, in terms of looking at scopes. Browsing through the source code with the cursor highlights matching parens and directly shows which expression you're in.

I do agree partially about the math, though. (+ 1 2 3 4 5 6 7) is easier to read for me than 1 + 2 + 3 + 4 + 5 + 6 + 7, but most mixed-operation expressions are easier to human-read infix.

S-expressions are also more explicit, eschewing punctuation for an AST representation of code. For example, a[2] becomes (aref a 2). Yes, this explicitness is more verbose, but because it's more regular I'd say it's easier to read when things get complex.

However, once you taste the ability to programmatically generate source code right in your code itself, and that becomes part of your common workflow, the benefits of AST s-expressions blow away any of these relatively minor downsides. You can code in an idealized representation, then macro that ideal into actual executing code.

Actually there is some amount of extremely well written code in Lisp.

Check out the book 'Paradigms of Artificial Intelligence Programming' by Peter Norvig. It is one of the best books ever written about programming and it explains a lot of Common Lisp.

http://norvig.com/paip.html

You should have no problems reading this code a week later, a year later or ten years later...

Lisp can be extended to support infix expressions. For instance:

http://www-cgi.cs.cmu.edu/afs/cs/project/ai-repository/ai/la...

After ~3 years of learning Lisp, I find the second style extremely easy to read.

"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.

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!

I've enjoyed using Racket and Clojure, and I see definite advantages to Lisp-style syntax. There are also disadvantages, but I don't think too many parentheses is the main problem, at least not for me. The simple syntax means there are fewer visual cues for language elements, and I think this reduces readability. Clojure is a move in the right direction because it makes more use of punctuation.

Edit: I forgot to add that whatever the disadvantages of Lisp-style syntax, saying it has to die is ridiculous. It is sufficiently useful that it has survived all of these years, and will continue to survive for a long time.

As another long-time LISPer, I kind of agree. I just wish there were an actual alternative.

And as for Python's multiline lambdas... I'll be a lambda heretic and say list comprehensions are the superior approach.

>I'll be a lambda heretic and say list comprehensions are the superior approach.

If all you use lambdas for is list comprehensions then... sure?

I vaguely recall that Haskell has some really neat features to fight the parentheses problem, so you might want to take a look.

Yes, I think Haskell is the right way forward, generally. It does have some significant whitespace which might be an unfortunate necessity. Another option is autoformatting a la Go.

REBOL's syntax is pretty much Lisp without the parentheses. Very pleasing to read. Example here: http://www.rebol.net/cookbook/recipes/0057.html

Another one that sort of resembles Lisp in ALGOL's clothing, is Dylan: http://opendylan.org/

I agree... REBOL is nice to read. A version of LISP that's more legible IMHO. Too bad it never took off, it had a lot of really nice concepts and lots of python-style "batteries included."

Why are people so concerned about anonymous functions? The facts that you ca Defoe a function inside a function, and that they are object make named functions as good as anonymous ones.

But you still have to come up with a name for it every time, and, more importantly, you can't do it inside an expression.

Ya exactly. If you're trying to do a functional map, then it doesn't make sense to have to def it especially because your def will go before the actual execution of it which always looks unideal

I like both Python and anonymous functions, but how would you suggest anonymous functions should work in Python if done "correctly", given the indentation-based syntax?

There's already an indentation based syntax for S-expressions: http://readable.sourceforge.net/

That is an improvement.

Edit: Why the down vote? I appreciated someone's work to address the issues I have with LISP?!

You may also find "z-expressions" interesting. http://chrisdone.com/z/

Why do you have to worry about balancing parens when you can use things like paredit?

Reply on news.ycombinator.com