🚀 go-pugleaf

><5455@rex.cs.tulane.edu> fs@rex.cs.tulane.edu (Frank Silbermann) writes:
>>
>>So, when we speak of strict constructors, are we not _really_
>>describing a property of the _selector_ functions, and not the constructor?

<1856@oravax.UUCP> sanjiva@oravax.odyssey.UUCP (Sanjiva Prasad) writes:
>
>	Yes, somewhat. A "constructor" is an *uninterpreted* function, ...
>	The notion of "strict constructor" is a slight abuse of terminology,
>	since the so-called constructor is not wholly uninterpreted.
>	Actually what we are doing is pretend we are
>	working with the product domains (e.g. D1xD2),
>	but are actually working with variants of them
>	(possibly embeddable in the product domain),
>	where elements such as <X,bottom> are identified with <bottom,bottom>,
>	which might be bottom of the product domain (i.e. of D1xD2). 
>	...
>	The so-called constructor symbol is weakly interpreted
>	(under approximation ordering), but otherwise behaves as
>	a true constructor would (for all non-bottom/ bottomless elements). 

It seems like a lot of unnecessary complication.
Instead of associating <bot,3> with <bot,bot>,
it seems simpler to keep these elements are distinct,
but simply not to allow programs to denote elements such as <bot, 3>.

In other words, one may let the syntactic `cons'
denote a strict _function_, f(x,y), which examines
both x and y, and then either returns <x,y>
(if neither x nor y are bottom), or else returns <bot,bot>.
The function `f' is strict, not <_,_>.

Because we only access the ordered pair constructor via a strict function,
elements such as <7,bot> would exist in the domain,
but could not be denoted via the language.

To be sure, this means that our domain is bigger
than strictly (no pun intended) necessary.
However, this is true in any case, since we usually
do not permit definition of every possible
continuous function, either.  (E.g., in many languages
it is impossible to define the parallel boolean `OR',
--- which would return TRUE if either argument is TRUE,
even if the other is bottom).

	Frank Silbermann	fs@cs.tulane.edu
	Tulane University	New Orleans, Louisianna  USA