unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
From: Jeremiah@pdp10.guru
To: Jan Nieuwenhuizen <janneke@gnu.org>
Cc: guile-user@gnu.org, epsilon-devel@gnu.org, matt.wette@gmail.com
Subject: Re: Next steps for Mes, stage0+? -- Re: You missed my later work
Date: Tue, 02 May 2017 14:26:26 -0400	[thread overview]
Message-ID: <87a86vcdyl.fsf@ITSx00.pdp10.guru> (raw)
In-Reply-To: <87h9134wbi.fsf@gnu.org> (message from Jan Nieuwenhuizen on Tue, 02 May 2017 08:17:05 +0200)


> Ah, and this is what you would need a separate cpp for?
It would certainly simplify the task of implementation

> Thanks for the pointer, I missed that.  I have looked into that
> yesterday.  There are 55 tests and Mes has two obvious reasons why none
> of them work: we need to supply some headers <stdio.h>, <string.h>, and
> they are using printf in all tests.
>
> I am curious to see how far Mes will get :-)

We can just implement stubs to move ahead and flush them out as we move
forward.
Having seen your work, I am certain Mes will go far :-)

> It's good to hear my plan makes sense to you (see below).  What's the
> META II compiler compiler?

https://en.wikipedia.org/wiki/META_II
One might think of it as an early parser generator, which what actually
was used to create the first B compiler.

> Indeed, that would be great!  Writing mes.c in Scheme fairly easy of
> course; I've done almost that a couple of times already.  Being able to
> compile [some] Scheme to native code would be very nice in itself too,
> not just for bootstrapping.

Especially since, the lisp compiler would allow us to save most of the C
bootstrapping steps and simply improve the lisp side of the equation
until implementing a C compiler in lisp becomes a solved problem.

> I was hoping for that, I still need some inspiration here.

How is this for inspiration?
http://piumarta.com/software/maru/
https://github.com/darius/ichbins

> Yes, thanks a lot!  When I started Mes it looked like an almost
> impossible task and what needs to be done can still look daunting.
> Questions are great, but some balancing with answers is very helpful.
Given first hand experience, my answer is as follows:
Lisp infrastructure seems like the correct course of action.
Which implies the following tasks:
1) add a lisp compiler that only supports the bare minimuim required for
useful work.
2a) Flush out MES C compiler as the most important Lisp program it needs
to compile
or
2b) leaverage minimal Lisp compiler to bootstrap full featured Lisp
compiler written in Lisp, which is then used to compile MES C compiler
and thus reduce implementation restrictions placed on MES C compiler.
3) Use the MES C compiler to compile tcc, make and other essential
bootstrap programs to finish the trusted compile path.
4) Extend and enhance Stage0 lisp to include cell compaction and thus
optimize garbage collection performance.
5) Cooperate to select what primitives would be implemented to allow the
stage0 lisp interpeter would need to get the first lisp compiler running
fast.

> Yes, I see.  That's the knowledge that must somehow regain.  It's
> probably a good thing that not everything works well :-)
certainly saves us from the estimated 4,400 Man-years spent
implementing the first algol compiler...

> Hmm...It would make sense to write this lisp compiler in lisp, of
> course.  No need to write it in C.  Hmm.  I wonder if someone would want
> to help transforming the mes.c interpreter into a mes.scm compiler?
It might take me a little bit to get up to speed with your code base but
I am always willing to try to help.

Sounds like we are going to have lots of fun together :D

-Jeremiah



      reply	other threads:[~2017-05-02 18:26 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-03-31 20:28 You missed my later work Jeremiah
2017-03-31 21:48 ` Jan Nieuwenhuizen
2017-03-31 23:17   ` Jeremiah
2017-04-27 12:55     ` Jan Nieuwenhuizen
2017-04-27 23:51       ` Matt Wette
2017-05-01  1:02       ` Jeremiah
2017-05-02  6:17         ` Next steps for Mes, stage0+? -- " Jan Nieuwenhuizen
2017-05-02 18:26           ` Jeremiah [this message]

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=87a86vcdyl.fsf@ITSx00.pdp10.guru \
    --to=jeremiah@pdp10.guru \
    --cc=epsilon-devel@gnu.org \
    --cc=guile-user@gnu.org \
    --cc=janneke@gnu.org \
    --cc=matt.wette@gmail.com \
    /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).