World: r3wp

so, I have to insist, that everybody using strings instead of words 
deserves every disaster he gets for not adhering to documented "best 
practices"

Those who don't use LOAD are condemned to reinvent it, badly :)

Has to do with implementation of this function: http://github.com/hostilefork/Rebmu/blob/master/rebmu.r#L448

Instead of [REMAP-DATATYPE email! email? "em"] I'd like [REMAP-DATATYPE 
email! "em"], but was confounded in trying to figure out how to write 
a version of that which worked reliably.

just BTW, an expression like

    is-email-addr: get bind load "email?" bind? 'system

can be expressed using a shorter form

    is-email-addr: get bind load "email?" 'system

, which is, in fact, the same, as:

    is-email-addr: get load "email?"

this is something curious I just noticed.

If you pass a file as a parameter to a rebol program on the dos command 
line it works
but if you do the same in a dos batch file, it does not

eg:. script.exe %/c/rebol/myfile.dat

works from the dos command line

but to get it to work in a batch file you have to do this

script.exe %%/c/rebol/myfile.dat

I presume it's because the command processor tries to do a substitution 
using the %

That would be it.

%
 is the variable begin/end tag. ie:
	C:\> set directory=c:\windows
	C:\> dir %directory%


But in batch file, it's also the begin tag for a "number" variable 
equal to the n'th parameter of the script. %1 for first param, %2 
for second... ie:
	C:\> type mybatch.bat
	dir %1

	C:\> mybatch.bat c:\windows

So, is there any other way to escape the % ?

I though escape char was ^, so let's try "^%"

Not in a batch file .. doesn't work

that's the Rebol escape char

http://tinyurl.com/3amb3zh:)

%% is a typical answer, since doubling the escape/meta character 
is usually sensible.  Well, to the extent that batch files are sensible.

I guess it was a good guess then :)

>> f: func[][ print "kuk" make error! "bla"]  f
kuk
** User Error: bla
** Near: make error! "bla"


Is there any way how to get something more useful in the "Near:" 
part of the user error?

This will get you a "near f" message and an arg1 code of 404, but 
 not an error of type 'user --- is that more useful?
    f: func[][ print "kuk" make error! 404]
    if error? bad: try [f] [probe disarm bad]

no... it isn't. the neer is again just [make error! 404]

Sorry....my mistake. 
    'near is '[make error] as before
but
    'where is 'f (rather than none)
So _slightly_ more useful?

Yes.. that's true.. but in real life I need more complex message 
instead of "bla"

f: func[][ print "kuk" make error! ["complex" 9999]] f
'where gives you 'f

'near gives you a whole block -- lots of room for a complex message 
:)

it's not so easy as it does not allow to add some variables... for 
example:

>> f: func[][ val: random 10000 make error! reduce ["complex" val]] 
f
** Script Error: Invalid argument: complex
** Where: f
** Near: make error! reduce ["complex" val]

>> f: func[][ val: random 10000 err: reduce ["complex" val] make 
error! err] f
** Script Error: Invalid argument: complex
** Where: f
** Near: make error! err

I use:

>> f: func[][ val: random 10000 make error! reform ["complex" val]] 
f
** User Error: complex 7367
** Near: make error! reform ["complex" val]
but would like to change the neer to place where the f is called

but maybe the user defined errors are not suitable for that

you can use an object spec block to define errors, but you have to 
know proper codes or else the error won't build itself.

is there a way to get access to the main script's header within code 
you execute using 'DO

when I 
do %source.r

and source.r defined as:

 print system/script/header/title

I get the title of the source.r file... not the main script.

well after a little bit of screwing around I came up with this function:

	;-----------------
	;-     get-application-title()
	;-----------------
	get-application-title: func [
		/local script parent
	][
		parent: system/script
		until [
			script: parent
			parent: script/parent
			none? parent/header
		]
		script/title
	]

f: func[[catch]][print "kuk" throw make error! "bla"]  f

>> add 10 50%
== 10.5

Hmm, I find that a little disappointing, it would seem that if one 
is going to bother having a special datatype for percent it would 
come out as 15.

percents represent the amount, its not just an alternate notation 
for decimal, like tags for strings.

You are missing a multiplication.

Well, I know, but I just mean that if functions can detect what types 
they get then making [add (something) (percent)] do the same thing 
as [add (something) to-decimal percent] seems a little less exciting 
than if it "knew what you meant".  There's sort of a dimensional 
analysis thing... adding integers and percents doesn't make a lot 
of semantic sense unless you're speaking about adding a number to 
a percentage of itself.

There was very long debate on this, when percents were implemented 
and this is the result and you should have to live with it.

Well, you are assuming that 10 is what the 50% was supposed to apply 
to. REBOL can't make that assumption - it has to do whatyou tell 
it to do, not what you want it to do.

Unless you want all numeric operations on the percent! type to include 
implicit multiplication.

http://www.wolframalpha.com/input/?i=10+%2B+50%25

Yes, Fork told REBOL to add 50% to 10. And result is 10.5 ...

OTOH: http://www.google.com/search?hl=en&source=hp&q=10+%2B+50%25&aq=f&aqi=h1g10&aql=&oq=&gs_rfai=

But if you asked me whether to go to Google Calculator or Wolfram 
Alpha as the source for mathematical intuition, I'd choose the latter 
myself.

Yes, but he told  to add 50% of what to 10? That's the missing multiplication.

It's an issue of mathematical intuition, which I do believe is established. 
 "That'll be 19.99... plus 12 percent tax"

Hey, it's early enough, make a proposal and submit it to CureCode. 
Be sure to check first to see if it's already there though.

Well it doesn't matter all that much, easy enough to work around. 
 I just wish Rebol showcased a bit more of its ability to have the 
cross product of behavior across types in examples where people would 
go "whoa, how'd it do that?" then... "oh, I see..."

One decision that I used to not think much of one way or another 
which I now really think is important is the idea that "none" is 
false? while 0 is not.

And remrmber that the mathematical intuituin you mention isn't the 
same if you swap the arguments. Note that Wolfram swaps the arguments 
back if you put the percent first. That is because the intuition 
for 50% + 10 is that it result in 60%.