At 2008-05-15 13.55, Frédéric Bonnet wrote:
>  Hi Neil,
>  
>  Neil Madden wrote:
[snip]
 > > My point is that real "strong" references are entirely
 > > incompatible with EIAS.
 > 
 >  Hmmm. I'm not sure what you mean by that. More precisely,
 >  what does EIAS means exactly? To me, it's the fact that
 >  everything can be expressed as strings, and that internal
 >  structures can be recreated from their string representation.
 >  The Cloverfield reference serialization format meets
 >  these criteria IMHO.

This ignorance, if I may say so, seems central to the conception of 
Cloverfield; I wonder if it is genuine of merely tactical (pretending 
not to know better in order to get away with misrepresenting the 
issues). Assuming the former however, I can say the key point is that 
the arguments of commands are in Cloverfield not known to be strings, 
and since command arguments are certainly in the traditional 
"everything" of EIAS, it follows that Cloverfield is not EIAS.

To elaborate on the "Cloverfield command arguments need not be strings" 
issue: The set of strings over a particular alphabet (which in current 
Tcl is the Unicode BMP) is a mathematically well-defined concept, and 
presumably the intent is not that Cloverfield should start interpreting 
every string containing unfortunate character combinations as commands 
to do something -- this would be the way of macro processors such as 
m4, and that way lies a quoting swamp -- but continue to handle strings 
as Tcl do. Nonetheless, Cloverfield is expected to handle values (such 
as references) that when operated upon produce results (e.g. 
side-effects) that are different from everything that could result from 
applying the same operation on a string. Hence references are not strings.

Now, what you in "the tridekalogue" invest a considerable effort in is 
ensuring that any command call can be written straight off as a string. 
  This is certainly an important part of The Tcl Way, but that alone 
does not give you EIAS. The command may be a string before parsing and 
substitution, but after that it would rather have to be a list of 
"things" from some proper superset of that of all strings. What you 
_might_ do is work some parsing rules in reverse and recover a string 
representation for the _list_ of those things; this would bring you 
"every list is a string", which is reminiscent of, but a weaker 
property than, EIAS.

To illustrate,

   {ref a}((1 {ref a}{}) (2 {ref a}{}))

is a perfectly good string, and it might also be the string 
representation for a Cloverfield list. Since this is one word, the list 
will have one element. That element is not a string, but it may be 
entered as a Cloverfield command argument, so that in order to generate 
the above, one can evaluate the command

   list {ref a}((1 {ref a}{}) (2 {ref a}{}))

(If it seems to you that I've got the nesting depth off by one, then 
check how it works for lists without references. Confusing the word one 
writes in a command for the actual string representation of the value 
of that word is a common mistake.)

It's futhermore possible that you don't even get Every List Is A 
String, depending on details of how references are reflected in the 
serialised form. The issue here is that one aspect of "Is A String" is 
that the string representation must tell you _everything_ about how 
that value behaves when operated upon, and for that it matters whether 
an element is local (only referenced to from within the list) or not 
(something outside the list holds a reference to the element).

Concretely, if one was to do

   set u ({ref a}(1 2) {ref a}{})
   set v ({ref a}(1 2) {ref a}{})

then presumably the values of u and v would have equal string 
representation, but be distinct in memory. If one then does

   set w $&v{0}

will the string representations of u and v still be equal? If they are, 
then the results of the commands

   linsert $u 1 $&w
   linsert $v 1 $&w

will have to be equal as well, but I doubt this is the intended 
behaviour. Rather, you would want the result of the latter to be a list 
where all three elements carry the same reference label, whereas in the 
result of the former, the middle element should carry a reference label 
different from that of the other two elements. For that to happen, 
while preserving Every List Is A String, the very act of obtaining a 
reference to a list element (substitution of $&v{0}) must change the 
string representation of that list as a whole.

 From there, one might go on to question the supposed locality of 
Cloverfield references -- although there might be syntax for local 
references that can be used to create data structures, doing anything 
with that data structure will force the references to be global -- but 
I'll stop here.


Lars Hellström


PS: To be frank: I believe Cloverfield is/will be an utter waste of 
good effort -- an exercise that seeks to afflict the very heart of Tcl 
with severe featuritis !-( -- and the sooner such projects die the 
better. ;-]

-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft 
Defy all challenges. Microsoft(R) Visual Studio 2008. 
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
_______________________________________________
Tcl-Core mailing list
Tcl-Core@[...].net
https://lists.sourceforge.net/lists/listinfo/tcl-core