[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: More on Full Specification
From: Paul Hudak <hudak-paul@YALE.ARPA>
From: Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>
No, not concurrently. E*, in the semantics, always evaluates in
*some* order. This isn't overspecification, as Paul Hudak suggests
,but rather a deliberate and desirable design decision.
I wasn't around when the decision was made, so can't say whether it
was "deliberate" or not, but in what sense is it "desireable"?
Presumably the motivation for this was to allow implementation
freedom, so why only stop half-way?
It would sure be nice if we could get an implicit PCALL without causing any
damage, but going the rest of the way will invalidate currently valid
code. Most of the code which would be endangered is certainly in bad style
already. Let me offer, however, a real-life example that doesn't seem too
unnatural:
(EQV? (SPLAY-TREE-ACCESS T KEY-1)
(SPLAY-TREE-ACCESS T KEY-2))
where splay trees are, of course, self-adjusting trees that may be
destructively modified when an item is retrieved. I invite you to imagine the
result of interleaving two splays on the same tree! It seems unreasonable to
insist that all Scheme programmers must follow Multilisp style standards if
their code is to be portable, and doubly so when we aren't providing any
synchronization constructs.
I wonder how many current
implementations permute the arguments in different ways depending on
context? Seems useful to me ... and fully within the motivation for
underspecification in the first place.
It is useful. My current compiler project uses it.
I think that the
default should be full specification, and that anything left
underspecified should have a very good rationale.
Yes, it seems that underspecification is never "free."
Eric