World: r4wp

It means pound on American keyboards. Maybe they don't use the character 
for that in England. We just use lb here now.

UK keyboards also have the "#" character. And  it's unshifted so 
it's more convenient than some other chars, such as "@" or "&" -- 
they are shifted on UK layouts
# is called hash over here.

Kaj: "Surely in English people write #1, #2 and such?" Certiainly 
not. An English person would never write that. An American would.

Kaj: I share your security concerns about an appserver, but I don't 
think that other words datatypes can really be more secure. As long 
as you can force the LOADing of arbitrary input strings (without 
even evaluating the code), you could use it to make the symbol table 
blow up the memory.

Peter, OK, but that's where issue! comes from

Doc, my point is that one would be more likely to screen for limited 
word use than limited issue! use

Would it be possible to have a recycle feature for the symbols registry?

Hardly, the symbol table purpose is to provide a mapping between 
an integer value (the symbol ID) and a string representation. If 
we could allow the removal of a symbol, we would need: 


1) to be sure that a symbol is not used anymore anywhere (would require 
an equivalent of a full GC collection pass) before removing it.


2) maintain a list of freed "slots" in the symbol table for re-use.


3) being able to trigger the symbols-GC at relevant points in time.


Even with that, it would still be hard to counter a LOAD-based attack 
on the symbol table.

screen for limited word use

 That would need to happen at the LOAD level...not very clean from 
 a design POV.

(but doable)

GC collection pass
 => GC mark pass

Actually the best defense against such attacks is to never use LOAD 
on untrusted sources.

In the case where potentially harmful input needs to be LOADed, the 
input string needs to be validated before LOADing it with some good 
heuristics. I don't see any other way.

Kaj: you should also note that refinements already exhibit exactly 
the same behavior as issue-as-word! You can use digits only in refinements.

As a basic screen, you can check the length of what you're loading. 
It can't blow out your memory much beyond twice the length of the 
source (once to read it, once for the results).

I use issues for IDs, phone numbers, pseudo-GUIDs, and serial numbers. 
I use INCLUDE as well, and the other PREBOL bits that use them as 
keywords.


Could I use a string for those things? Sure. But I like having a 
datatype with more meaning.

Handy when parsing as well.

Issue! datatype added: https://github.com/dockimbel/Red/commit/177b65e67dfc23b1fe7475686a65af49fee7e939

I think issue-as-string could still be useful, so I was wondering 
if supporting both would be a good idea. I could be achieved by adding 
a keyword! datatype, we could then have two syntaxes:

    #<keyword>			;-- for issue-as-word (keyword! datatype!)
    ##<issue>			;-- for issue-as-string (issue! datatype!)

What do you think?

makes sense to me.

I would prefer it to be the other way around

The main use for keywords is preprocessing directives. We are used 
to #include, #if, #either, ... rather than ##include, ##if, ##either, 
... which look quite bad. I prefer to reserve the lighter syntax 
for the most frequent use-cases, which are keywords.

I haven't found any good prefix to replace # for issue-as-string!, 
so ## is the only option I see so far.

I'd prefer the other way around too. It would make it easier to port 
existing REBOL systems that make extensive use of issue! to Red.

REBOL systems that make extensive use of issue! 
 What systems do you have in mind?

The ones that I work one with Gregg.

Do you have to process lots of literal issue! values?

Yes. The data is stored in REBOL blocks. The "key" for each block 
is an issue value typically of the form #999999999 (though the length 
may vary).

Gregg knows the details much better than I.

It's interesting that we have all the symbols in unicode but still 
are lack of symbols because of we use only ASCII characters.

:-)

Jerry: keyboards are only able to handle a tiny subset of Unicode.

The limitation comes from the input devices.

Peter: you might want to optimize such structure to use integers 
instead of very costly issues-as-strings.

##1 looks at least as bad as #if especially because #1 is (American) 
English, while #if is just one of the many ad hoc inventions in C

How about @ for a keyword prefix? It has some precedent in TeX and 
such, I think

I knew that, Doc.

##1 looks at least as bad as ##if

@ will clash with email! syntax.

Agreed, but we use much more often #if than ##1.

I don't think so. mail! always needs to have a name before the @

I wouldn't program a system where users would have to enter ##1 for 
a bug number or such

nr<space>@red-lang.org
 would then be loaded silently without any error reported.

We can still use #1 as we always do. My proposition was just trying 
to cover some rare cases where we want to process issues as strings. 
But I see it brings a lot of confusion, so I will probably leave 
it as-is for now.

I think the split is fundamentally over that I don't see REBOL as 
just a language for pogrammers, but as an engine for user dialects

The system that I'm referring to has been collecting data for 10 
years or so. There are hundreds of REBOL scripts that would need 
to be changed.


More importantly , the users have got used to using the issue format 
when entering data.


It would be a massive emotional change and quite a large programming 
change to move from using issue-as-string.

I believe that Gregg has many other systems that depend on issue-as-string

I prefer # to be used for issue-as-string and and ## (or something 
else) for issue-as-word.

empty?: function [
	series			[string!]
	return:			[logic!]
][
	tail? series
]

-= Red Compiler =- 
Feature not yet implemented!