Re: [bug-mes] MesCC should optimize ease of convincing us of its correctness

[Jan Nieuwenhuizen]

Mark H Weaver writes:

Hi Mark,

> Earlier, I wrote:
>> It seems that MesCC has been designed to make it as simple as possible
>> to understand.  Toward that end, you have chosen to implement a language
>> that is not quite C.
>
> I somehow failed to notice (or remember) that Danny had already written:
>> Oh, we don't intentionally violate C semantics.
>
> I'm glad to hear it.  Apologies for the straw man argument.
> Please disregard my last message, and sorry for the noise.

That's fine; I mostly read it as an informed and critical viewpoint,
which is something we could use.  Moreover, it shows me that you
really care about this, which makes me happy.

Also your message is really not that far off.  When I started Mes in
2016 I got a lot of discouragement, ranging from "that's impossible",
"you're an xxx" to the more subtle "and even if you finally succeed
after many years, why?".

At first I just focussed on a lisp interpreter (the Scheme and
Guile-compatibility idea came much later).  I chose to write it in a
pretty simple subset of C, as I was unsure about the bootstrap path for
Mes itself.  I called Mes.c a `prototype in C' because I thought it
would be most probable that I would rewrite Mes in some kind of
annotated assembly.  Currently, Jeremiah Orians is translating Mes.c
into M2-Planet, which is an even simpler C subset.

When the Mes.c scheme interpreter started to work, my first real big
target was to self-host, MesCC should be able to build Mes.c.  When that
finally worked, I started looking at tcc (after dismissing early 1.x
GCCs).  The first version of a Mes.c+MesCC-built tcc that could build
itself was heavily patched by me.  I removed many constructs like
a->b->c, a ()->b, usage of shorts, using uniform switch/case statements
etc.

I asked the tcc community if they would want to play a role in my
bootstrap efforts by accepting patches towards using a subset of C, but
that was rejected.  I then spent about a year to make MesCC rich enough
to deal with a whole bunch of unnecessary C constructs.  To be fair
that greatly improved the design and usefulness of MesCC.

So, while I would agree that we should not invent our own language,
supporting a pragmatic subset of C has been the focus for quite a while.

Greetings,
janneke


-- 
Jan Nieuwenhuizen <address@hidden> | GNU LilyPond http://lilypond.org
Freelance IT http://JoyofSource.com | Avatar® http://AvatarAcademy.com