World: r3wp

No Brian, you won't because Carl already made the change in alpha 
39, and is currently writing DECODE.

Even my compromise from the last time you brought this up was rejected. 
TRANSCODE/error and codecs is what we got. Live with it.

I'm doing it with well meaning intent.  I really do struggle trying 
to get young up and coming university students to give REBOL the 
chance I know it deserves.  And sorry Brian, I've haven't tried A39 
yet.  I'm still running the A33 for Linux.

Well, I already rewrote LOAD to take advantage of the TRANSCODE changes. 
It should go in the next build.

This includes LOAD/next, btw.

Like LOAD/header, it is better than R2 :)

This is very cool news ... I'll crank up wine again on an a40.exe 
to see ... time to catch up with recent developments again.

I think upgrade works with the Linux version now, and there are Linux 
builds on the releases page.

Even cooler news from the upcoming LOAD:
>> load ["print 'hello" "print 'there"]
== [[print 'hello] [print 'there]]
Works with files and urls too - Carl's idea :)

uh ?

I've been trying upgrade ... just did a minute ago ... it stashed 
an r3-a40.exe  so I wouldn't have bothered to look ... but am now 
as you made me all keen and curious.   And yes, the releases page 
has updates I didn't notice.

Thanks Brian

LOAD of a block will treat the block as a collection of things to 
load, so it will load all of them The code is this:
    map x source [apply :load [:x header next all unbound]]

Yeah, the upgrade returns anLinux binary with a Windows name :)

an -> a

ahah i was about to said it was a shortcot for
map str ["print 'here" "print 'here"][load str]

to slow

Yup, except with APPLY so the refinements can be propagated.

MAP and APPLY are native in R3, as fast as FOREACH and function calls, 
respectively.

map is currently underated, it's a really cool function

Even as mezzanines they would be useful, so MAP and APPLY are part 
of R2-Forward as well.

I use them in R2 every day :)

Well, APPLY more often than MAP, but still.

I still don't see the performance hit of a lexical scanner that defaulted 
to 

make foreign!"" - One word, backtracking. It needs MAGIC to do what 
you want. MAGIC is expensive.

Furthermore, I don't believe that this would attract even one more 
user to REBOL.

Well put :)

To be honest, i can see his point.

If instead of failing on the first error encountered, we could have 
a load-foreign which accept a user call back function, each time 
an error occurs.

Then, we could do some  handy conversions meanwhile the loading process.
Don't say it would be a useless thing guys.

it's easy to simulate with transcode and parse but we need speed 
here

Failure is your friend. If it doesn't fail on errors, you can't trust 
the output and yo have to do the error checking in your code.

i'm not talking about the standard behavior of LOAD here

But he was.

I'd say there is a case for adapting Rebol's vocabulary, eg:


 measure! - proposed a long time ago - 2cm 3.4cl 5o (degrees) 1em 
 - found elsewhere, eg CSS

 date! - recognize some common alternate constructs - 12-Mar-2009T04:00
	money! - the suggested: $1,000.00


I'd love to see Rebol mature along these lines.  The literal types 
are the essense of Rebol's being, they make for expressive problem 
solving and efficient data exchange with some resemblence to terms 
we would use on paper - all with 'load as its core arbiter.  It'd 
be great to be able to extract meaning from any stream of data, and 
I think if any language can, it's Rebol - however, it just seems 
beyond the scope of 'load which has this specifically and valuably 
defined purpose.  Whereas 'parse can be used to describe anything! 
- even if you load junk!, you're still going to need 'parse to make 
sense of it...

callback on error
 - how is that different from using PARSE and LOAD/NEXT ??

Chris: that is a whole different issue. , in numbers does not work 
because REBOL allows 1000.00 and 1000,00 to be the same thing, though 
with some euristics we might be able to make that work. euristics 
are bad for a language's lexicon though. instead, like to date! does 
(wrt load) I'd rather have to decimal! (etc.) to be smarter.

Has someone done some test with a JIT library ?
For example to be used with a little VM to replace rebcode ?

As I see the problem, it would be:

1/ create a compile function in Rebol using parse to translate a 
dialect into some bytecodes.
2/ call an external (dll or so) tiny virtual machine.

3/ The VM uses a JIT libray (ie. AsmJIT) to convert the bytecodes 
into ASM instructions.
4/ the VM execute the code

could be faster than rebcode (especially the loops)

Well if your going to go that route why not just use REBOL to create 
a MACRO language that outputs assembly code?  That would be rather 
easy to implement.

want to be done in real-time, with a jit library. Not with intermediate 
files and slow compile time

need to inject code

SLOW compile time?  Assemblers are using macro's already and compiling 
extremely fast.

but how do you inject code in your running application without a 
good framework to do that.
You can't just throw a bynary stream in the heaven

I wasn't objecting to your comment about injection.

I'm not agreeing with it either.

But if that is what you desire go for it.

give me a dll wich accept a binary stream and run it as a function 
and i'm ok to generate assembler with rebol

*which

Go for it Steeve.

Gabriele: "callback on error" - how is that different from using 
PARSE and LOAD/NEXT ??

It's *much* slower (according to Carl). That is why he decided to 
handle this with TRANSCODE/error (which returns the data so far, 
an error object, and the next position), rather than TRANSCODE/else 
on-error (which would have called the provided on-error function 
when there was a parse error).

Gabriele; Ahh ... lights are coming on.  MAGIC lights.   ;)  Ok, 
I can see how the success backtracking could lead to more grief than 
I originally imagined.


So now I'll shutup on this ... until we see what comes of user types 
(if we get 'em) mixed with transcode/error.  Could be cool.