World: r3wp

Ladislav, I seem to remember, you once argued against get-words (or 
was it lit-words) as arguments to functions?

 - actually, that is a different matter. What I argued against was 
 "non-transparent" argument passing. The func [:argument] is not "just 
 a get-word", it is a specification of  "as-is argument passing". 
 As far as this one is concerned, it is much better than in R2; cf. 
 the QUOTE function, which cannot be implemented using any kind of 
 argument passing available in R2, while it is trivial in R3. The 
 "unevaluated words argument passing" specified by func ['some-word] 
 is still a different matter and I think that it is much less useful 
 than many users think. (e.g. the GET or SET function don't use it 
 for a good reason).

I wrote about it e.g. in http://www.fm.tul.cz/~ladislav/rebol/argpass.html
, but the article is a bit outdated

I only use lit-word parameters for console interactive functions 
(like CD) - otherwise it tends to be a bad idea. You can use get-word 
parameters for special tricks, but most of the standard special tricks 
have built-in functions in R3 implementing them already. It's usally 
easier to use one of the builtins (like QUOTE) than to navigate the 
tricks of reimplementing them.

There are a few years gone since I wrote my last c program under 
windows.
Just today I tried the extensions.
I was successful with Win-Lcc, but not with tcc.

Can someone tell me, if its possible to compile the extensions with 
tcc and how it should be done?

meassing lot of feature in tcc, are the extensions compilable with 
C compiler ?

or olny C++ ?

Only C for now - not C++. Some tweaks to the header will help with 
that. It's on my list to test with TCC :)

There are some platform-specific adjustments that the headers couuld 
be doing, but aren't yet. We could put TCC tweaks there.

2.100.80 released with new 'copy semantics ... let's test. Max - 
throw your 10K of your gfx nodes into it :-)

Thinking aloud for a bit in relation to the new Copy Semantics:
http://www.rebol.net/wiki/Copy_Semantics


What about the idea of protecting values. This way they won't be 
copied, when creatng a new object. Today we can protect words, but 
not values. So if a word is used for an indirect value, we can kinda 
change the word anyway (I say 'kinda', because we change the value, 
the word points to):

>> a: "a string"
>> b: a
>> protect 'a
>> change b "hmm"
>> a
== "hmmtring"


My idea is, that if we were able to protect values producing constants, 
this idea could be used to guide the creating of objects. And Copy 
Semantics could maybe be a lot simpler.

Submit your comment to the blog, please ...

Done.

Just for those ones who don't test.

To have the R2 behaviour of MAKE in R3, use COPY instead (without 
refinement).

Will images within objects be handled the same way in R2 and R3 then? 
;-)

i'ts not modified

R2 behaviour:

>> o: context [img: make image! 100x100]
>> o1: make o []
>> same? o/img o1/img
== false

R3 behaviour:

>> o: context [img: make image! 100x100
>> o1: copy o
>> same? o/img o1/img
== true

I don't think, your statement holds.

well

my mistake, but it's better that way, no ?

Would this seem like a REBOL way to create a constant?

define s "a string"

Used e.g. in an object this way:

o: context [
	define s "a string"
]


s can then be used as any other word, except it can't be modified 
(both the word and the value), and it won't  be cloned, when creating 
new objects from o.

Steeve, I can't judge that.

To me, the best way is, if the rules are so simple, you're never 
in doubt when programming. I compare these rules to operator rules. 
In REBOL, operators are evaluated left to right. It's a lot easier 
to remember, than having to look at page 53 in "The C Programming 
Language" every now and then, when I program in C, because I can't 
remember all those rules.


I guess, it would be dead simple, if all values were cloned by default, 
when creating new objects. And then use constants for those, that 
you don't wanna have cloned.

I have never used PROTECT. Do you guys use that? Maybe a warning 
system would be better!? hm

Geomol - with new semantics, you can choose datatypes, which values 
will be copied - copy/types [image!] for e.g., or something like 
that :-)

Submitted my CALL complaints to CureCode. Let's see what Carl thinks 
about it ;-)

Yes, I know. Is it too complex with copy/types? To me, it seems a 
bit complex.

Honestly i don't see the interest to protect things.

All the Rebol scripts are plain texts so that they are readable and 
modifiable by any skilled programmer.

If we could compile some scripts or modules to prevent them from 
being inspected, i would say yes, i will protect some things.
but not currently.

From the docs:


COPY/types - specify as a typeset the values to be copied. Note that 
you can use /types without /deep, in which case the copy is applied 
only to the top level of values.


COPY/deep - perform the copy recursively on each value. If you use 
/deep without /types, it is assumed that you want to copy all series 
values (any-string!, binary!, and any-block!) but not bitsets, images, 
vectors, maps, functions, or objects.


I'm pretty sure, I won't be able to remember these rules, so I have 
to look it up, every time I use it. Result: I will probably not use 
it, if I don't really really have to.

Steeve, I sometime manage to accidently redefine words as TO. The 
result is, my script produce strange results, and it's a hard bug 
to find. I could consider protecting all the system words (there's 
a function to do that). But maybe better, if REBOL could give me 
a warning, when I redefine a system word (or maybe changing type 
of one of my own words).

If it's just for debuging purposes, it's a matter of habits.

Never used PROTECT to debug things because i have different habits

Do you accidently redefine words, you shouldn't have? Or do you have 
your own naming convention of words, so your own words will never 
be called the same as a system word? Or maybe you just are very good 
at remembering all the system words? :-)

Geomol - it might be complex, but it serves the purpose to define 
wrapper functions, like object, context, etc. So you can createy 
- my-picture-obj :-)

First of all, i use local contexts everywhere, so that if i redefine 
a global words, the bad effect is limited.

Second: I mostly don't use mezzanines because i want my code as fast 
 as possible. So, I only have to remember the name of natives.

Third: I love REBOL and practices it every weeks, so it's not a pain 
to remember all the words.

fourthly: Because of that, i never do such bugs (except in old times)

:-) Do you use VID?

I like your habit of local contexts everywhere. I try to have that 
habit aswell.

But sometime I manage to write code like:

context [

main: layout [
	from: field
	to: field
]
view layout
]

See the problem?

I see, you forgot to declare your locals

Right, sometime I forgot those inside layout blocks, and that can 
be hard to debug.

I would modify the VID behaviour instead, to treat definitivly that 
case

Yes, good idea.

This is a dirty hack of the LAYOUT function: you're warned if a set-word 
in the layout is not local.

use [x src][
	src: third find second :layout 'while
	src: first find src/forever block!

 insert back tail insert src [if same? in system/words x:][x [print 
 ["Warning:" x "is global var"]]]
]

for 2.7.6

Seems like I wasn't up-to-date regarding PROTECT in R3.

Geomol, you can protect values already in R3 with PROTECT. Request 
granted ahead of time :)

Yup, I think, it might be a good idea to use that to guide copying 
of content within objects, so we don't have to have this complex 
copy semantics. A rule could be: protected values are like constants, 
and they don't get cloned, when creating new objects. All other values 
get cloned.
Makes sense to me.

A problem is though, if I wanna change such a protected value anyway. 
Then I have to first unprotect, change and (maybe) protect again. 
Alternatively, REBOL would need a new flag on values, that mark them 
as "changable constants" or "not-being-copied values" or whatever. 
A rule could be, that such values doesn't get cloned, but they can 
be changed effecting all objects having them.

R3 alpha 81 out, with the new modules. The existing module docs are 
mostly correct now, though still incomplete.

The module docs were good before, but the module system didn't work 
the way specified. Now it does.

So, finally your changes applied? :-)

Yeah, and only two words were wrong in the released version :)

My bad, not Carl's. The errors caused by the two wrong words are 
minor.

BrianH: is new object creation method already in-place? Does it cover 
the changes, you were suggesting in the past? Or simply put - what 
you think should come next?