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
> 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
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
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, start
> 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
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
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
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 obvio
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 qu
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.
>
>
...
10 matches
Mail list logo
