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