World: r3wp

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.

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.