World: r3wp

you mean like following, which we have for ages? :-)

>> $10'000'000
== $10000000.00

amacleod, we've been discussing FORM-DECIMAL for a while in this 
very group. Scroll up to see.

Pekr, that works but  would prefer commas...
but can you go the other way:
	>>$10000000
	==$10'000'000

Thanks, Henrik, I'll have a look..

REBOL uses the French Swiss currency format (how neutral can you 
get?), but I agree that default formatting to include group separators 
in the console would be nice.

Hmmm.... http://www.articlesbase.com/banking-articles/no-deal-for-us-on-usb-names-1795473.html

Is it intended that some binaries read with LOAD, should return an 
empty block? REBOL/View 2.7.6 here.

Interesting:

>> load read/binary %file.dat
== #{
0000100000001D81000076100000766700007D7E00007F6C00007FB300007FF2
0000805B000080CE00008166000081B100008293000082F10000834A0000...
>> load %file.dat
== [
]

Depends on what's in %file.dat, the whole file, not just the beginning 
of it.

LOAD in R2 has several bugs and design flaws - not sure which is 
which - which probably can't be fixed due to compatibility.

Thanks for the input Brian. I've spent many an hour trying to figure 
out how "load" behaves.

So did I, when I was writing LOAD for R3, fixing the aforementioned 
bugs and design flaws.

Working on LOAD this week, actually. Already fixed one bug earlier, 
now working on a tricky blog request.

load in R2 has even returned a word! datatype to me !

(on a binary zip file)

Wouldn't do so in R3 unless the zip file had some contents somewhere 
in it that resembled an embedded script-in-a-block. Zip files occasionally 
have uncompressed data, so that can sometimes liik like an embedded 
script.

Well, I can reveal that the example is an encrypted SQLite file. 
I could hand it over to BrianH or Carl for debugging?

what were you expecting to find?

I think it's often more preferable to parse the data rather than 
load it ...

What hapens if the data is corrupted by a disk error ?

LOAD should be a quick way to tell whether I'm loading REBOL valid 
data or not. Returning an empty block for an unknown 1 MB binary 
isn't appropriate, because the outcome is suddenly loadable.

is there anything like a lint tool for R2 ... even some simple scripts 
or tools?

do you mean link tool?

lint is sometimes called a program that looks at your code and warns 
you about any potentially stupid behaviour you did

ok, I don't know any tool like that. I think that might be quite 
hard to build for REBOL.

well it's not ultimative .. it could do just some sanity checking 
of things that are possible

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.