World: r3wp

ecaled = evaled

Yes, I mean I wouldn't want to lose the ability to use lit-word parameters 
in function specs. Sorry I wasn't clear about that.

Aha .. I am also not too big on this.. just thinking outloud

Thinking out loud is good. 


I've used them in the past, and sometimes they make things look a 
*lot* nicer. Other times they end up being a pain, especially when 
you're generating code. That is, you want to generate the arg dynamically.

One criticism of rebol that I saw is that because of no parens , 
you have to know the number of args of each word to understand the 
program like >> first join get-name id << . I don't see this as a 
problem in practice, and like the fact that there are no parens needed. 
 but if you add that some functions can use take args that look just 
like they will eval into values in every other case it becomes a 
little more complex. :) but as I said I am just debating.

yes, I also love this ability when creating my own "control structures" 
but I lately rather used ordinary approach because sometimes my fancy 
function then bit me later :)

REBOL's free-ranging evaluation is the polar opposite of Lisp that 
way. :-)  It can take getting used to, but I found it natural before 
long. It is different though, and it's something people can cite 
as being obviously different from other languages. 


Something fun to ask is what we would have to give up if REBOL had 
arg lists like other languages.

And what would it take so you could write REBOL like Lisp?


Would you be able to write func calls with parens, as in other langs, 
and then pre-process it with REBOL?


Ultimately, people have to realize that the lack of parens on func 
calls isn't just some crazy thing Carl wanted to do to be different.

I think the lack of parens on function calls is esential thing to 
make programs flow better .. I really like that. You can always add 
parens and if some part is a little more complex. Or if you add all 
the parens you get relisp >> (first (join get-name id)) << :)

On Lisp, exactly. Now, on the paren thing in general, it's not just 
better flow. Remember that REBOL isn't a programming language, it's 
a messaging language. Now, think about dialects. Next, imagine how 
you would make dialects work.

yes, it's also more important in context of messages and dialects 
 :)

Lit-word arguments

 actually aren't lit-word arguments, this is just a function specification 
 dialect specifying how the arguments are evaluated; in this respect 
 R2 "lit-word arguments" are different thing, than R3 "lit-word" arguments, 
 since in R3 they actually are "sometimes evaluated arguments (get-word! 
 and paren! cause evaluation, otherwise the argument is passed without 
 being evaluated), while in R2 they are not evaluated, just the value 
 of a get-word is retrieved.

Thanks for the clarification Ladislav.

Technically, get-words are evaluated by the lit-word calling convention 
in R2 as well, just not parens. Look at this:
>> a: func ['a] [:a]
>> w: 1
== 1
>> a w + 2
** Script Error: Cannot use add on word! value
** Where: halt-view
** Near: a w + 2
>> a :w + 2
== 3


The only difference between "just the value of a get-word is retrieved" 
and "the get-word is evaluated" is that evaluation also triggers 
the op! processing trick, if an operator follows the get-word.

The new or changed mezzanines in R2 2.7.7+ that use the lit-word 
calling convention explicitly evaluate parens to be more like the 
R3 version of the functions. However, since the evaluation is explicit 
within the function rather than performed by DO at the call location, 
op! evaluation isn't triggered:
>> a (w) + 2
** Script Error: Cannot use add on paren! value
** Where: halt-view
** Near: a (w) + 2


Since the lit-word calling convention is only really appropriate 
for functions that act like syntax (like FOR), interactive functions 
that work on files (like CD) or functions that use word values as 
flags (like SECURE), they are never used with functions that take 
as arguments the types of values that are returned by op! expressions 
(numbers, binaries, true or false). So this is never an issue in 
practice, only in bad code that should never work.

ah, I stand corrected:

a: func ['a] [probe :a]
w: 1
a :w + 3
; 4
; == 4

, i.e. the get-word really triggers evaluation even in R2, so the 
only difference is, that paren! does not trigger evaluation in R2.

Is size? %somefile limited to a certain limit? When trying to get 
a size of a 4GB file, it returns 22927360.

32bit integer size?

yep.

Got it. Thought so.

at least it's not negative!

Wouldn't it be possible to get correct decimal number if you get 
negative (overflowed) size as an integer?

(in a limited range:)

and what if the file is 8gb?

Size? is 64 bit -- in theory.  What OS?

(on R3)

he's talking r2

Yep., R2 and then the word that was keeping track of the bytes sent 
exploded so I just changed the progress bar to show activity  and 
skipped trying to track sizes. The main point was to move files from 
one drive to another anyway.

Is this logical?

>> negate 2 - 1
== -1
>> - 2 - 1
== -3


(Notice I put space after the first minus making it a unary minus.)

The above is R2. Unary minus doesn't seem to be implemented in R3.

Yes...
2 - 1 = 1, negate 1 = -1
negative 2 minus 1 = -3

And as for the space:
>> X: 5
== 5
>> -X
** Script Error: -X has no value
** Near: -X
>> - X
== -5

unary minus is Negate (in R3). The R2 case certainly is weird:
- why should binary infix operators behave as prefix?
- why should binary infix - operator become unary prefix?

- why should unary prefix - operator have a different precedence 
than any "normal unary operator in Rebol"?

Only reason to have '-' as unary minus is to be free from having 
to write NEGATE all the time. NEGATE is good though in many cases. 
But having unary minus to have precedence over operators is weird, 
yes. I would be ok with having '-' as unary minus, if it didn't have 
precedence over operators. It should work just like NEGATE. Well, 
design decisions can be hard. :-)

I see it as, the symbol itself, being the binary infix subtraction, 
is what puts it on the same level as operators (not above)...  So 
I still see no contradiction...

And the reasons to not have a prefix minus:

- It's ambiguous with the infix minus, and we don't have a compiler 
to resolve the ambiguity.

- The special case of DWIM for a missing first argument slows down 
DO, and makes user-defined ops not work.

What's the best name for such a function?

f: func[words data][forall words [insert data make set-word! words/1 
 data: skip data 2] make object! head data]

or this one:

f: func[words data][forall words [insert data words/1  data: skip 
data 2] head data]

make-record

Oldes, I have them but in R3.

the first one in an aternative way to make objects.

as-object: func [w d][set w: bind? use w reduce [:first w] d w]

>>as-object [a b c][1 2 3]
== make object! [
    a: 1
    b: 2
	c: 3
]

I named the second one Mixin, with a slightly different code too.

mixin: funco [a [series!] b [series!] /local v][
    parse a: copy a [some [skip if (v: first+ b) insert v] a:]]
    head clear a
]

>>mixin "12345" "abcdefgh"
=="1a2b3c4d5e"

>>mixin [1 2 3 4 5 ] "abcdefgh"
==[1 #"a" 2 #"b" 3 #"c" 4 #"d" 5 #"e"]

I have ALTERNATE and MERGE at the lower levels. The first combines 
two series and returns a new series. The second merges one series 
into another, with a /SKIP refinement. I have TO-SPEC-BLOCK , since 
that's such a useful and common need. I avoided using AS- in the 
past, thinking more standard non-copying coercion funcs would make 
them confusing. Those haven't appeared, so I do use AS- sometimes 
now.

I've just found out from the mailing list that 'exclude creates a 
block of unique items.


so, unique block [block!] is the same as exclude block [block!] [ 
]


So, what's the best way to remove items from a block without making 
the first block unique ?

remove-each x data [find [stuff] x]  ; or whatever other criteria 
you want.

REMOVE-EACH is great. Watch out though - the return type has changed 
from the data block in R2 to the count of removed items in R3. Don't 
know why, Carl wanted the change.

It's modifying though, unlike EXCLUDE.

well, it makes kind of sense, I guess to return something else. returning 
a block from a modifying function seems a little bit like a "round 
circle" to me.

I suppose it's the cheapest thing to return and he thinks it's valuable 
information, so fine. I previously used REMOVE-EACH as a filter though, 
so it means more code for me in some (admittedly rare) circumstances. 
Overall, R3 code tends to be cleaner for most standard code patterns, 
though in some cases the best features are slightly undocumented 
(except in mezzanine code that depends on them).

it's probably a recurring code pattern for him

and now I made a round circle comment :-) (I talk way too much today)

For instance, in R3 (can't check R2 right now on this computer) comparison 
is allowed to unset! and error! values can be done with operators 
if the unset/error value is on the left side of the operator, but 
not on the right. This is because operators redirect to actions, 
and action functions are different depending on their first argument 
(single-dispatch). The comparison actions for unset! and error! can 
compare to other values, but the comparson actions of other types 
don't support comparing to error/unset. The action! function that 
calls the action has a typespec for its first argument that doesn't 
allow error/unset, but the op! redirects to the internal action, 
not the action! function, and it works because it uses a DO trick 
instead of a standard function call.

Arghhhh !!!! My Brain....

Sorry, that was awkwardly phrased. If there was a better way of explaining 
that to newbies that didn't require a full article, it would be in 
the docs.