r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[!REBOL3-OLD1]

Pekr
25-Jun-2009
[15768]
Well, if you agree, it is cool. Make a decision and move on - we 
have still tonnes of issues to solve :-) You know - half functional 
modules, no concurrency, no upper layer networking, still no plugins, 
no GUI (and Flash is going to be everywhere by the end of the year) 
... that seems like a really lot of catch-up we need to play ...
BrianH
25-Jun-2009
[15769]
Max is missing that I already proposed a more flexible solution than 
he is proposing. He is so focused on the behavior of MAKE that he 
missed that I also made proposals for COPY andf COPY/deep.
Pekr
25-Jun-2009
[15770x2]
We imo need to quickly proceed to Beta. I want to start using R3 
as an R2 replacement soon. I need SQLite and then GUI, but I can 
wait with the GUI.
ouch, meeting in 4 minutes ... starting my preparation work :-)
BrianH
25-Jun-2009
[15772]
I am overdue to go to sleep - it's 3am here. I expect to wake up 
and find more comments, darnit :)
Izkata
25-Jun-2009
[15773]
I haven't been following too closely, but I'm against copy making 
a new object from an old one.  I'd have to look at the suggestions 
more to have more comments
BrianH
25-Jun-2009
[15774x5]
Without rebinding, both shallow and deep copy of objects can have 
problems. That's why MAKE is the sensible default, the easy thing.
However, you can't have MAKE do a shallow copy: Spec blocks would 
explode in size. So you need another way to do a shallow copy.
And if you have MAKE do a deep copy (as it does now in R3), memory 
explodes and you can't do graph references. So you need a way to 
make a deep copy too, in case you need to.
So I'm suggesting that the things that would normally be bound in 
an object spec get BIND/copy when you MAKE from an object prototype, 
but otherwise referenced. That means BIND/copy of blocks, words, 
functions and closures. The rest can be copied by the init spec if 
you need to, or not.
Keep in mind that BIND/copy is more efficient in R3, and in theory 
doesn't even need to be a copy: It could be copy-on-write.,
Izkata
25-Jun-2009
[15779]
(I went to sleep right after my last comment, hence the lag)


On equality:  Ladislav's idea sounds good, but I don't exactly see 
the point for having the bottom level in there.  What use would it 
be for?  How/where would the range for "approximate" be set?


On objects:  I think I may have misread it earlier - my comment was, 
"copy/deep [object1 object2]" should return a new block that still 
points at object1 and object2, rather than creating two duplicates 
of them.  But from the comments it certainly doesn't sound like I 
was thinking.  (Although make/deep or "copy/deep/types foo [object! 
series!]" suggestions sound like they may help..?)
Sunanda
25-Jun-2009
[15780]
Another update of my R2--->R3 porting adventures. Highlights of new 
stuff:
  -- pick 0 vs pick -1
  -- hash vs map

  -- examples of version sniffing to ensure one source works in R2 
  and R3 (thanks to Ladislav
     for the method of distingishing R2 from R3)
http://www.rebol.org/art-display-article.r?article=j26z
BrianH
25-Jun-2009
[15781x2]
Izkata, when refering to Ladislav's levels, please number them (as 
he should have). I'm not sure what you mean by "the bottom level". 
If you mean the first level, that is an exact description of the 
behavior of EQUAL? or = in R2.
Adding a refinement to MAKE would be a bad idea, since it is a very 
low-level action that all datatypes support. COPY/types though... 
:)
Izkata
25-Jun-2009
[15783]
I meant the one he labeled "the bottom level", the non-transitive 
one  ;)

I'll call "the bottom level" level 1, then increase to 4, for now. 
 Generally I only use EQUAL? in R2, which appears to me to be level 
2 (although you named it level 1?), but can see why the stricter 
levels 3 and 4 are helpful - I just don't see where level 1 can be 
used right now.


As far as naming goes, my only question is the need for negatives. 
 Why isn't NOT sufficient? ("not equal?" rather than "not-equal?", 
etc)


I forget MAKE can be used with things other than object!, I use it 
that way so rarely.  So yeah, /deep doesn't make sense now that I 
think about it   =P
BrianH
25-Jun-2009
[15784x2]
EQUAL? in R2 is level 1. Changing it to level 2 would break a lot 
of code, particularly for word equivalence :(
You need a NOT-EQUAL? action so you can have a != operator. Every 
op! maps to an action!, no exceptions.
Izkata
25-Jun-2009
[15786x2]
Mmk, I must have just never run across a case where I would have 
seen that by coincidence.
and I didn't know about the op! mapping
BrianH
25-Jun-2009
[15788]
Yeah, it's why there is no NOT-SAME? function - no operator needs 
it.
PeterWood
25-Jun-2009
[15789]
How do you convert a Map! to a Block! in R3? The obvious way doesn't 
seem to work:

>> a: map! [a 1 b 1 c 1]

== [a 1 b 1 c 1]

>> b: to block! a
== [map!]
Sunanda
25-Jun-2009
[15790]
You are missing a TO (or  a MAKE)
    a: TO map! [a 1 b 1 c 1]
    to-block a
    == [a 1 b 1 c 1]
PeterWood
25-Jun-2009
[15791]
Thanks, Sunanda
Maxim
25-Jun-2009
[15792]
version A62 just has to be a special version, it was released on 
my birthday  :-)
Ladislav
29-Jun-2009
[15793]
for Henrik (and others?): you can add your BUILD requirements/notes 
to http://www.rebol.net/wiki/Replacement
Pekr
29-Jun-2009
[15794]
A65 notes mention bind-of .... but A65 release does not know this 
function - it is undefined. So - what is 'bind-of?
BrianH
29-Jun-2009
[15795]
Whoops, typo. Fixed.
Ladislav
30-Jun-2009
[15796x5]
A question from Carl: 

Should #877 just cause an error (infinite cycle):

a: copy []
insert/only a a
copy/deep a
as far as I am concerned, this looks acceptable
Domain of EQUAL? EQUIVALENT? STRICT-EQUAL? and SAME?: currently they 
are declared to accept all values except for #[unset!] Any proposals 
for change?
>> b: tail [1 2 3]
== []

>> clear head b
== []

>> same? b b
== true

>> equal? b b
** Script error: out of range or past end
** Where: equal?
** Near: equal? b b

** Note: use WHY? for more about this error
the above was yet another domain-related example. I can imagine the 
EQUAL? example to yield TRUE as an alternative. Which one do you 
prefer???????
Anton
30-Jun-2009
[15801]
I think this is just about performance. SAME? has a simple job to 
do to see if two values are the same. EQUAL? investigates in more 
depth, and then discovers the range problem. This seems like a good 
implementation and I like the current behaviour.
BrianH
30-Jun-2009
[15802]
EQUAL? is used more often by newbies and people doing quick programming. 
Such people would be better served by the error.
Henrik
30-Jun-2009
[15803]
I'm considering the concept of neutral values: Empty blocks, empty 
strings, zero, true and generally what is default made with MAKE 
<type> [].

It comes from typing this alot:

	all [
		val
		block? val
		empty? val
	]

which would be equivalent to:

	neutral? val

It may be a bad idea.
sqlab
30-Jun-2009
[15804]
Why should  equal? b b yield a error?

Just because it gives back an error in R2, but there also b alone 
gives back an error.
The current behaviour in R3 is much better.
BrianH
30-Jun-2009
[15805]
It yields an error in R3 too. You *want* that error because it tells 
you that you have bad series references. You want to know that.
sqlab
30-Jun-2009
[15806]
No, it does not give an error in R3.

>>  b: tail [1 2 3]
== []

>> clear head b
== []

>> b
== []
BrianH
30-Jun-2009
[15807x2]
EQUAL? b b gives an error in R3, as does = and ==.
No "but there also" related to EQUAL? in your statement, so that 
was the assumed subject of  "The current behaviour in R3".
Ladislav
30-Jun-2009
[15809]
EQUAL? b b causes an error. The value of such an error is doubtful, 
taking into account, that e.g. the MOLD function accepts the series 
happily, in an incompatible manner. So, what is "more useful"? To 
cause or not to cause? My personal opinion is, that the value of 
causing the error is totally negligible even for the beginners. (the 
EQUAL? function is not meant to be used as the function supposed 
to be used for such checking)
BrianH
30-Jun-2009
[15810]
I'm not convinced that the lack of an error with the straight b reference 
is good either. It seems like a good error to throw.
Ladislav
30-Jun-2009
[15811]
If we examine the "nature" of the implementation of REBOL blocks, 
then we come to the conclusion (at least I do), that the "abstraction" 
is as follows: (at least when we examine the PICK function): a block 
is an "essentially unlimited" series of values, the majority of them 
are  #[none] s, except for a limited "segment", which may "contain" 
other values as well
BrianH
30-Jun-2009
[15812x3]
There is a lot of correct code that would assume that
>>greater-or-equal? length? head b index? b

If this is ever not the case and I try to retrieve a value from that 
reference before that condition is true again, that is a serious 
error. If you fill in the missing data before you attempt to retrieve 
anything, not an error.
So, either b is an error in R3, or INDEX? is an error (which might 
be the case).
So we could either have INDEX? be an error, or unstable. Which do 
you prefer?
Ladislav
30-Jun-2009
[15815]
PICK happily allows you to examine any position, so a code that works 
in a manner incompatible with PICK is violating the block design 
principle IMO
BrianH
30-Jun-2009
[15816]
I'm OK with declaring that bounds don't matter, and that INDEX? is 
not an error. The rationale for the new series bounds model was my 
idea, anyways. And having =, !=, == and !== (and their actions) not 
generate an error is consistent with that. Just taking the devil's 
advocate position :)
Ladislav
30-Jun-2009
[15817]
moreover, the INDEX? function does not show you an error.