World: r4wp

I am probably too influenced by the way Carl designed R2

Funny, I am probably too influenced by Carl's assessment of R2 after 
using it for years and thus having realized that certain of its design 
decisions were actually mistakes that need correcting.

Ladislav, don't quibble about "return" vs. "trigger"; you don't know 
yet how errors will be implemented in Red. In R3, for instance, errors 
are triggered by being returned internally. Try to keep the arguments 
on topic :)

Ladislav, I didn't say triggering an error wasn't stupid, I said 
that it was less stupid because it was louder.
 - yes, that is correct, I do agree with you

Re "influenced by Carl" - I think that it is good to strive for simplicity, 
however, indexing is not simple when index arithmetic does not work

And, yes, Henrik's solution using AT could be considered a 1d) solution 
for Red in case the functions will work as he indicated

BTW, 0 is the reason why many arithmetic algorithms work, so getting 
rid of 0 helps only to get back in time before 0 was invented, to 
the time when those algorithms did not exist. (the word algorithm 
itself is actually pointing to the city where a zero proponent and 
matmenatical giant Muhammad ibn Musa lived).

FYI, it means at least 1282 years back in time, but, actually, much 
more, taking into account that even before some nations used 0 successfully.

'Ladislav, don't quibble about "return" vs. "trigger"; you don't 
know yet how errors will be implemented in Red.' - I wrote that in 
hope there will be some reasonable compatibility with REBOL, but, 
you are right, that I should not...

All that matters is how it appears to work from the outside, not 
how it works internally :)

However, in REBOL (no matter how it is implemented) there is a difference 
between "returning an error" and "triggering an error". A compatible 
implementation would need to maintain such difference, I guess.

This does not have anything in common with "how it works internally".

While it's too late to keep all this chat out of the Red channel, 
if you would all like to continue this very specific discussion, 
I will create a group just for that.

Thanks, Gregg

Preliminary support for Red functions (please read the commit log)::


https://github.com/dockimbel/Red/commit/cc5c8dcb839572bb25559f964ed7d30419cb5a31

That's great Doc!

There's an entry missing in the commit log:
- dynamic function creation is not yet supported.

Cool, now it's a real programming language

I like the plan for FUNCTION

This is a great new Doc ! BTW why  use /local refinement ? Don't 
you think that would be better to have words local by default, and 
to use /global when needed ?

Such model would not work with lexical scoping. For example, you 
wouldn't be able to access words from parent object from a function 
because you will be only able to define local (to function context) 
or global context words.

and using something like /external instead of /global , meaning that 
the specified word is somewhere in parents context ?

It doesn't scale well, and as you can see in the following example, 
it can quickly get nasty:


    [/external obj1 [a b] /external obj2 [c d] /external obj3 [e f] /global 
    g h]

thanks for explanation. Having vars locally by default is one of 
the few nice aspect  of php. But as you said, in objects methods 
probably this leads verbosity.

You can't arbitrary pick a feature in one language and drop it in 
another one and expect it to have the same benefits...especially 
when they are so different. ;-)

That design note would make a great doc entry somewhere. Is there 
a Red wiki where we can stash these things, or what would be the 
preferred method at this point?

Davide, FUNCT in R3 declares all set-words in the code block as local 
by default. The commit comment says that Red's FUNCTION will act 
like that.

Doc, will FUNCTION have some of the other options that FUNCT has? 
(Feel free to adopt the FUNCT code: I wrote it.)

Now Red supports 21 datatypes. In the following R3 datatype list, 
datatypes with a minus prefix are not supported in Red yet.


action -binary -bitset block char -closure -command datatype -date 
-decimal -email -end -error -event -file -frame function get-path 
get-word -gob -handle -image integer -issue -library lit-path lit-word 
logic -map -module -money native none -object op -pair -paren path 
-percent -port -rebcode refinement set-path set-word string -struct 
-tag -task -time -tuple -typeset unset -url -utype -vector word

just a note: there is absolutely no need to support the end! datatype. 
REBOL doesn't support it either, in fact.

Jerry, I am not sure, I would post such a list, especially to Red 
FB channel. It looks almost discouraging. How will you measure the 
quality of Red e.g. running on ARM, and R3 not?

Moreover - Red is not a clone of R3, some things might be done quite 
differently in the end imo ....

Jerry: command!, end!, frame! and rebcode! are very unlikely to be 
adopted in Red. Also following will probably not be part of Red too 
(or not in a near future): event!, gob!, handle!. Meaning of decimal! 
will most probably be changed, float! or real! will be used instead. 
Money! will receive a different treatment than in REBOL (number of 
digits after comma will probably be adjustable).


Also, expect the return of hash! in Red, and new datatypes that do 
not exists in REBOL.

As you can see, it is not a 1-1 matching between Red and R3.

Routine! will also probably be back in Red.

I agree with Peter, you can't measure Red's progress by taking R3 
as a target goal. It is better and more accurate to measure progress 
by counting what is built in Red.

struct! doesn't work in R3

task! seems to work half or so

As far as I know, utype! doesn't work

rebcode! is not implemented in R3

Doc - interesting - I know you have no intention to port View, but 
what about other types of events? Will not be there an event type? 
I want my wait-list with various events - networking, serial port, 
whatever :-)

Kaj, rebcode! isn't really in R2 anymore either. But the mechanism 
that was used to make rebcode fast in R2 has been implemented in 
R3, and it used by the R3-GUI dialect. Anyone could implement their 
own rebcode if they like, even with improvements. That mechanism 
would be worth supporting in Red.

Hopefully less buggy too. The rebcode dialect caused a lot of crashes 
and security holes, which is why it was removed. The new mechanism 
doesn't have that problem.

Petr, I haven't decided yet how events will be presented to user, 
there are different possible options and the choice will depend on 
the implementation constraints. Once we have the I/O + tasking implemented, 
we'll see what interface is the best for exposing events to user.

Too bad about command!, that function type is the best one for pluggable 
JIT compiled function models. There are other advantages too.

Let's not rehash the hybrid extension conversation though :)

For handle!, what type are you using to be an opaque pointer-sized 
type that all pointer operations are prohibited on? Can such a thing 
be typedefed?

If you had an ability to create an opaque value of any size that 
will fit in a value slot, or maybe just limited to pointer size, 
only accessible from Red/system code, that would be a good replacement 
for handle!.

I haven't decided on that yet. I need to implement first the type 
marshalling interface between Red and Red/System and see then, what 
is the best option.

Interesting info, Brian. However, I wonder what rebcode! would be 
needed for when you can inline Red/System

The advantage to rebcode isn't that it's fast, it's that its semantic 
model is similar to assembler. That makes it useful for a lot of 
interesting problems. Also, there might be times when you don't want 
to allow Red/System to be inlined - it's basically the same as unsafe 
code in C#, with the same security characteristics.

Yes, but RebCode is aimed at an interpreter. In Red we can make any 
safe dialect we want that compiles to Red and/or Red/System