World: r4wp

What's not implemented here? The problem seems to be in the series 
string! argument

Do we post Red/System questions here as well?


Kaj, is your example for Red or Red/System?  I think you're talking 
about Red.  If it's Red/System, 'tail? is not the way you check to 
see if you're at the end of a c-string.

But I know you know that.  I just wanted to see if I am getting a 
handle on Red/System... ;-)

It's about Red, as can be seen in the compiler output header

This place is definitely also for Red/System questions. It's only 
since shortly that Red is here to ask about :-)

It would make it easier to port existing REBOL systems that make 
extensive use of issue!

 - this does not look smart at all, there were discussions about this 
 when R3 design was discussed. There was no significant mention of 
 such systems when the decision was made.

I never thought the change to issue-as-word was any improvement. 
 I still wonder what is fundamentaly better about it.  IMHO issues 
are meant to be datas.  they used to be promoted like serial numbers 
or tag labels.   


AFAICT only pre-processing tools use them as keywords... because 
they stand out.   but in such cases, the actual amount of issues 
is so low, that any memory saving it would be for them to be words, 
is virtually insignificant.

Kaj, this works for me:

Red[]
empty?: func [s [string!] return: [logic!]][tail? s]
if not empty? "string" [print "full"]

using the latest commit under OS X

... and even when I change s to series

Did you mean to use  function [] instead of func[] ?

One reason it would be bad to adopt a different literal form for 
the issue! datatype from REBOL (whether any-word! or any-string!) 
is that it would make it more difficult to exchange data between 
REBOL and Red.

Peter: I agree partially with your last argument: it wouldn't change 
anything about data exchanging with REBOL (as the literal #... form 
exists in both languages), but it would make some code testing for 
issue! (vs keyword!) incompatible between them.


The point in making issue! work as a word is fast comparison wherever 
it been used as a keyword or an ID (usually used for lookups). It 
is not a trivial performance difference, it is between one and two 
orders of magnitude faster with words than with strings.

Re-read Carl's blog about it: http://www.rebol.net/r3blogs/0108.html

Kaj: about EMPTY?, no problem here, your code compiles and run fine.

The problem is gone with the latest update from Git

Peter, no, I did not mean to use FUNC. I like to standardise on the 
full, comfortable form. In a compiler, the overhead is no problem

Is

empty?: :tail?

not supposed to be supported yet?

No, it needs specific support for functions. EMPTY? definition needs 
to be caught by the compiler to populate its internal functions table.

Function support will be completed once objects will be added.

OK

Note that most respondents to Carl's old blog liked to keep issue! 
as is

From there, how about \ as a prefix for keywords?

As preproc directives such as #if should stand out, it will be hard 
to find anything better than #.

there are still § & ~ unpopulated and without a special meaning .)

Note that § is not immediately available on US keyboards

and & is a word character

An altenative for preprocessor command could be
.if
(It starts in column 1 doesn't it?)

On the other hand isn;t it possible to get the meaning from the context? 
#if #define etc could be preversed preprocessor words?
(or I am on a complete other level again this time)

preversed=preserved

(The sz sign i a bad choice as is the ¤ or the & ^ * @ and Euro sign 
together with all backets and braces.)

#if# ?

#1 2# if one needs it as a string, I consider current Rebol behaviour 
as confusing:
>> probe to-string probe to-issue "1 2"
#1
1 2

in my case I used issues only as preprocesor commands and for storing 
color values in my dialect (which I could replace with the hexadecimal 
number which is in Red already)

Carl's post was interesting because (and I think this is true for 
Carl in general) he sees himself as a regular REBOL user, so when 
he decides on a design point, he extrapolates that to general use. 
Fortunately, his choices are generally very good. :-) In this case, 
he was the one who set the precedent of using issues as keywords, 
which I think came from familiar syntax for them in other languages.

My question then, as now, is what are the benefits, what do we give 
up for those, and what are the alternatives? I do think the # sigil 
is U.S. centric, so it works for me. It may not make sense in other 
parts of the world.

I like things that are different to look different. But we don't 
have many goods chars left as leading or bracketing sigils, and I 
don't know if Doc has anything planned for those (e.g. [! @ & ~ | 
_]). 


The doubling of a sigil, to me, seems more like something we want 
to use as a convention, not a datatype. But the real question is 
what value each datatype adds. I've asked Carl a few times about 
a marker! type, for use in tagging locations in documents. Good chars 
for those are not easy to type († ‡ §), but could have mappings from 
(+ ++ $ $$). And now hashtags are a widely used meme. What lets us 
add meaning and clarity to the things we write, beyond just code. 
I still think REBOL's great success in expression comes from the 
fact that it was designed for data exchange.

Note that most respondents to Carl's old blog liked to keep issue! 
as is

 I just see people expressing irrational fears... I was pointing on 
 this article to refer to Carl's statements about issue! which I completely 
 share: 


It was a good attempt, but rarely, if ever, has it been used. Normally, 
we use strings for those types of values. Instead, the issue datatype 
has gained usage as a meta keyword.


Also, I fully agree with him that having issue-as-word is more helpful 
than having issue-as-string.

I agree with Andreas, the change to issue-as-word (== keyword) has 
been motivated mainly but preproc directives, so, we certainly don't 
want to change their syntax, there is no problem there to fix.


My question was about adding or not an issue-as-string datatype and 
what literal form would it then have.

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.