AltME groups: search

Jaime, this is a deep difference and we need to settle it.  I agree 
it's more exciting being able to experiment and choose new behaviours 
for a language, but I think it's more responsible to support the 
language that we have. We can't just keep jumping from language to 
language. The real hard work is to perfect an existing language.

You can't expect a deep thing like a language platform to catch on 
within a few months, or even a few years. Especially not without 
any advertising

When copying a string, you get what you see.

When copying deep a block containing strings, you get more than what 
you see.

Yes, the string is copied in both cases. The difference is that  
copy/deep copies the whole string not only the part that is maked 
by index.

My guess is the current copy/deep behaviour can consume too much 
memory if the strings(or whatever data) are too big.

Here is another way how to ilustrate it clearly:
 
>> s: "abc"
== "abc"
>> mold/all copy/deep reduce [next s]
== {[#[string! "abc" 2]]}
>> mold/all copy next s
== {"bc"}

>> s: [1 2 3]
== [1 2 3]
>> mold/all x: copy reduce [next s]
== "[#[block![1 2 3]2]]"
>> mold/all y: copy/deep reduce [next s]
== "[#[block![1 2 3]2]]"
>> mold/all z: copy next s
== "[2 3]"
>> same? x/1 next s
== true
>> same? y/1 next s
== false
>> same? z/1 next s
== false
>>

yes, the whole serie is copied from HEAD in the copy/deep case...not 
sure if Carl does that intentionally but could be a bug that can 
lead to unwanted bigger memory footprint in some scripts imo.

I have a COPY/DEEP question:


When doing a COPY/DEEP, the first level requires that the argument 
must be a series!, port! or bitset! But when doing a /DEEP, I imagine 
that COPY traverses a series for elements and uses a different process 
than for the first level to determine whether the element can be 
copied. If it can't, it silently passes the value through.

Why can't we do that on the first level as well?

I do dislike having to do:

either series? var [copy/deep var][var]


thing. Generally the programming needed for absolutely deep copy 
a value is too elaborate.

Anyway, such deep bug in REBOL is worrying.

such deep bug in REBOL
 is not a bug in REBOL at all

And, there is an easy remedy, the expression:

    MAKE OBJECT! copy/deep [...]

does not modify the [...], so it is OK

That does not make sense in this case, when what you need is just 
a function like:

safe-object: func [blk [block!]] [make object! copy/deep blk]

and you are done

In REBOL, literal blocks are just literal blocks. If you modify them... 
they are modified. Binding a block modifies the words inside the 
block, ie. it modifies the block. It can't get any simpler than this.


Now, you may argue that MAKE OBJECT! should bind/copy the block instead; 
the reason it does not is purely performance (as 99.99% of the time 
the copy is not necessary). In that 0.01% of cases where you need 
it... you just write MAKE OBJECT! COPY/DEEP [...] instead.

Geomol, the behaviour of self modifying code is never simple to understand, 
that is where Gabriele and I can agree with you.


In contrast to that, what both Gabriele and I call simple is the 
suggestion to use the SAFE-OBJECT [...] (or MAKE OBJECT! COPY/DEEP 
[...]) non-modifying expression, which, indeed, exhibits the simple 
behaviour.

(and, I guess, the same applies to Gabriele as well)

 - correct, as I said, 99.99% of the time copy/deep is not necessary 
 for make object!. The only time i've had to think about using it 
 in the past 12 or so years... is the above example.

Gabriele, I'm afraid, the consequence of such complicated rules is, 
that most programmers will put in COPY/DEEP many places in the code 
in front of blocks. By "most programmers" I mean every REBOL programmer 
except maybe 3.


I don't follow you, when you say, it's an intentional "optimization" 
and then argue, it's a useful feature, we can't live without.

most programmers will put in COPY/DEEP many places in the code in 
front of blocks.
 - how many programs on rebol.org do this?

Yup. The reason that CONTEXT currently doesn't copy is the same as 
why MODULE doesn't copy: They are generally used for one-off creations, 
based on large specs that are rarely reused, and inefficient to deep-copy. 
We could easily make them copy, but it would continue to be a bad 
idea for those reasons.

Gregg, about your questions.


1) Has this behavior ever been behind a bug in any of your REBOL 
code? If so, what was the context and what was the impact (e.g., 
how did you work around it)?


I guess, you mean series inside functions. I'm not for everything 
should do a copy, as Gabriele imply. The problem with series in functions 
is only a problem, because functions in REBOL isn't functions in 
the traditional understanding. They are semi-closures. If they were 
functions, the local values would just be on the stack. Because the 
locals live on, this was a problem for me years ago. First I solved 
it by putting COPY in series definitions, then I in many cases changed 
to just do a CLEAR, like in:

local-block: clear []


Now with the discovered behaviour regarding objects, I find the binding 
rules so complicated, that I would forget, how it works in two weeks. 
I will remember, that I have to be very careful, when making objects 
inside functions, especially if it's recursive functions. The consequence 
for me is, that I will probably put COPY/DEEP in, when making objects. 
As I won't start new big projects in REBOL, I will probably not do 
this a lot in practice.

John, it sounds like where you get confused, or think of things as 
bugs or design flaws, is when having your REBOL "That's funny!" moments, 
borne of deep tinkering. Aside from the "copy series in funcs" behavior, 
which I think bites many people at some point, your issues don't 
come from writing application code in REBOL and bumping up against 
REBOL's behavior. Rather, it seems that REBOL's implementation and 
design don't match your expecations in these cases, and you really 
want it to. :-)


The reason I asked about consequences is because you may want a change 
that affects other users negatively. Imagine REBOLers as being in 
one of two groups. Group A is the gurus. They have internalized REBOLs 
design, understand it deeply, and use BIND and recursive PARSE rules 
without fear. That group is very small. Group C contains everybody 
else, which includes people that don't know about using /local with 
funcs, and suggest REBOL should use  = for "assignment". They have 
never used USE, BIND, or many other functions, because they aren't 
sure how they work. Some of them know a little about series references, 
so they always use COPY to be safe. (Yes, group B exists too, but 
they are much more like C than A).


If REBOL were meant only for A users, it would be very different. 
As a designer, it seems pragmatic to make it so things work well 
for the B and C users who, when they hit a problem that requires 
advanced understanding, will work around issues with the bits they 
understand (and adding many COPY calls), no matter how inelegant. 
Group A users may suffer at their expense, but I'm OK with that, 
because I'm not one of them.

map-each: func [

 "Evaluates a block for each value(s) in a series and returns them 
 as a block."
	[throw catch]

 'word [word! block!] "Word or block of words to set each time (local)"
	data [block!] "The series to traverse"
	body [block!] "Block to evaluate each time"
	/into "Collect into a given series, rather than a new block"

 output [any-block! any-string!] "The series to output to" ; Not image!
	/local init len x
][
	; Shortcut return for empty data
	either empty? data [any [output make block! 0]] [
		; BIND/copy word and body
		word: either block? word [
			if empty? word [throw make error! [script invalid-arg []]]

   copy/deep word  ; /deep because word is rebound before errors checked
		] [reduce [word]]
		word: use word reduce [word]
		body: bind/copy body first word
		; Build init code
		init: none
		parse word [any [word! | x: set-word! (
			unless init [init: make block! 4]
			; Add [x: at data index] to init, and remove from word
			insert insert insert tail init first x [at data] index? x
			remove x
		) :x | x: skip (

   throw make error! reduce ['script 'expect-set [word! set-word!] type? 
   first x]
		)]]
		len: length? word ; Can be zero now (for advanced code tricks)
		; Create the output series if not specified
		unless into [output: make block! divide length? data max 1 len]
		; Process the data (which is not empty at this point)

  until [ ; Note: output: insert/only output needed for list! output
			set word data  do init

   unless unset? set/any 'x do body [output: insert/only output :x]
			tail? data: skip data len
		]
		; Return the output and clean up memory references
		also either into [output] [head output] (
			set [word data body output init x] none
		)
	]
]

Andreas, FORALL won't work here:
>> a: [[1] [2] [3 [4]] [[5]]] forall a [change a first a] a
== [1 2 3 4]


If it's shallow, it should be [1 2 3 [4] [5]], if deep it should 
be [1 2 3 4 5].

The PARSE and WHILE versions above will work in all cases where you 
don't run out of memory, and for the deep versions when there are 
no cyclic references.

>> parse [[1] [2] [3 [4]] [[5]]] [return while [change [set x block!] 
x | skip]]
== [1 2 3 [4] [5]]

>> parse [[1] [2] [3 [4]] [[5]]] [return while [and change [set x 
block!] x | skip]]
== [1 2 3 4 5]

ASSERT/type can do deep type checking of paths, and after the function 
returns the code can assume that the assertions are true. This can 
help with making code that would otherwise be too general for the 
inferencer to handle be really specific. To work best, ASSERT would 
also need to be built into the language, like the loop functions.

AltME is nice, but sometimes, when users are posting too fast on 
deep topics, I have a hard time following the conversation. My english 
is not that good, so I have to check for some words exact spelling 
or meaning when reading/posting. Also, I like to take time to think 
about things before saying them, especially when the topic is deep/complex. 
The old REBOL ML was great for that. That's why I was proposing moving 
such conversations to Google groups, which is just a web front-end 
to a ML.

Those are main basic themes of conserns that will have a deep impact 
on Red you refuse to see it fine

Actually it isn't a new syntax, it's just that the compiler wasn't 
checking it deep enough until now.

Btw, about function! extended support: after making a few tests in 
the compiler to extend it, I can't support it for argument passing 
and as return value for native functions without making function! 
type fully first class. The changes required for that are too deep 
and too numerous to be made now.

I'll wait for your fixes. It's not useful to hunt for deep bugs that 
are already known

Sorry, but I don't really have time to do such deep debugging

I'd like to make the JVM port before the rewrite of Red/System in 
Red, as doing so will certainly require some deep adjustments to 
Red/System compiler and linker, so better have it experienced before 
the rewrite.

Ah, then it's stack-based with deep access into the stack.

Andreas in R3, nested blocks inside a function can't be shared with 
global words.
The body of a function is deep copied before compilation.

Geomol; by text!  I was referring to the old junk! argument.  It's 
not really junk!, it's human text, encoded as humans see fit, gibberish 
or deep meaning symbolic.  Naming things is hard.  ;)   KWATZ! is 
ok...but I don't get the 'ahhh, that's optimal in meaning and depth' 
from it - and I lean Buddhist and did see the Zen references. But 
kwatz is still sinking in, if it's going to (and perhaps that is 
the best kind of deep meaning).

It's not really junk!, it's human text, encoded as humans see fit, 
gibberish or deep meaning symbolic.

Funny, when I first implemented KWATZ!, I called it gibberish!, but 
I found KWATZ! better suited and more interesting. And it kinda give 
you the same feeling, as when you see a computer go down with a "Guru 
Meditation". :)


And if you don't mind, I may start poking around in your wiki as 
btiffin on GitHub. Feel free to tear any writings apart.

The idea with the wiki is, that it's for everybody to edit, so it's 
not really "mine". And as I have very little time for documentation 
right now, I will only contribute a little. It may be needed to step 
in at some point and clear things up, make different pages consistent 
with each other etc., and that may be me, who does that, but it could 
be somebody else too. For the dictionary, it may be an idea to write 
a script, which does most of the documentation (I think, there's 
an old REBOL script for that lying around somewhere, which may be 
suited with some modification). system/words may be needed to do 
that properly, and that's not in World yet. I produce LaTeX output 
with my NicomDoc format, so I'm covered there with the documentation, 
I'll do (a proper manual).

Regarding cortex.w - is that in the far-plan?

Yes, the binary will be as basic as possible. I even consider removing 
definitions of natives from the binary, as it's possible to define 
them in cortex.w. Same could be done with datatypes with a little 
change to World. Then the binary could only define MAKE and DATATYPE! 
(and probably also SYSTEM), and the rest could be build from that. 
It's a good idea to split the doc up in a native section and a mezzanine 
section. And then there's rebol.w, which will make it possible to 
run even more REBOL scripts. There could be a dictionary for that 
too.

Btw. COPY is by defauit deep in World (contrary to REBOL), and World 
will support deep copying of cyclic blocks, which gives a stack overflow 
error in REBOL.

hum... strange I feel like it was fixed, since at some point, R3 
coudn't make objects which I required, then, when Carl did the whole 
copy/make makeover, I was able to start using R3 because of deep 
copying issues being resolved ... maybe it was not completely fixed.