Re: More on Full Specification

[Eric S. Tiedemann <tiedeman@acf3.NYU.EDU>]

	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