Re: [racket-users] Re: Some concern about ChezScheme...

['John Clements' via Racket Users]

> On Feb 8, 2019, at 15:01, George Neuner <gneun...@comcast.net> wrote:
> 
> On Fri, 8 Feb 2019 08:37:33 -0500, Matthias Felleisen
> <matth...@felleisen.org> wrote:
> 
>> 
>>> On Feb 6, 2019, at 3:19 PM, George Neuner <gneun...@comcast.net> wrote:
> 
>>> 
>>> The idea that a compiler should be structured as multiple passes each
>>> doing just one clearly defined thing is quite old.  I don't have
>>> references, but I recall some of these ideas being floated in the late
>>> 80's, early 90's [when I was in school].
>>> 
>>> Interestingly, LLVM began (circa ~2000) with similar notions that the
>>> compiler should be highly modular and composed of many (relatively
>>> simple) passes.  Unfortunately, they quickly discovered that, for a C
>>> compiler at least, having too many passes makes the compiler very slow
>>> - even on fast machines.  Relatively quickly they started combining
>>> the simple passes to reduce the running time. 
>> 
>> 
>> I strongly recommend that you read the article(s) to find out how
>> different nanopasses are from the multiple-pass compilers, which
>> probably date back to the late 60s at least. — Matthias
> 
> I did read the article and it seems to me that the "new idea" is the
> declarative tool generator framework rather than the so-called
> "nanopass" approach.  
> 
> The distinguishing characteristics of "nanopass" are said to be:
> 
> (1) the intermediate-language grammars are formally specified and
>     enforced;
> (2) each pass needs to contain traversal code only for forms that
>     undergo meaningful transformation; and
> (3) the intermediate code is represented more efficiently as records
> 
> 
> IRs implemented using records/structs go back to the 1960s (if not
> earlier).
> 
> 
> Formally specified IR grammars go back at least to Algol (1958). I
> concede that I am not aware of any (non-academic) compiler that
> actually has used this approach: AFAIAA, even the Algol compilers
> internally were ad hoc.  But the *idea* is not new.
> 
> I can recall as a student in the late 80's reading papers about
> language translation and compiler implementation using Prolog
> [relevant to this in the sense  of being declarative programming]. I
> don't have cites available, but I was spending a lot of my library
> time reading CACM and IEEE ToPL so it probably was in one of those.
> 
> 
> I'm not sure what #2 actually refers to.  I may be (probably am)
> missing something, but it would seem obvious to me that one does not
> write a whole lot of unnecessary code.


Hmm… I think I disagree.  In particular, I think you’re missing the notion of a 
DSL that allows these intermediate languages to be specified much more 
concisely by allowing users to write, in essence, “this language is just like 
that one, except that this node is added and this other one is removed.” I 
think it’s this feature, and its associated 
automatic-translation-of-untouched-nodes code, that makes it possible to 
consider writing a 50-pass parser that would otherwise have about 50 x 10 = 500 
“create a node by applying the transformation to the sub-elements” visitor 
clauses. Right?

In fact, as someone who’s about to teach a compilers class starting in April 
and who’s almost fatally prone to last-minute pivots, I have to ask: is anyone 
that you know (o great racket users list) currently using this approach or 
these tools? Last year I went with what I think of as the Aziz Ghuloum via Ben 
Lerner approach, starting with a trivial language and widening it gradually. I 
see now that Ghuloum was actually teaching at IU when he wrote his 2006 Scheme 
Workshop paper, and that although he cites about fifteen Dybvig papers, the 
nanopass papers don’t seem to be among them.

Hmm…

John



-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.