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

[George Neuner]

On 2/9/2019 1:33 PM, 'John Clements' via Racket Users wrote:

> On Feb 8, 2019, at 15:01, George Neuner   wrote:
> 
> 
> 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?


I was referring to the development of the compiler itself.  My comments 
were directed at the perceived problems of bloat in the "micropass" 
compiler infrastructure that "nanopass" is supposed to fix.  ISTM the 
providers of the tools must be held accountable for any bloat they cause 
... not the ones who use the tools.


In the context of real world [rather than academic] development, my 
experience is that most DSLs are not of the form ", plus this bit, 
minus that bit", but rather are unique languages having unique semantics 
that only are *perceived* to be similar to  due to borrowing of 
syntax.  Most users of  don't really understand its semantics, and 
whatever -like DSLs they create will share their flawed understanding.


Real world DSLs - whether compiled or interpreted - often are grown 
incrementally in a "micropass" like way.  But most developers today do 
not have a CS education and will not be using any kind of compiler 
development "framework".  Many even eschew tools like parser generators 
because their formal approaches are perceived to be "too complicated".  
Under these circumstances, there will not be much superfluous code 
written [or generated] that is not either a false start to be thrown 
away, or some kind of unit test.



To be clear, I have no problem with "nanopass" - I think it's a fine 
idea.  But I wonder how well it will transition into the real world when 
students exposed to the methodology leave school and go to work.  Will 
the tools be available for business use and will they be up to the 
demands of real world development?  Will they reduce development effort 
enough to be adopted outside academia?


YMMV, (and it will)
George

--
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.

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

[Matthias Felleisen]

> On Feb 9, 2019, at 5:35 PM, ra...@airmail.cc wrote:
> 
> Could nanopass, at least in theory, fuse multiple (or even all) passes into 
> one at compile time.  To create a very efficient compiler which is also 
> logically broken down and readable in the source code?


Yes, precisely because the languages ought to be purely declarative and, 
especially in a Racket setting, could be isolated from the imperative parts of 
the language. 

No, as they currently are used in Chez because they use side-effects on 
occasion to communicate between passes. See Experience report and up-stream URL 
to Chez module. 

Great research topic, and yes, we looked into it but moved on — Matthias


-- 
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.

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

[rain1]

On 2019-02-08 23:01, George Neuner wrote:

On Fri, 8 Feb 2019 08:37:33 -0500, Matthias Felleisen
 wrote:



On Feb 6, 2019, at 3:19 PM, George Neuner  
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.

The article talks about deficiencies noted with various support tools
and drivers that were provided to aid students in implementing
so-called "micropass" compilers, but who wrote those tools?  Not the
students.  If there was much superfluous code being used or generated,
well whose fault was that?

Aside: I certainly could see it being a reaction to working with Java
where tree walking code has to be contorted to fit into the stupid
multiple dispatch and vistor patterns.


YMMV, (and it will)
George


Could nanopass, at least in theory, fuse multiple (or even all) passes 
into one at compile time.  To create a very efficient compiler which is 
also logically broken down and readable in the source code?


--
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.

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

[Benjamin Scott Lerner]

Credit where it's due: Joe Politz (now at UCSD) came up with the first adaptation of Ghuloum's approach, and I've been riffing on his notes :-)On Feb 9, 2019 1:34 PM, 'John Clements' via Racket Users  wrote:


 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.






-- 
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.

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

['John Clements' via Racket Users]

> On Feb 8, 2019, at 15:01, George Neuner  wrote:
> 
> On Fri, 8 Feb 2019 08:37:33 -0500, Matthias Felleisen
>  wrote:
> 
>> 
>>> On Feb 6, 2019, at 3:19 PM, George Neuner  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.

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

[George Neuner]

On Fri, 8 Feb 2019 08:37:33 -0500, Matthias Felleisen
 wrote:

>
>> On Feb 6, 2019, at 3:19 PM, George Neuner  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.

The article talks about deficiencies noted with various support tools
and drivers that were provided to aid students in implementing
so-called "micropass" compilers, but who wrote those tools?  Not the
students.  If there was much superfluous code being used or generated,
well whose fault was that?

Aside: I certainly could see it being a reaction to working with Java
where tree walking code has to be contorted to fit into the stupid
multiple dispatch and vistor patterns.


YMMV, (and it will)
George

-- 
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.

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

[George Neuner]

On Wed, 6 Feb 2019 12:50:21 -0500, Matthias Felleisen
 wrote:

>> On Feb 6, 2019, at 12:30 PM, 'Paulo Matos' via Racket Users 
>>  wrote:
>> 
>> I was quite surprised to read these nanopass ideas have been around for
>> so long.
>
>
>1. The educational idea came first: 
>
>A Nanopass framework for compiler education. • Volume 15, Issue 5 • September 
>2005 , pp. 653-667
>
>https://www.cambridge.org/core/journals/journal-of-functional-programming/article/educational-pearl-a-nanopass-framework-for-compiler-education/1E378B9B451270AF6A155FA0C21C04A3
>
>2. The experience report of applying the idea to a commercial compiler came 
>about 10 years later: 
>
>A Nanopass framework for commercial compiler development. ICFP ’13 , pp 343-350
>
>https://dl.acm.org/citation.cfm?id=2500618 
>
>
>— Matthias


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.


George

-- 
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.

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

[Neil Van Dyke]

I appreciate the engineering diligence behind Alex's and Paulo's concerns.

Given the exemplary track record on Racket, I'm comfortable putting 
faith in Matthew's assessments (like a trusted engineering colleague, 
beyond the quantifiable like interim benchmarks), and there's at least 
some obvious goal alignment, and there's also been a good amount of 
transparency and conspicuous methodical work on the Chez work.


Thanks to Alex, I just realized that I don't recall the plans for 
performance at switchover time, and going from there.  It'd be good to 
get an update/reminder on the current thinking, as people have to plan 
for long-term.


(My experience with a Racket production server farm is that we often 
didn't pick up each new Racket version immediately, and one time I 
backported a Racket enhancement across multiple versions when we had to 
be especially conservative, but we wanted to keep the option to move to 
use the latest version at any time, and we liked to know that we're on a 
good track for long-term.)


(BTW, some of us run Racket on ancient Intel Core 2 and older smartphone 
ARM, plus have Racket on a beefy new dedicated real-metal compute 
server, and we use 
"https://www.neilvandyke.org/racket/install-racket-versioned.sh";... so 
we will know if anyone tries any funny-stuff! :)


--
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.

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

[Alex Harsanyi]

I guess I also have some concerns about the move to Chez, and largely for 
the same reasons:

* the Chez community is very small, at least when looking at the 
chez-scheme Google Group and Github activity.  I am glad that I'm not the 
only one who noticed that.

* the "maintainability" angle is questionable.  I read all the reports and 
watched the presentation on YouTube, but all I found can be summarized as  
"Matthews opinion is that it will be more maintainable", while his opinion 
carries a lot of weight, it remains an opinion. Time will tell if 
Racket-on-Chez will actually be more maintainable.  BTW, in my professional 
career I have seen a few large ode re-writes whose only benefit was to be 
"improved maintainability", without a clear definition of what that means. 
After the company spending a lot of time and money, this maintainability 
improvement did not materialize...  based on that experience, I remain 
cautious -- sorry, I have been burnt to many times :-) 

* performance wise, it is clear to me by now, that the best I can hope for 
is for overall performance to remain largely the same when Racket 8.0? is 
released.  In the current snapshot, the overall performance is worse.  
There is a separate google-groups thread about this, and I will try to help 
out on this, mostly by providing test cases.

Based on what I have read and seen, my best understanding of Racket-on-Chez 
is that Racket as a language research platform, will probably benefit from 
this move and  Racket as a teaching platform will not be affected either 
way.  What that means for software development using Racket, remains to be 
seen.

I apologize for the negative message...
Alex.

On Tuesday, February 5, 2019 at 9:01:20 PM UTC+8, Paulo Matos wrote:
>
> Hi all, 
>
> Now that I got your attention... :) 
> Although the title is not purely click-bait, it is motivated by personal 
> requirements. 
>
> Most of us are happy with the move to Chez (actually haven't heard 
> anyone opposing it), but I would like to point to something I have felt 
> over the past year and to understand if this is just my feeling or not 
> from others (maybe Matthew) who have had any experience working with Chez. 
>
> I have been, for over a year on and off, trying to port Chez to RISC-V. 
> My problem here is really understanding the Chez arquitecture, rather 
> than the RISC-V one with which I have been working for a few years now 
> as a consultant. 
>
> The whole point of the work was not to get Chez on RISC-V per se but to 
> get Racket on RISC-V. My initial email to the Chez ML was replied to by 
> Andy Keep. He replied in great detail on how to create a Chez backend - 
> I have cleaned up his reply and have been slowly adding to it [1]. 
>
> That was a great start but from there things started to fall apart. 
> Further emails to my questions were generally not replied to (of the 4 
> messages sent, 1 was replied to) [2]. 
>
> Then there is some backend rot... I noticed for example, that there was 
> no Makefile for a threaded version of arm32 although the backend file is 
> there meaning it should be supported. It seems that it's just that 
> nobody every tried to build it. Then software floating point is an 
> option in a backend config file but if you enable it, bootstrapping 
> doesn't work because the compiler really expects you to have some 
> floating point registers. 
>
> Matthew mentions the move to Chez will help maintainability and I am 
> sure he's right because he has been working with Racket for a long time 
> but my experience comes from looking at backend files. When you look at 
> them you end up being forced to look elsewhere, specifically the 
> cpnanopass.ss file [3]. Well, this file is the stuff of nightmares... 
> It's over 16000 (sixteen thousand!!!) lines of dense scheme code, whose 
> comments are not necessarily Chez-Beginner friendly (maybe Alexis wants 
> to rewrite it? [4]). 
>
> So I am a bit concerned about this. I somehow get the feeling that 
> what's going to happen is that Chez is going to slowly degenerate to a 
> Racket sub-project, and nobody is going to really use Chez directly. 
> Therefore this means Matthew et al. will end up maintaining it along 
> with Racket itself. As far as I understand it, both A. Keep and R. 
> Dybvig are both at Cisco and Chez is a side-project from which they are 
> slowly distancing themselves. Chez becoming a sub-project of Racket 
> might seem far-fetched until you noticed Matthew is already the number 4 
> contributor of Chez since it was open-sourced [5]. 
>
> The only question I have is really, what do other people feel about 
> this. Am I making any sense? Have I missed some hidden Chez community 
> that's working day and night into improving it? Or is Chez current sole 
> purpose of existence to support Racket? 
>
> [1] 
> https://github.com/LinkiTools/ChezScheme-RISCV/blob/wip-riscv/PORTING.md 
> [2] 
>
> https://groups.google.com/forum/#!searchin/chez-scheme/Paulo$20Ma

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

[Greg Trzeciak]

On Tuesday, February 5, 2019 at 2:01:20 PM UTC+1, Paulo Matos wrote:
>
>
> So I am a bit concerned about this. I somehow get the feeling that 
> what's going to happen is that Chez is going to slowly degenerate to a 
> Racket sub-project, and nobody is going to really use Chez directly. 
>
>
... and the two became one...  and from that day they were called RaChez 
[read: ruckus]

I could not resist the pun but hope you will get more meaningful response 
then mine. 
Although if someone is looking for racket2 alternative name, #lang ruckus 
seems fitting (given circumstances).

-- 
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.