
Dale – A GC-less S-expression system programming language - omaranto
https://github.com/tomhrr/dale
======
Scaevolus
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
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.

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

------
bcg1
Cool.

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

~~~
abecedarius
Not to mention
[http://en.wikipedia.org/wiki/PreScheme](http://en.wikipedia.org/wiki/PreScheme).

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

~~~
oxryly1
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.

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

~~~
oxryly1
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.

