World: r3wp

it depends on what stupid behavior is. :-) I guess it can scan for 
things like "probe system".

:)

Why does this work:
 	if (to-money bal) < (to-money $0.00) [break]
but not this: 
	if (to-money bal) = (to-money $0.00) [break]
when looping through results that include $0.00

for example my results data looks like this:
$5578.00
$4190.45
$2798.27
$1401.46
$0.00
-$1406.13


If I try to halt at $0.00 comparing with '=' it does not stop but 
if i look for '< $0.00' it catch it as soon as i go below $0.00.

are you sure it's not just ignoring the break?

math conversion error

Why would it ignore the break? I've tried other things like print 
statements to test if it sees it..but it does not seem to see it..

where is your data coming from?

this is the issue ...

>> $0.00 = to-money 0.0000001
== false

try ..

$0 = round/to bal .01

you are the man Graham! That works! Thanks again.

>> $0.00 = round/to to-money .0001 .01
== true

Rebol internally maintains the precision ... so what you see is not 
what you get

That makes sense now, thanks.

from !REBOL2 --> 

Gregg said "I wouldn't want to lose lit-words, but they do create 
issues at times."


I also don't want to loose lit-words (it they are what I thinkt they 
are). Isn't lit word 'this . which get's ecaled via do dialect to 
just word. I also don't want to loose that in no way.

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]