World: r4wp

its dangerous because issues are very often used for hexadecimal 
notation.   this will complexify things for dialectors.

if the above is implemented, an  any-issue! type must be added to 
allow comparing both forms as the same type, when it doesn't matter.

overall, not sure the added confusion is really worth it.

yes, you summed up the issues, Max

Red has a dedicated notation for hexadecimal numbers

If you know it's a number, you shouldn't use a string issue for storage: 
that's wildly inefficient

With my proposal, you can parse numbers in issue notation, detect 
it's an integer and convert it to integer storage, without polluting 
the symbol table

Kaj, you're missing the point, in real life, the idea adds confusion 
to dialecting and probably very little benefits in real-life.  


very few uses require *only* first characters as numbers  IMHO.  
most will also use other chars as part of their dataset.

There definitely is a point. Please read the above discussion

Another thing: are natives more efficient than routines?

  Routines and natives are both Red/System code that use Red runtime 
  internal API, so they perform the same. In case of routines, you 
  might have a tiny overhead for integer! and logic! that are converted 
  back and forth between Red and Red/System, but it is really very 
  small, and only significant if you iterate a lot of times over a 
  routine call.


From the memory and boot time perspective, natives are more efficient 
because their body block is not stored internally  for reflection 
like routines. So, for functions like QUIT that should be part of 
Red core, it is better to implement them as natives, to save memory 
and booting time.

Until SMS texting there were very little words spelled with numbers 
in them.

Doc, thanks for the explanation. About reflection, will there be 
a compile option to turn it off, for commercial code that should 
stay closed?

It may also be useful to turn it off per function, for example for 
being able to write routines almost as efficient as natives

Sorry to change topic from the current issues (pun intended), but 
I wanted to say thanks to Doc and Kaj for the information about graphics 
on Red/System on Linux running on ARM!  Where could I download the 
GTK.reds file?

Sorry if the answer is obvious and I just missed reading it somewhere.

http://www.red-lang.org/p/contributions_20.html

You also need the Red-GLib and Red-common repositories which aren't 
listed there

Where would I find those?

In the same place, using the same name pattern

About reflection, will there be a compile option to turn it off, 
for commercial code that should stay closed?


What I planned so far is a compile option to switch between different 
modes of bundling the functions/routines source code into the final 
executable. Main options are: 

- in form of native "build instructions" (the current behavior)
- in form of compressed text


The latter option will generate smaller executables, but will be 
slow down boot time a little, as it will require the interpreter 
to process it. The former option provides a high level of obfuscation, 
that requires a lot of work to decompile (cracking REBOL's SDK protection 
is probably an easier job).

interpreter => tokenizer

Hm, I guess interpreted functions make it hard to leave out the source 
in some form. That would be another argument for being able to designate 
it per function

Actually, every statically defined Red function will get compiled, 
only functions created at runtime will be passed to the interprerter 
(or JIT-compiled).

Yes, but the source is still included for reflection, isn't it? That 
could be removed

So the "interpreted functions" do not exists at compile-time nor 
in the executable in source form, as their are created at runtime.

they

what about function argument, like in Rebol? I mean, those catch 
etc. arguments?

I thought the source is added as extra for body-of?

We could remove the body block of compiled function! values, yes, 
so it doesn't get added to the executable. That could be an optional 
switch that would also disable undefine 'body-of accessor.

Yes, that's exactly what I mean

Pekr: I don't understand your question, could you be more specific?

Doc - Kaj wants some option to trigger functions being complied in 
various ways. I just said, that maybe it can be done on per function 
basis, using special parameters ...

my-func: func [[dynamic] a [integer!]][]

Yes, I was also thinking in that direction

The problem might be, that it has to be decided during compile time, 
so the source code would have to be analyzed. Otoh it might be the 
right place (instead of preprocessor) to fit in, along with catch, 
throw ....

You can still define it at runtime in such case, instead of statically 
define it. No need to add another attribute.

Functions created at runtime will always retain their body block.

You will be able to achieve that using different approaches:

1) Using DO: do [foo: func [...][...]]

2) Indirectly specifying the spec and/or body block: 

    body: [...]
    foo: func [...] body

This will result in 'foo function been created at runtime (then JIT-compiled 
or interpreted on each call).

Kaj: you should add your syntax proposition for keyword! + issue! 
to github tracker as a wish, so we don't forget about it.

If we don't find any big drawback, I think I will implement it.

OK, thanks

Added routines invocation support to interpreter.

Congratulations: the rhythm of changes in Red is just fast!

I scripted a little command that I run from time to time, just to 
see how both Rebol3 and Red are going:
cd ~/dev/Red/ && git pull && cd && cd dev/r3/ && git pull

And I can see through gitk that the rythm of Red's work is just amazing. 
Courage!

Merci Pierre ! :-)

De rien, merci à toi!

I cannot really find a startup guide for Red: so, if no one shouts, 
I'll try to write one, during my long hours of flight next week.

That would be good

ok, then!

Pierre, have you scrolled down throw this page: https://github.com/dockimbel/Red
?

through

Let me know if there are missing information there.

I had read another version of these instructions; it looks like it 
was reworked a bit.

Yes it was, the Red/System README was merged in Red's one.