From: | jens.hansson@mailbox.swipnet.se (Jens Hansson) |
Newsgroups: | comp.compilers |
Date: | 6 Mar 1996 21:18:19 -0500 |
Organization: | - |
References: | 96-02-187 96-02-234 96-02-308 |
Keywords: | standards |
jgm@CS.Cornell.EDU (Gregory Morrisett) writes:
> Providing a precise semantics for a language is not just something
> for the "theoriticians" to do -- it really provides the basis for a
> language -- a contract for both the implementors and the users...
henry@zoo.toronto.edu says...
>Unfortunately, such contracts work much better if they are written in
>a language that the implementors and the users can understand without
>calling in a specialist to interpret for them.
>Send compilers articles to compilers@iecc.com,
>meta-mail to compilers-request@iecc.com.
My suggestion would be:
Describe the semantics in a formal language that is machine-readable
and executable. I believe this is the only way to prove that a
language is "formal" enough. On top of that, this should save the
compiler writers a lot of work -- you could just use the
specification. If you want to do it better (i.e. improving
performance) you have an executable to generate test-vectors from.
The problem with this approach is that the language in itself might
*allow* differences in implementation, like C allows different integer
sizes for different machines. I'd say this is a bad language
definition, but we will have to live with old languages for a while...
[The usual justification for allowing different integer sizes and other
such variations from one platform to another is that if you tie down too
many details, you make it impractical for the language to run reasonable
on machines with different word sizes. Now that everyone seems to have
forgotten that there were ever machines with word sizes not powers of
two, perhaps this argument is worth revisiting. -John]
--
Return to the
comp.compilers page.
Search the
comp.compilers archives again.