Mailing List Archive: 49091 messages
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

Sameness - a pragmatic approach.

 [1/39] from: lmecir::mbox::vol::cz at: 11-Feb-2003 8:36


In my opinion the best sameness should be the one that is the most useful for a purpose, for which it is normally used. My model task is: let's have a block B with length 2. Let's suppose, that our partner tells us, that his function F has inserted a value V into it. Our task is to find the position at which the given value is. The first implementation: implementation1: func [b [block!] v [any-type!]] [ either equal? first b get/any 'v [1] [2] ] This implementation has got the following disadvantage: v: [1] b: [[1]] insert/only tail b v implementation1 b v ; == 1 , although we know, that the value V has been stored at the position 2. Let's improve our implementation using SAME? instead of EQUAL?: implementation2: func [b [block!] v [any-type!]] [ either same? first b get/any 'v [1] [2] ] implementation2 b v ; == 2 Which is better than before. Nevertheless, Joel showed that IMPLEMENTATION2 isn't optimal, because: v: 3.0 b: [3] insert/only tail b v implementation2 b v ; == 1 , while the correct answer is 2. My last implementation will use my IDENTICAL? function (described in http://www.rebolforces.com/~ladislav/evaluation.html ). do http://www.rebolforces.com/~ladislav/evaluation.r implementation3: func [b [block!] v [any-type!]] [ either identical? first b get/any 'v [1] [2] ] implementation3 b v ; == 2 In the above mentioned article I proved, that there is no other function, which could be used instead of the IDENTICAL? function for a new implementation and help us to get the correct answer with higher probability than IMPLEMENTATION3. Regards -L

 [2/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 12:43


Hi Ladislav, On Tuesday, February 11, 2003, 8:36:19 AM, you wrote: LM> let's have a block B with length 2. Let's suppose, that our partner tells LM> us, that his function F has inserted a value V into it. Our task is to find LM> the position at which the given value is. I don't think the problem is well defined, unless you are able to identify V amongst any copy of V. I.e. you would not be able to solve the problem in this case: v: 1 b: [1] insert tail b v So we have two choices: either decide that immutable values that are equal are to be considered the same value (so that both V and the two values in the block are the same value), or that immutable values are never the same (so that we have three different "1"s above). I am inclined for the latter just because it avoids another layer of abstraction that is not useful for any other things except the SAME? function. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [3/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 13:51


Hi Gabriele, ----- Original Message ----- From: "Gabriele Santilli" ...
> I don't think the problem is well defined, unless you are able to > identify V amongst any copy of V.
<<quoted lines omitted: 12>>
> Regards, > Gabriele.
I am not able to identify the position of V uniquely in the case you specified, but my problem is a legal problem even though it may not be uniquely solvable sometimes. The same problem occurs below: v: [1] b: reduce [v] insert/only tail b v and (like you did above), Romano might tell me, that this proves, that indiscernible mutable values are never the same when they are at different positions in a block. Is this reasoning useful for the problem? I doubt it, because my approach gives me the provably optimal solution. Moreover, there is one more trouble with your: "immutable values are never the same" approach. In my article I started by defining the identity and then I was able to define mutations, mutability and immutability. If you start the other way round, then there is a trouble, that you use undefined notions and you have to give the meaning to mutations/mutability first, which may be difficult/ambiguous. (See e.g. the discussion on mutability of dates, etc., where my identity-dependent definition gives different results, than another - yet to be written - definition might yield). Regards -L

 [4/39] from: joel:neely:fedex at: 11-Feb-2003 7:43


Hi, all, Am I doing something stupid here? I just tried the following:
>> foo: make object! [a: 1 b: "Hi!"] >> baz: make object! [a: 1 b: "Hi!"]
<<quoted lines omitted: 3>>
>> equal? foo baz == false >> equal? mold foo mold baz == true
Which would lead me to conclude that equality is not defined over objects?? -jn-

 [5/39] from: joel:neely:fedex at: 11-Feb-2003 7:30


Hi, Gabriele, Gabriele Santilli wrote:
> v: 1 > b: [1]
<<quoted lines omitted: 6>>
> another layer of abstraction that is not useful for any other > things except the SAME? function.
I am inclined for the former interpretation, for (oddly enough) the same reason (avoiding unnecessry concepts). I can think of no test that distinguishes among the value of V and the two values in B, and therefore conclude that they are the same. The concept of "where a value was obtained" seems entirely too complicated to my poor brain. On the other hand, given v: "one" b: ["one"] insert tail b v it is easy to engage in behavior that distinguishes the two values in B, therefore I'd conclude that they may be equal (same content, recursively investigated if necessary) but not identical in all respects. I can do this without concern for "where" those values may be mentioned, which makes this seem simpler to me. I'd distinguish between "reading" and "writing" activity, (i.e. read-only access vs. mutation) and take the view that for any two values A and B, equal? a b would be defined as (using non-REBOL but common concepts) for all R in "reading" (R a) = (R b) (yeah, I know that's recursive, there are just too many "primitive" data types in REBOL for me to write all of the base cases ;-) OTOH, same? a b would be defined as all [ for all R in "reading" (R a) = (R b) for all W in "writing" and R in "reading" (W a R a) = (R b) ] So, for example, letting R be MOLD and W be REMOVE , we have v: "one" b: ["one"] insert tail b v (remove b/1 probe mold b/1) = (probe mold b/2) to distinguish the two values in B proving that they are not SAME? Under that view, there are no "writing" activities for immutable values, therefore the second clause in SAME? is vacuously true. And, of course, EQUAL? and SAME? must obey the standard Mathematical requirements for equivalence relations (must be reflexive, symmetric, and transitive). -jn-

 [6/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 15:46


Hi Joel, ----- Original Message ----- From: "Joel Neely" ...
> Am I doing something stupid here? I just tried the following: > > >> foo: make object! [a: 1 b: "Hi!"] > >> baz: make object! [a: 1 b: "Hi!"] > >> equal? foo baz == false > >> equal? mold foo mold baz == true
this is an old issue. Nevertheless, object equality *is* defined: equal? foo foo ; == true This kind of equality is rather trivial, but IIRC the implementor didn't want to overcome all possible difficulties to use a more sensible definition. My EQUAL-STATE? equivalence is a trial to define something better for objects, nevertheless, I have given up for functions, because the natural functional equality isn't algorithmizable. What do you think, is there better functional equality than identity/sameness? Regards -L

 [7/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 15:51


Hi Joel, On Tuesday, February 11, 2003, 2:30:09 PM, you wrote: JN> I am inclined for the former interpretation, for (oddly enough) the JN> same reason (avoiding unnecessry concepts). I can think of no test JN> that distinguishes among the value of V and the two values in B, and No test can prove them being the same, either; so it is an arbitrary choice anyway, and I was just worried of (wrong) implications the former might suggest to a casual reader: one thousand "1"s will consume the same amount of memory than one "1" because they are all the same value. Thus I wanted to avoid the concept "they are the same conceptually, but not in implementation", since I don't find it worth it. Anyway, again, both choices are valid and arbitrary, as long as the behavior of SAME? is consistent with them. :-) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [8/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 15:41


Hi Ladislav, On Tuesday, February 11, 2003, 1:51:35 PM, you wrote: LM> I am not able to identify the position of V uniquely in the LM> case you specified, but my problem is a legal problem even LM> though it may not be uniquely solvable sometimes. The same LM> problem occurs below: What I meant as "not well defined" was that since you used the sentence "the position at which the given value is" you were implying that such position exists and is unique. If we define such position as a position in the block where there is a value that is identical to the value V, then clearly can have multiple solutions, and they depend on the definition of "identical". However this is only being picky, so no point to argue. :-) LM> way round, then there is a trouble, that you use undefined LM> notions and you have to give the meaning to LM> mutations/mutability first, which may be difficult/ambiguous. It is just a matter of definitions. I could simply start by enumerating the types that are mutable and the ones that are immutable, then enumerate the functions that cause a mutation in a mutable value, and then saying that values of the immutable types are never the same, and two values of a mutable type are the same when they are equal before and after an arbitrary mutation of one of them. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [9/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 15:54


Hi Joel, On Tuesday, February 11, 2003, 2:43:52 PM, you wrote: JN> Which would lead me to conclude that equality is not defined over JN> objects?? It looks like it isn't. In the same way that SAME? is the same as EQUAL? for immutable types, EQUAL? is the same as SAME? for OBJECT!s.
>> a: b: make object! [a: 1 b: 2] >> same? a b == true >> equal? a b == true
Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [10/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 16:11


Hi Joel, ...
> I'd distinguish between "reading" and "writing" activity, (i.e. > read-only access vs. mutation) and take the view that for any
<<quoted lines omitted: 5>>
> (yeah, I know that's recursive, there are just too many "primitive" > data types in REBOL for me to write all of the base cases ;-)
...
> So, for example, letting R be MOLD
... Interestingly enough, this isn't the case here: alias 'a "aaa" equal? mold 'a mold 'aaa ; == false equal? 'a 'aaa ; == true How would you comment that? Does it look like an inconsistency to you? Regards -L

 [11/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 16:33


Hi Gabriele, ...
> It is just a matter of definitions. I could simply start by > enumerating the types that are mutable and the ones that are
<<quoted lines omitted: 5>>
> Regards, > Gabriele.
That sounds legal. But the definition of mutability seems more complicated than the sameness to me. Let's take Rebol errors as an example. Originally I thought, that they were immutable. So I could have put them on the list of immutable datatypes. Later I found out, that I was wrong and I corrected myself. I was able to do so, because I had a definition of mutability. In the case of your definition I would never have a chance to find out that I was wrong, because I simply couldn't have been. This doesn't look like a pragmatic approach. Rebol dates may serve as another example. Set-paths originally didn't work for dates as we all remember. According to my definition they were immutable. Interestingly enough, the situation hasn't changed after the set-path introduction, i.e. the definition showed a good stability. Isn't that a good property? Ciao -L

 [12/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 16:55


Hi Gabriele, interesting application of SAME? ! ----- Original Message ----- From: "Gabriele Santilli" ...
> I was just worried of (wrong) > implications the former might suggest to a casual reader: one > thousand "1"s will consume the same amount of memory than one "1" > because they are all the same value.
This is really wrong, see below: ; create an object o: make object! [] ; let's have 1000 identical o's block: make block! 0 insert/dup block o 1'000 Although we have thousand identical O's, the memory consumption is bigger than for one O exactly like in the case of 1's. Interestingly enough, the memory consumed additionally is the same in both cases. Regards -L

 [13/39] from: joel:neely:fedex at: 11-Feb-2003 10:57


Hi, Ladislav, Ladislav Mecir wrote:
> Interestingly enough, this isn't the case here: > > alias 'a "aaa" > equal? mold 'a mold 'aaa ; == false > equal? 'a 'aaa ; == true > > How would you comment that? Does it look like an inconsistency > to you? >
Yes. -jn- -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Atlanta, Ga. - Scientists at the Centers for Disease Control today confirmed that hoof-and-mouth disease cannot be spread by Microsoft's Outlook email application, believed to be the first time the program has ever failed to propagate a major virus.

 [14/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 18:23


Hi Ladislav, On Tuesday, February 11, 2003, 4:55:58 PM, you wrote: LM> Although we have thousand identical O's, the memory LM> consumption is bigger than for one O exactly like in the case LM> of 1's. Interestingly enough, the memory consumed additionally LM> is the same in both cases. But that is the memory consumed by the block, not the objects themselves.
>> system/stats == 3772264 >> b: make block! 1000 == [] >> system/stats == 3788648
so that we have:
>> o: make object! [a: 1 b: 2] >> system/stats == 3788648 >> insert/dup b o 1000 == [] >> system/stats == 3788648
while:
>> clear b == [] >> system/stats == 3792752 >> loop 1000 [insert tail b make o []] == [] >> system/stats == 3891232
Now the fact that the space a block uses is enough to keep simple values in it without needing further memory allocations does not mean that those simple values are not taking memory; thinking in abstract, if you could decouple the block from the values it contains, having 1000 "1"s would take 1000 times the space taken by one "1". Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [15/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 18:14


Hi Ladislav, On Tuesday, February 11, 2003, 4:33:55 PM, you wrote: LM> That sounds legal. But the definition of mutability seems more complicated than the sameness to me. Of course, and that is why the definition should be written down by the language designer. We can only base our discussion to the implementation, thus I don't see any problem with the definition of GSAME? since it looks very natural with the current implementation. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [16/39] from: rotenca:telvia:it at: 11-Feb-2003 19:17


Hi Ladislav, i want to fire another shot in this sameness war :-)
> This implementation has got the following disadvantage: > > v: [1] > b: [[1]] > insert/only tail b v > implementation1 b v ; == 1 > > , although we know, that the value V has been stored at the position 2.
v: 1 b: [1] insert/only tail b v implementation1 b v ; == 1
> Let's improve our implementation using SAME? instead of EQUAL?:
implementation2 b v ; == 1 Do you want that i think that v has been inserted at the first position? Or do you want that i think that i can't distingue the FIRST 1 by the SECOND one. I instead think that the same? function is undefined for scalar value. Another note: When scalar value are passed to function, the function receive a copy of the value. How can a function decide with two copies, if the original values are the same? It is like to decide if the 'a string is the same with a construct like this: a: "string" same? copy a copy a ;== false --- Ciao Romano

 [17/39] from: g:santilli:tiscalinet:it at: 11-Feb-2003 19:14


Hi Joel, On Tuesday, February 11, 2003, 5:57:48 PM, you wrote:
>> How would you comment that? Does it look like an inconsistency >> to you?
JN> Yes. I don't agree. It's just that some values can have different textual representations. For example the two equal objects:
>> a: make object! [a: 1 b: 2] >> b: make object! [b: 2 a: 1] >> mold a
== { make object! [ a: 1 b: 2 ]}
>> mold b
== { make object! [ b: 2 a: 1 ]} are "rendered" differently by mold but are still equal, in the same way the two words "a" and "aaa" are equal once the alias is created. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [18/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 20:56


Thanks, Joel,
> Ladislav Mecir wrote: > >
<<quoted lines omitted: 9>>
> Yes. > -jn-
To be consistent, then, maybe we should say: word1: 'a a: 1 word2: use [a] [a: 2 'a] that WORD1 and WORD2 aren't "naturally" equal, because we can find some differences without any writing operation, shouldn't we? After evaluating an expression like: a: 2 we aren't able to decide for the same words whether they are equal or not without a writing operation, that is why WORD1 and WORD2 aren't "naturally" equal in this case. What is your opinion? -L

 [19/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 21:14


Hi, Gabriele,
> I don't agree. It's just that some values can have different > textual representations. For example the two equal objects:
<<quoted lines omitted: 17>>
> Regards, > Gabriele.
If you consider A and B equal, are you saying, that the implementation of the EQUAL? function isn't consistent for you, because the EQUAL? function doesn't behave like that? Does the following alias 'a "aaa" equal? 'a 'aaa ; == true while same? 'a 'aaa ; == false look consistent to you then? And why? Ciao -L

 [20/39] from: lmecir:mbox:vol:cz at: 11-Feb-2003 21:36


Hi Gabriele, ...
> Of course, and that is why the definition should be written down > by the language designer. We can only base our discussion to the
<<quoted lines omitted: 3>>
> Regards, > Gabriele.
Let me cite from the above paragraph: 1) "the definition should be written down by the language designer" 2) "I don't see any problem with the definition of GSAME?" My POV totally differs in both things: 1) I feel free to write down my own definition of the IDENTICAL? function, my own definition of mutability/immutability, mutations/replacements etc. and to prove their usefulness/optimality/fitness for a particular purpose as well as propose them to the language designer as an improvement. 2) The definition of GSAME? doesn't exist for me as I have said before (you simply cannot start your definition with the listing of the mutable/immutable values). If that were the case and I was free to do it, I could have said, that integers were mutable. That would be legal from the definitional POV, but ridiculous otherwise. Ciao -L

 [21/39] from: joel:neely:fedex at: 11-Feb-2003 16:13


Hi, Ladislav (et al), I'm having to ponder my mental model here, so this is just me thinking aloud ... Ladislav Mecir wrote:
> > > > > > Interestingly enough, this isn't the case here:
<<quoted lines omitted: 20>>
> without a writing operation, that is why WORD1 and WORD2 aren't "naturally" > equal in this case.
I had previously thought of words and values via a model in which a word is associated with a value via a context, words in different contexts may have names spelled the same (as in your A vs. A above), and a LIT-WORD! value was essentially a way to "quote" a word (i.e. to suppress the automatic evaluation of a word to the associated value in the appropriate context). MOLDing a lit-word would just retrieve a string that spelled its name. Clearly that model doesn't address ALIAS properly, both because of your example above using A vs AAA , and because of the fact that ALIASing is apparently immutable once accomplished:
>> alias 'a "aaa"
== aaa ...
>> foo: 3
== 3
>> alias 'foo "aaa"
** Script Error: Alias word is already in use: aaa ** Where: halt-view ** Near: alias 'foo "aaa"
>> alias 'a "foo"
** Script Error: Alias word is already in use: foo ** Where: halt-view ** Near: alias 'a "foo" ...
>> unprotect 'aaa >> alias 'foo "aaa"
** Script Error: Alias word is already in use: aaa ** Where: halt-view ** Near: alias 'foo "aaa" At this point I can only scratch my head in puzzlement, because: 1) It's not clear to me what problem ALIAS is supposed to solve; 2) It's not clear to me why ALIASes must be immutable; 3) It's not clear to me why PROTECTion is inadequate to eliminate accidental re-SETting of alias names; 4) It appears that there's some additional layer of WORD! objects to which word-names refer, and which is detectable via the LIT-WORD! "indirect reference". Given your
> > > alias 'a "aaa" > > > equal? mold 'a mold 'aaa ; == false > > > equal? 'a 'aaa ; == true
I would have expected equal? a aaa ; == true as A and AAA are entangled in a way that guarantees changes to the value associated with one will necessarily be visible in the value associated with the other. I would (in my ignorance of both the intent and implementation of ALIASing) have expected EQUAL? 'A 'AAA to have evaluated to FALSE , as the two literal names (spellings) are different. On the other hand, given that you've called my attention to
> > > equal? 'a 'aaa ; == true
I'm now further baffled to observe same? 'a 'aaa ; == false <rant> All of this simply reinforces my frustration at the lack of a clear, authoritative language spec, in at least two ways. 1) The claim that REBOL is intended for "humans" vs "programmers" doesn't hold water when there are aspects that almost every REBOL programmer (judging by the discussions/questions on this list) finds confusing or counterintuitive, or simply avoids entirely because their use is too difficult to understand/predict, and therefore... 2) The stock reply, "Let REBOL be REBOL; don't think in terms that other languages use!" is wholly unsatisfactory, as the fact that REBOL is actually implemented on conventional computers means that its behavior *CAN* be explained in terms that programmers (at least the programmers of RT ;-) can understand. I've learned and used a large number of languages (and operating systems) during my career, and certainly understand the value of thinking natively in a programming language. I certainly think differently when writing e.g. Perl than when writing Java, and the difference increases exponentially with e.g. Prolog vs C, etc. However, in the case of every other language I've ever learned, I have had access to specifications, manuals, tutorials, textbooks, (and, in the case of languages such as Perl, Python, Ruby, etc. the actual inventors and implementors of the language) to get the definitive answer to any question about what the language was *supposed* to do at any level of detail needed. For the three languages mentioned above (among others) one can get the source code of the implementation as the "source of last resort" to get answers for oneself. I'm certainly happy with the concept that a designer might try to create a language that can be "picked up" by intelligent humans who don't happen to possess graduate degrees in Computing Science or some other aspect of Mathematics. However, that's a totally different aspiration than denying those who *do* have a technical background from the opportunity to use what they already know as a basis for understanding a new language. It's OK to tell a non-technical user something as informal as This language distinguishes between "integer" values, which are "whole numbers" without fractions, and "decimal" numbers which do have fractions. but if you want your language to be used by real programmers for real applications, you'd better be willing to talk about how many bits in an integer and the mantissa and exponent of a floating-pt value. Those two conversations DO NOT conflict. REBOL is a very interesting language with some neat concepts, but as long as we are on our own to figure out how it works (or was intended to work) we will *never* be able to persuade a significant portion of working programmers (and the suits in the food chain) that they should use it. Whether REBOL can even achieve a sufficient "critical mass" of devotees under these circumstances remains to be seen. </rant> -- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Atlanta, Ga. - Scientists at the Centers for Disease Control today confirmed that hoof-and-mouth disease cannot be spread by Microsoft's Outlook email application, believed to be the first time the program has ever failed to propagate a major virus.

 [22/39] from: g:santilli:tiscalinet:it at: 12-Feb-2003 1:21


Hi Joel, On Tuesday, February 11, 2003, 11:13:43 PM, you wrote: JN> 1) It's not clear to me what problem ALIAS is supposed to solve; Translations. If you wanted to translate REBOL or any REBOL dialect into another human language (i.e. not English). JN> 2) It's not clear to me why ALIASes must be immutable; Because once you have said that "stampa" is a different spelling for "print", the current implementation is no more able to "undo" this, probably for the same reason why words cannot be removed from contexts. Of course, AFAIK. (I strongly agree that we need more documentation.) Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [23/39] from: joel:neely:fedex at: 11-Feb-2003 20:49


Hi, Gabriele, Gabriele Santilli wrote:
> Hi Joel, > On Tuesday, February 11, 2003, 11:13:43 PM, you wrote:
<<quoted lines omitted: 4>>
>> protect 'stampa >> stampa: 13
** Script Error: Word stampa is protected, cannot modify ** Near: stampa: 13 Either way, doesn't it still take up another word slot in the global dict^H^H^H^Hcontext.
> JN> 2) It's not clear to me why ALIASes must be immutable; > > Because once you have said that "stampa" is a different spelling > for "print", the current implementation is no more able to "undo" > this, probably for the same reason why words cannot be removed > from contexts. >
I must be missing something. The question of why ALIASes "must" be immutable isn't answered by the fact that they currently are. That only begs the question again, "But *WHY* are they, and would it break something crucial if that were changed?" -jn-

 [24/39] from: lmecir:mbox:vol:cz at: 12-Feb-2003 6:40


Hi Joel, BTW, you didn't answer my question about equality of functions. (I am not sure my question was understandable.) Have you got any opinion? Regards -L

 [25/39] from: lmecir:mbox:vol:cz at: 12-Feb-2003 6:37


Hi Joel,
> I must be missing something. The question of why ALIASes "must" be > immutable isn't answered by the fact that they currently are. That > only begs the question again, "But *WHY* are they, and would it > break something crucial if that were changed?" > > -jn-
I am sure, that in the current implementation it would break things. Let's suppose, that you use both the word 'a and the word 'aaa. In the current implementation you create two new words, each of which has got its own storage . A block like: block: [a aaa] then contains two such normal words. Next, suppose, that you want to do: alias 'a "aaa" , which is "forbidden". If it were allowed, you would be able to create a new block new-block: [a aaa] The trouble is, that although both BLOCK and NEW-BLOCK look and feel the same, they contain different 'aaa words: the former 'aaa has its own storage , while the second one hasn't, because it uses the storage of 'a. The implementation can be changed, but at the expense of an interpreter slow-down and a "retroactivity", which would change the behaviour of BLOCK. Regards -L

 [26/39] from: lmecir:mbox:vol:cz at: 12-Feb-2003 7:05


Hi Romano,
> Hi Ladislav, i want to fire another shot in this sameness war :-)
It would be stupid from me to try to not allow you to find your own definition, with which you would feel comfortable.
> Do you want that i think that v has been inserted at the first position? > > Or do you want that i think that i can't distingue the FIRST 1 by the
SECOND
> one.
What I wanted to underline is the fact, that I supplied a function solving the problem optimally, i.e. giving us as much information as we can get, not less.
> I instead think that the same? function is undefined for scalar value.
Although this looks like a simple sentence, it isn't so. I will translate it to the form I understand: "We should define the SAME? function, that would be undefined for scalar values". I have got only two objections: 1) Nobody has defined what is a "scalar value" in Rebol (is it a date?), at least I haven't seen any complete definition. When the definition will be complete, there is a second objection: 2) Such a function wouldn't do as well as my IDENTICAL? for solving the discussed problem. You may think, that such a function would do better for an "average" task, but I am skeptic about it.
> When scalar value are passed to function, the function receive a copy of
the
> value.
That is your terminology. I am using a different one, nevertheless, I can adjust myself. The biggest trouble may be, that your terminology isn't compatible with the official documentation at all. (Still OK with me as long as I can discern them). Ciao -L

 [27/39] from: lmecir:mbox:vol:cz at: 12-Feb-2003 9:33


Hi Gabriele!
> LM> Although we have thousand identical O's, the memory > LM> consumption is bigger than for one O exactly like in the case > LM> of 1's. Interestingly enough, the memory consumed additionally > LM> is the same in both cases. > > But that is the memory consumed by the block, not the objects > themselves.
Exactly, that is why both thousand O's and thousand 1's behaved alike. My pragmatic POV is, that no confusion has been caused WRT the memory allocation. I can imagine a situation (with more complicated immutable values), when identical values can be stored at different places in the computer memory and therefore consume more memory, than one could superficially expect. OTOH, I can even imagine a situation, when a mutable value can use (temporarily) the same computer memory as another value until a mutation occurs (quite usual strategy). Summary: your model task didn't help us to find any advantages/disadvantages of any approach. Regards -L

 [28/39] from: gisle:dankel:no at: 12-Feb-2003 9:15


Hi Joel, Here's one difference:
>> alias 'print "stampa1"
== stampa1
>> stampa2: :print >> print: 5
== 5
>> stampa1
== 5
>> stampa2
** Script Error: stampa2 is missing its value argument ** Where: halt-view ** Near: stampa2 Gisle

 [29/39] from: joel:neely:fedex at: 12-Feb-2003 5:30


Hi, Gisle, Gisle Dankel wrote:
> >> alias 'print "stampa1" > == stampa1
<<quoted lines omitted: 7>>
> ** Where: halt-view > ** Near: stampa2
Yes, that is a succinct demonstration of the difference between ALIAS and SET, but my question was "Why do we need that capability?" Maybe I can ask it differently, in two stages: 1) When is the last time anyone on this list used ALIAS for anything? (other than demonstrating what ALIAS does ;-) 2) Could that need have been served by some other mechanism already in REBOL? (such as SET/PROTECT or passing a reference) As for myself, the answer to question (1) is "never" but perhaps someone here can enlighten me as to what I've been missing. -jn-

 [30/39] from: g:santilli:tiscalinet:it at: 12-Feb-2003 12:33


Hi Joel, On Wednesday, February 12, 2003, 3:49:20 AM, you wrote: JN> >> stampa: :print JN> >> protect 'stampa JN> >> stampa: 13 JN> ** Script Error: Word stampa is protected, cannot modify JN> ** Near: stampa: 13
>> alias 'all "tutto" == tutto >> mold/tutto true == "#[true]"
(Try this without ALIAS... ;-) JN> Either way, doesn't it still take up another word slot in the global JN> dict^H^H^H^Hcontext. If you use ALIAS, you are not using slots in the global context AFAIK. Also, you can translate the PARSE dialect or any other dialect using ALIAS; I don't know any other way to do it. JN> I must be missing something. The question of why ALIASes "must" be JN> immutable isn't answered by the fact that they currently are. That JN> only begs the question again, "But *WHY* are they, and would it JN> break something crucial if that were changed?" You should ask Carl. ;-) I can only make guesses about the current implementation, which a) would break if you could alias a word that has already been added to system/words, since it would mean having the same word twice in system/words (or in any other object that was created and used that word) and b) would break if you could unalias a word since then it would loose its bindings. Regards, Gabriele. -- Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r

 [31/39] from: joel:neely:fedex at: 12-Feb-2003 6:39


Hi, Ladislav, Sorry! Didn't mean to ignore it! I distinguish between equality testing in general and equality over object methods (though they are certainly functions) because context makes a difference. Fundamentally we have to "shoehorn" three-valued logic into the REBOL two-valued LOGIC! type... Ladislav Mecir wrote:
> BTW, you didn't answer my question about equality of functions. > (I am not sure my question was understandable.) Have you got > any opinion? >
Me? Have opinions? ;-) Let me bound the answer with two assertions, and then try to narrow the gap. 1) I would not expect REBOL to determine general functional equivalence, that e.g. fun0: func [a [number!]] [a + 2] and fun1: func [a [number!]] [2 + a] are (intended to be) equivalent, much less fun2: func [a [number!]] [return 1 + a + 1] or fun2: func [a [number!]] [1 + a + 3 + a / 2] 2) My original question was in reference to the example of foo: make object! [a: 1 b: "Hi!"] baz: make object! [a: 1 b: "Hi!"] equal? foo baz where functions were not involved. It seems to me that this is not significantly harder to solve than fooblk: ["a" 1 "b" "Hi!"] bazblk: ["a" 1 "b" "Hi!"] without functions in the picture. With "elementary" types, EQUAL? is strictly two-valued: we can state with total confidence that two values are or are not equal. Aristotle would have been proud. There are really three possible answers for EQUAL? over function values: we know they are equal (probably SAME?), we know they are not equal (e.g. different argument signatures), or we simply can't tell (given a specific set of criteria). Of course EQUAL? must return a boolean value by definition, so we fold the "can't tell" case into FALSE (properly IMHO). Let me interrupt myself to assert the view that enhanced equality testing for objects should be concerned with correspondance of the attributes and content, without regard for ordering, so that altfoo: make object! [a: 1 b: "Hi!" c: false d: 3.14] would be considered equal to altbaz: make object! [d: 3.14 a: 1 c: false b: "Hi!"] because the *sets* of local words can be placed into 1-to-1 correspondance with equal names and values. Now back to our regularly scheduled program... So this leaves open a number of possibilities for object equality testing: 0) Give up unless the two objects are SAME? This is the present behavior AFAIK. 1) Define equality of objects without trying to analyze inner functions. This would allow equality testing over objects that are used as structured data containers, as in the common REBOL idiom: make object! decode-cgi system/options/cgi/query-string or the FOO and BAZ pairs above. Synonymous object attributes that are set to FUNCTION! values would be compared with EQUAL? which would still "do the right thing" for such cases as newfoo: make object! [a: 1 b: "Hi!" say: :print] newbaz: make object! [a: 1 b: "Hi!" say: :print] where the words referred to the same external/nonmethod func. This case would treat normal methods as "don't know" = FALSE . 2) Use a smarter "method-aware" equality test for the specific case of functions being compared as values of object-local words: two methods would be considered equal if corresponding arguments and refinements had the same names and types, their locals had the same names, and their bodies were the same except for the appearance of corresponding argument, local, refinment, and parent-object words, which would have to match in the obvious way. Thus we would get TRUE for EQUAL? over foofun: make object! [ a: 1 b: "Hi!" say: func [n [number!]] [ loop n [ print ["a" a tab "b" b] ] ] ] and bazfun: make foo [] ;; OK, I'm lazy... ;-) because of the following analysis: foofun type bazfun ---------------------- ---------------------- a: corr. a: 1 equal 1 b: corr. b: "Hi!" equal "Hi!" say: corr. say: func [ equal func [ n corr. n [number!]] [ loop equal [number!]] [ loop n corr. n [ print [ "a" equal [ print [ "a" a corr. a tab "b" equal tab "b" b corr. b ] ] ] ] equal ] ] ] ] (where I'm crowding as much "equality" as possible into one line for the sake of brevity). In all of these alternatives, there will still be "don't know" cases that become FALSE (i.e. our heuristics can't prove they are equal) but I see some virtue in pushing the envelope. My (uninformed) guess is that option (1) wouldn't be very costly to add, as we already have an equality test for functions:
>> stampa: :print >> equal? :print :stampa
== true We certainly don't want to wait for the interpreter to solve the Halting Problem, however! ;-) -jn-

 [32/39] from: maarten:koopmans:surfnet:nl at: 12-Feb-2003 13:30


Hi Joel,
> 1) When is the last time anyone on this list used ALIAS for anything? > (other than demonstrating what ALIAS does ;-)
I did. Once upon a time on the wild wild REB I wrote a script that you could feed a dictionary and then made a "localized " REBOL. Aliasing the complete dictionary to provide a native (as in a your native language) REBOL. REBOL/Dutch was fun to have. I built it for my wife so she could read some scripts that she was about to use. That worked for her as well.
> 2) Could that need have been served by some other mechanism already > in REBOL? (such as SET/PROTECT or passing a reference) >
No. Alias works "better" than set for some values. As you may well know ;-) --Maarten

 [33/39] from: ammon:addept:ws at: 12-Feb-2003 7:11


Hi Joel, This may not be the answer you were looking for, and someone may have pointed this out already, but I am going through my email from the top down so I haven't seen it yet. ;-)
>> foo: make object! [a: 1 b: "Hi!"] >> baz: foo >> equal? foo baz
== true Enjoy!! Ammon Johnson CIO of Addept ---------- (www.addept.ws) 435.616.2322 ---------- (ammon AT addept.ws)

 [34/39] from: joel:neely:fedex at: 12-Feb-2003 9:13


Hi, Ammon, I probably was too brief in my phrasing; what I meant was "equality of content" vs. "same reference" in the same way that one can have equal blocks that are not the same block.
>> foo: [0 2 4 "Hi!"] == [0 2 4 "Hi!"] >> baz: [0 2 4 "Hi!"] == [0 2 4 "Hi!"] >> equal? foo baz == true >> same? foo baz == false
Sorry for being too "shorthand"! -jn- Ammon Johnson wrote:
> > >> foo: make object! [a: 1 b: "Hi!"] > >> baz: foo > >> equal? foo baz > == true >
-- ---------------------------------------------------------------------- Joel Neely joelDOTneelyATfedexDOTcom 901-263-4446 Atlanta, Ga. - Scientists at the Centers for Disease Control today confirmed that hoof-and-mouth disease cannot be spread by Microsoft's Outlook email application, believed to be the first time the program has ever failed to propagate a major virus.

 [35/39] from: rotenca:telvia:it at: 12-Feb-2003 16:18


Hi Ladislav,
> > When scalar value are passed to function, the function receive a copy of > the
<<quoted lines omitted: 3>>
> compatible with the official documentation at all. (Still OK with me as long > as I can discern them).
I should like to know how you (and the official doc) interpret this point. Perhaps all this stuff is not clear to me. --- Ciao Romano

 [36/39] from: rotenca:telvia:it at: 12-Feb-2003 16:50


Hi Gabriele,
> are "rendered" differently by mold but are still equal, in the > same way the two words "a" and "aaa" are equal once the alias is > created.
I agree. Is interesting for me to note this: alias 'a "aaa" o: context [aaa: 4] o/a ;==4 o2: context [a: 5] o2/aaa ;==5 --- Ciao Romano

 [37/39] from: rotenca:telvia:it at: 12-Feb-2003 16:38


Hi all
> The trouble is, that although both BLOCK and NEW-BLOCK look and feel the > same, they contain different 'aaa words: the former 'aaa has its own > "storage", while the second one hasn't, because it uses the storage of 'a. > The implementation can be changed, but at the expense of an interpreter > slow-down and a "retroactivity", which would change the behaviour of BLOCK.
I think that an alias word cannot be un-aliased because it is not added to the global context. If the link with the original aliased word is broken the alias word will become an unloaded / unbound word (and this kind of words make crash Rebol in some situations). --- Ciao Romano

 [38/39] from: greggirwin:mindspring at: 12-Feb-2003 9:20


Joel et al, JN> ...but my question was "Why do we need that capability?" JN> 1) When is the last time anyone on this list used ALIAS for anything? JN> (other than demonstrating what ALIAS does ;-) JN> 2) Could that need have been served by some other mechanism already JN> in REBOL? (such as SET/PROTECT or passing a reference) Is there another mechanism you can use to create localized dialects? That's probably the main use I've thought of for ALIAS, but I haven't thought about how else you might do it. -- Gregg ; Localizing a dialect with ALIAS alias 'who "welche" alias 'where "wo" alias 'when "wann" rule: [ some [ 'who set persons [word! | block!] | 'where set place string! | 'when set time time! ] to end ] time: place: persons: none parse [ who Fred where "Your house" when 9:30 ] rule print [time place persons] time: place: persons: none parse [ welche Karl wo "Euer Haus" wann 11:30 ] rule print [time place persons]

 [39/39] from: lmecir:mbox:vol:cz at: 12-Feb-2003 18:10


Hi Joel,
> 2) My original question was in reference to the example of > foo: make object! [a: 1 b: "Hi!"]
<<quoted lines omitted: 5>>
> bazblk: ["a" 1 "b" "Hi!"] > without functions in the picture.
Just to show it is possible: do http://www.rebolforces.com/~ladislav/evaluation.r equal-state? foo baz ; == true
> With "elementary" types, EQUAL? is strictly two-valued: we can > state with total confidence that two values are or are not > equal. Aristotle would have been proud.
:-)
> There are really three possible answers for EQUAL? over function > values: we know they are equal (probably SAME?), we know they
<<quoted lines omitted: 12>>
> correspondance with equal names and values. Now back to our > regularly scheduled program...
Let me just have a look, what the EQUAL-STATE? thinks about it: equal-state? altfoo altbaz ; == false Bad luck. Nevertheless, this seems to be in contradiction with your rule stating that (mold altfoo) should equal to (mold altbaz), which isn't the case.
> So this leaves open a number of possibilities for object equality > testing:
<<quoted lines omitted: 12>>
> where the words referred to the same external/nonmethod func. > This case would treat normal methods as "don't know" = FALSE .
Let me check EQUAL-STATE? again: equal-state? newfoo newbaz ; == true
> 2) Use a smarter "method-aware" equality test for the specific > case of functions being compared as values of object-local
<<quoted lines omitted: 45>>
> the Halting Problem, however! ;-) > -jn-
I just wanted to start with a simpler, yet, as it seems, unsolvable problem. How it should be with the equality of: a: func [a] [a] b: func [a] [a] although this seems to be almost trivial, it isn't, see below: c: func [a] [a] change second :c use [a] [a: 0 'a] probe :c ; func [a][a] Now I don't know about any better method to compare A and C, than the classical sameness. Moreover, this shows, that Rebol is less transparent, then it seems at a first glance. Regards -L

Notes
  • Quoted lines have been omitted from some messages.
    View the message alone to see the lines that have been omitted