World: r4wp

Actually re-reading Gregg post above about # sigil been US-centric 
and the popularity of hashtags, it seems to me even more interesting 
to rename issue! datatype to keyword!.

hmm, from compatiblity to Rebol point of view, is the rename needed?

Which Rebol are you referring to? R2 or R3?

You should be aware that you will never have a 100% script compatibility 
between R2/R3, R2/Red and R3/Red. This means that migration tools 
would be required anyway for R2 scripts. Adding some rules to change 
issue! to keyword!, issue? to keyword? and to-issue to to-keyword 
is really not the biggest show-stopper.

As for me, don't bother adding another issue-as-string. I won't use 
a syntax that's not compatible with natural language. I'll have to 
do string processing and convert the original issue! syntax to string!

string parsing

quit: :halt
q: :quit

How come this works in console? Is it because they don't take arguments?

No, it works because it is interpreted, which is an execution model 
very different from static compilation. In the interpreter, there 
is no need to make internal tables for functions or variables, they 
are simply resolved at runtime.

That is why the interpreter will be useful to fill the gaps that 
are too complex or too expensive for the static compiler to cover.

The JIT-compiler will also be used to fill those gaps when it is 
more effective than the interpreter (mainly code with loops).

OK, I wondered because this code is compiled, before the interpreter 
is started

Ah, if it is compiled, let me see...

Ok, same answer. :-)

:-)

The compiler generates code to pass the function! value from :halt 
to quit:, then the interpreter evaluation `quit` by analyzing its 
value, detecting a function!, then processing it.

evaluation = evaluates

The compiler needs to do that at compile-time, so it needs to recognize 
what is a function! call and what is not.

Doc, in your opinion, is Red/System mature enough to write graphical 
apps in Linux on the Arm processor?

Red/System is in beta stage. Whether or not it is a good choice for 
a GUI app is matter of personal taste. I personally gave up building 
GUI apps in a C-level language a long time ago. However, if you want 
to give it a try, I recommend you Kaj's GTK+ binding, which now works 
fine on Linux ARM, as shown here: 

http://static.red-lang.org/rpi-gtk-widgets.png

You can see the source code for this GTK+ demo here:

http://red.esperconsultancy.nl/Red-GTK/artifact/3453dd410a1c64ca8f842f75c7431b6f7fc3c4b3


As you can see, Red/System has some limited dialecting capabilities 
that Kaj leveraged to build a very nice GUI dialect (which is quite 
an achievement for a low-level language).

Thanks Doc for sharing this information and Kaj for doing this GUI 
binding, paving the way for newcomers and sharing the source for 
deep study. When I will be going back to my former status (more free 
time) I plan to deeply study Red/System in parallel with the C language 
just to be able to write some small doc (or book) to help newcomers 
to start with Red/System after coming from the C environment. In 
fact it's a long time I planned to do it for myself first but never 
found the time to do so when I worked as a teacher in the past. Now 
I hope I will better drive my diary to cope with this new planniing 
!!!

Doc or Kaj, do you think it would be usable on my Android tablet 
- since it uses Linux on Arm as basis ? Already I can use the R3 
port from Cyphre and the console is working fine. The single problem 
I see for now is that the Red/System app is still not working on 
my tablet ... but I suppose some time in a near future this will 
be a thing of the past. Bue Doc I don't tell you this so you feel 
yourself as if you would put more time on this issue. This is not 
even disturbing me for the moment sinc in any case I don't have much 
time left for now - so even if it already worked I couldn't use it 
anyway. It's damage I don't know more by myself about all these new 
computers and environments but I have to think I'm not alone in this 
case ... Regards

Keyword! sounds much more like it means a reserved word in the language 
to me. 

issue!
keyword!
label!
marker!
cue!

Still, I'm sure I could get used to keyword! as it could be interpreted 
clearly in the different contexts where issue! is used today.

If used as keywords/hashtags in messages (blocks), would they be 
better as word! or string! values? Limits versus speed I suppose.

Gregg: (I'm not sure if I understand your question correctly) If 
you use an issue! as a keyword/hashtag, it will be better for issue! 
to be a sub-type of word! rather than string!.

Gerard, Red currently works better on generic Linux for ARM than 
Android. All support for Linux is available on ARM, but Android is 
quite different

It's possible there's currently a problem with Red/System on Android. 
Can anyone confirm this?

Other than that, many of the libraries that I bind are not or not 
easily available on Android, so functionality is currently more limited

A possible cause of the hello app not working on Android anymore 
is a mismatch between the output encoding of Red and the expected 
one from the Java wrapper. I will check that when I'll start working 
fully on the Android port.

I can't push to GitHub because it requires a Git version newer than 
the one available in my Ubuntu of only a year and a half old

At least, that's what it seems to mean when it says error 403

Got it working through SSH instead of HTTPS. I spent a whole day 
setting up GitHub to be able to fork and push Red contributions

Doc, what I meant was, if you use blocks as a message structure, 
you include issue! values as hashtags, you gain speed and storage 
efficiency. But you may also hit limits. Suppose you have a blog/chat/tweet 
system, how many unique issues can you have without blowing a symbol 
table if they are words?


Not saying they shouldn't be words, to be clear, just making sure 
I know how to use them correctly. :-)

Limit for symbol table is available memory, but it would be a bad 
idea to make the symbol table grow too big with current implementation, 
it would slow down a lot addition of new words. This could be addressed 
by using a more sophisticated internal data structure in the future.

Actually, the worst case is if you have massive number of issue! 
values and doing transformations of them (insert / remove operations). 
In such case, you should use string! and convert to issue! once transformations 
are done.

Great. Thanks Doc.

Would empty? and zero? be suitable to add as functions, or should 
they be natives?

As there are frequently used, native is probably a better choice.

I'll leave them in my Fossil repository, then. I have a function 
for empty? and a routine for zero?

there = they

My brain came up with a solution for issue! while I was sleeping. 
It's a notational problem, so how about having both issue! and keyword! 
start with a # but when the next character is alphabetic, it's a 
keyword, and otherwise, it's an issue!.


This is consistent with both issue notation in American English and 
preprocessor keywords in C-like languages.


It's an easy rule for the lexer, and a relatively easy rule for humans, 
that is intuitively clear.


It optimises keyword use for speed, while preventing memory leaking 
into the symbol table for almost all issue notations.


It's unlikely that someone has issues starting with an alphabet character, 
but when they do, most cases will be transparent. In other cases, 
only little code needs to be added to handle them as keyword!.

It's unlikely that someone has issues starting with an alphabet character


Serial ID, product keys, etc... often start with a letter. From the 
implementation POV, your proposition is fine to me.

I'd be willing to make that sacrifice to have the other cases solved

Any thoughts about callbacks in Red?

Another thing: are natives more efficient than routines?

Hmm, Kaj's issue idea sounds quite good, from an implementation perspective.

It may be a bit counter-intuitive that #dd64cc4f-1859-4c2d-86ff-31400868ec14 
and #033168aa-b7b1-413d-a57c-01f9c469d3b3 have vastly different performance 
characteristics when it comes to comparison. But maybe that's really 
the tradeoff worth making.

- hmm, that looks hard to document/keep in mind, however. Those two 
cases would then look as different datatypes, having only some "artificial" 
syntactic resemblance, though (I am not strongly against it, but 
it is not usual...)

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.