I think you are both happy if the language is made a little bit more
precise. I'm not sure of the best way to do that but, for starters:
Suppose we are very precise about what we mean by the "execution" of a
Scheme program. In particular, we focus on observables: a program's
execution is observable by virtue of its operations on ports; in a
secondary sense, the program's model of its internal state during
execution can also accumulate evidence of execution. In other words,
taking the specification of program evaluation as given, an execution is
all of the observable consequences of a particular evaluation.
Then consider the case of a portable Scheme library, linked to a C
program. What the safety requirement wants to say -- the only sensible
thing it /can/ say -- is that none of the observable behavior of the
resulting system during any execution should be attributable to an
improper execution of the Scheme code (or else there is a bug in the
Scheme implementation).
Here are two cases to illustrate:
*1. Scheme code calls a C function, which promptly crashes and aborts
the program.* Ok, in that case, the Scheme program's execution is in
the middle of a procedure call. This case is the same as one in which,
without causing any observable side effects, a procedure call to a
standard Scheme procedure never returns: this is still a valid execution
of the Scheme code.
*2. Scheme code calls a C function, which corrupts the Scheme heap and
silently returns.* In this case, the Scheme program's execution resumes
but in a state that is outside of the domain of valid execution
states. This is a bug in the Scheme implementation. We can expect
all "embeddable in C/C++" implementations to have bugs of this sort --
it's an implementation limitation (which says, unsurprisingly, "link
with broken code and all bets are off"). Still, from the perspective
of the report, such buggy implementations can be improved by making the
bug less likely to occur.
So, you're both right?
-t
John Cowan wrote:
> William D Clinger scripsit:
>
>
>> As defined by this document, the Scheme programming
>> language is safe in the following sense: The execution
>> of a Scheme program cannot go so badly wrong as to crash
>> or to continue to execute while behaving in ways that are
>> inconsistent with the semantics described in this document,
>> unless said execution first encounters some implementation
>> restriction or other defect in the implementation of Scheme
>> that is executing the program.
>>
>> That language would imply that no Scheme program could
>> link with unsafe libraries. Another way of putting it
>> is that the act of linking with unsafe libraries would
>> prevent a program from being a Scheme program.
>>
>> If that were to become the definition of Scheme programs,
>> it would be accurate to say that Scheme programs cannot
>> interoperate with C and C++.
>>
>> If that were to become the definition of Scheme programs,
>> then I would not have much interest in Scheme programs,
>> and I would certainly not bother to implement the Scheme
>> language, as so defined.
>>
>
> Everything you say is trivially true, given the understanding of "Scheme
> program" as "program conformant to R5.92RS". A program parts of which are
> written in C (or other low-level language) can't possibly be conformant
> to R5.92RS; try feeding the C parts to any conformant interpreter or
> compiler and see what happens. This is no more bizarre than saying that
> a Fortran program part of which is written in Cobol can't conform to any
> Fortran standard. No standard can prescribe the behavior of an artifact
> that does not claim conformance to the standard. (The ANSI C committee
> hashed this out in detail, and came up with two terms, "conforming" and
> "strictly conforming"; the latter refers to programs that don't exercise
> any of the behavior left undefined by the standard.)
>
> This in no way means that R5.92RS Scheme implementations should accept
> only programs conformant to R5.92RS. In practice, a language that can't
> do interlanguage linking of some kind is on a death spiral.
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL:
http://lists.r6rs.org/pipermail/r6rs-discuss/attachments/20070127/af6d5889/attachment.html
Received on Sat Jan 27 2007 - 12:57:18 UTC