[r6rs-discuss] Interpreters need not apply?

[Pascal Costanza]

On 7 Mar 2007, at 09:39, Abdulaziz Ghuloum wrote:

>
> On Mar 7, 2007, at 2:59 AM, Thomas Lord wrote:
>
>> Abdulaziz Ghuloum wrote:
>>>
>>> Aubrey, what's this class of "pure interpreters" that you're  
>>> concerned about?  How do they semantically differ from say  
>>> petite, csi, gsi, mzscheme, guile, gosh, rscheme, etc?
>>
>> Doesn't adding the word "semantically" to that question rather  
>> miss the point?
>
> How could I miss a point when asking a question?  The purpose of my  
> question was to enquire, not to miss or make a point.  If you think  
> the question was invalid, then please explain.
>
>
>> Did anyone deny that the current R6 draft could be implemented,  
>> portably,
>> atop any R5 implementation, including SCM?
>
> That's pretty close to what I understood from Aubrey's opening  
> sentence:
>
>> By requiring phased processing of libraries, R5.92RS has
>> disenfranchised "pure interpreters", apparently for the sake of
>> macros.
>
> And acccording to my dictionary (English is not my first language):
>   disenfranchise: deprive (someone) of a right or privilege
>
> So, how could R6RS disenfranchise pure interpreters, and at the  
> same time, be implemented atop these same interpreters?

The terms "compiler" and "interpreter" are not well-defined. But  
AFAICT, a compiler typically works in two phases: A translation from  
one representation to another one, where the latter is typically a  
representation that can be executed by some interpreter (for example,  
a CPU).

An interpreter typically works in one phase: It evaluates expressions  
one by one without doing any sort of whole-program analysis.

Interpreters are interesting because they sometimes have better  
performance characteristics than compilers. Especially when code is  
loaded or generated on demand at runtime, a compilation step may  
incur a much larger overhead than "pure" interpretation. For example,  
this is the case when the loaded or generated code is only executed  
once or just a few times.

This is, BTW, one of the reasons why "modern" virtual machines, like  
those for Java, Smalltalk or Self, are so efficient: They simply  
defer compilation until there is enough evidence that certain  
hotspots actually benefit from an extra compilation step.


Pascal

-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium




-- 
Pascal Costanza, mailto:pc at p-cos.net, http://p-cos.net
Vrije Universiteit Brussel, Programming Technology Lab
Pleinlaan 2, B-1050 Brussel, Belgium