unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Tim Van den Langenbergh <tmt_vdl@gmx.com>
To: Christine Lemmer-Webber <cwebber@dustycloud.org>
Cc: guile-user@gnu.org
Subject: Re: Guile Steel: a proposal for a systems lisp
Date: Mon, 11 Jul 2022 13:13:29 +0200	[thread overview]
Message-ID: <875yk3u9av.fsf@terra.tmtvl.info> (raw)
In-Reply-To: <87v8s6xpnq.fsf@dustycloud.org>


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



  parent reply	other threads:[~2022-07-11 11:13 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2022-07-09 15:35 Guile Steel: a proposal for a systems lisp Christine Lemmer-Webber
2022-07-10  9:46 ` Blake Shaw
2022-07-10 12:14 ` Zelphir Kaltstahl
2022-07-11 11:13 ` Tim Van den Langenbergh [this message]
2022-07-15 12:08   ` Christine Lemmer-Webber
2022-08-06 22:38     ` Christine Lemmer-Webber
2022-07-11 13:10 ` Martin Becze
2022-08-07  9:28 ` Damien Mattei
2022-08-07 12:43   ` Christine Lemmer-Webber
2022-08-07 14:47     ` Damien Mattei
2022-08-07 16:02       ` Andrew Gwozdziewycz
2022-08-07 20:17       ` Christine Lemmer-Webber
2022-08-07 21:12         ` Damien Mattei

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/guile/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=875yk3u9av.fsf@terra.tmtvl.info \
    --to=tmt_vdl@gmx.com \
    --cc=cwebber@dustycloud.org \
    --cc=guile-user@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).