World: r4wp

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.

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.