guile-user
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Guile Steel: a proposal for a systems lisp


From: Tim Van den Langenbergh
Subject: Re: Guile Steel: a proposal for a systems lisp
Date: Mon, 11 Jul 2022 13:13:29 +0200
User-agent: mu4e 1.8.5; emacs 28.1

Christine Lemmer-Webber <cwebber@dustycloud.org> writes:

> A little blogpost this morning, not actual software, but software
> desiderata:
>   https://dustycloud.org/blog/guile-steel-proposal/
>
> I'd love to see something like the above happen.  I'd love to help make
> it happen.  So this is more of a call to arms than anything else.
>
> Can we have a "systems lisp"?  Can we do better than Rust?  Let's put
> some interesting things on that compiler tower of ours!

Dear Christine,

creating a Lisp-inspired systems programming language is indeed an interesting
idea, I have also been thinking about something similar (though I wasn't
thinking of tying it to Guile in any way).

Your talk about propagators is also quite interesting, it may take me a lot of
mental processing power to map them to "hey hardware, give me this many bytes
on the stack"-style output, I ought to play around with them over the weekend.

My own thoughts on a systems programming language primarily revolve around
stealing interesting ideas from other projects: taking some notation from
Cakelisp and Coalton, parts of the type system from Coalton and Rust, the
memory management from Rust,...

As I am a big fan of the GNU project I was thinking of targetting GCC's GENERIC
as an initial compilation target, though I am aware that a lot of projects seem
to prefer LLVM instead.  Unfortunately it seems like GCC's documentation
doesn't match up well against that of LLVM, so adding some advanced
functionality may take some code reading (or putting GCC through GDB, that
could be fun).

The part of designing a language for systems programming I dread most is
getting the predictability right.  Being able to tell in advance what gets
allocated on the stack, what on the heap, what gets freed when is very
important.  Of course manual memory management has been a major cause of bugs,
so having the language manage it properly is of prime importance, which makes
it hard to get the predictability right without hampering the ergonomics of the
language.

I am looking forward to reading your further thoughts as you start tinkering
around with the idea.  The Lisp revolution could use another stride forwards.

Vale,

- Tim



reply via email to

[Prev in Thread] Current Thread [Next in Thread]