sergio masci wrote:

>> sergio masci wrote:
>> 
>>> If I understand you correctly what you are saying is that if the
>>> compiler writer is already aware of the /standard/ library before
>>> he starts writing the compiler AND the /standard/ library
>>> definition is set in concrete just as the language definition is
>>> then the compiler writer is able to use intimate knowledge of the
>>> /standard/ library functions within the compiler without
>>> incorporating the code generation of the /standard/ library
>>> functions within the compiler but instead leaving this implemented
>>> external to the compiler proper (so that these functions can be
>>> written by someone else and code generated at compile time). 
>> 
>> Correct. 
>> 
>> I thought this all is basically understood when talking about
>> standard libraries (that is, libraries with an interface that is
>> part of the language standard).
> 
> Ok so I'm starting to get on the same page as you (I may not agree
> but at least I now understand how you are seeing things :)

I thought that there was some disconnect, and I hoped that we would get
there eventually :)

> Furthermore you seem to be saying that using a function call syntax
> rather than a verbose statement syntax (e.g. SQL) should be equally
> easy for the compiler to understand
> e.g.
> 	A compiler should be able to interpret the following three 
> 	statemets as identical
> 
> (1)...	// function call syntax
> 	if( lt(x, 0), assign(y, 0), assign(y, x) )
> 
> (2)...	// C syntax
> 	if (x<0)
> 	{	y = 0;
> 	}
> 	else
> 	{	y = x;
> 	}
> 
> (3)...	// verbose syntax
> 	if x < 0 then
> 		y = 0
> 	else
> 		y = x
> 	endif

I suspect that in many compilers (3) and (2) end up (as an intermediate
representation) in something that's equivalent to (1). But even if not,
it shouldn't be too difficult to make all three end up in the same,
whatever the compiler's internal representation of this statement is. 

It's probably a bit more difficult to write a parser for (2) and (3)
than it is to write one for (1), but in the great scheme of a compiler,
I don't think that this difference is crucial. 

So, yes, I think for a compiler these three could be identical. I don't
see that a compiler could derive any information from any of them that
it couldn't derive from the other two.

Provided, of course, that the functions used in (1) are just as defined
as the operators and statements used in (2) and (3).

> AND because the compiler should be able to "understand" functions as
> easily as other language statements that it is a convenient way to
> extend the language. 

Yes, extend or customize. That's approximately the C++ standard library
way. 

(However, in C++ this isn't done thoroughly. Due to notation conventions
and backwards compatibility, many language elements are special
operators with special features; for example, no matter the specific
meaning given through overriding, the relative precedence of operators
is fixed by the language. Probably a good and necessary thing, but
breaks the extendibility. Not having any precedence and requiring
parentheses for everything would be the "clean" way, but that's more
cumbersome to write in a large majority of the cases, so this is not
only backwards compatibility, but also pragmatism.)

> Could you please confirm this. 

Basically confirmed. 

Gerhard
-- 
http://www.piclist.com PIC/SX FAQ & list archive
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist