World: r4wp

I was convinced about that for Unicode, and it didn't work out well 
;-)

Ah, one thing to not, the type casting shortcuts like: as-integer, 
as-byte, etc.. won't work within #call because the Red/System preprocessor 
is invoked too late.

not => note

That sounds important to document.

I would probably prefer it being called #callback, or some ppl might 
relate it to REBOL's  CALL :-)

Actually, it is related a bit, because in both cases, you are making 
an "external" call.

#call is more generic; you're not necessarily calling back

That's why I've opted finally for just #call.

A Red/System logic! is stored as integer!, right, not byte!?

Integer! yes.

Just one question - I can see refeinements again mentioned. Is that 
technologically it is not easy achievable, or will we get refinement 
support for #call and routines later in the future?

Doc - strange thing on Trello - I I would not have my link in the 
cache, Search on Trello.com does not show any results for Red, or 
Red programming language ... strange ...

I I would = If I would ....

Refinements: these are a matter of cost vs added value. It costs 
significantly to add refinements support to routines and #call, and 
the added value is small. So, it is possible to add them, but it 
falls in the "nice to have" feature list, not "must to have", so 
they are very low priority.

Does Red attempt to answer Carl's old question of passing big options? 
Carl wrote a document on this once, but I can't find it.

Essentially it was the idea of doing something else, when a function 
grows to have too many refinements, as this is both not very user 
friendly and reduces performance.

APPLY is there for that (not yet implemented in Red though).

ok

There's also the special /options (IIRC) refinement in Topaz that 
allows use to pass a block with set-words/value for each arguments 
(including refinements). That should be also a solution to consider.

I've sometimes thought /WITH would be a good name for the arg block 
idea, though it would conflict with a few existing cases.

Agreed, I'm using that when marshalling Red to Red/System parameters

I have consolidated the current Red/System V2 wish list  on the Github 
wiki - https://github.com/dockimbel/Red/wiki/Red-System-v2-Wish-List

Thanks Peter. Could you please add a message like "Wish moved to 
v2 wish list on wiki" to each related tickets and close them?

Also, having details for #27 and #28 would helpful. As is, I don't 
understand them.

Also each wish has to be motivated by some need, else it will be 
likely rejected if the need is not obvious to me.

Quite extensive list. If there are no show-stoppers, I would proceed 
with Red first, e.g. getting us onto IOS, Android, bindings to native 
APIs, I/O, parse, etc. :-)

A lot of that needs to go through Red/System, so it's hard setting 
priorities

I've closed the issues and will write up #27 and #28 (as I understand 
them) and add to the needs as I understand them.

Nice list, Peter

Quite a few are youre Kaj :-)

Yes, but it's important to have them in a more structured form

Right, having a more formal specification like Python's PEP would 
be nice.

Pekr: it's for Red/System 2.0, so it's not a short-term task.

Also, probably half of them will be rejected, or superseded by other 
features.

No rejected items yet, looking good! Point 5 and 17 both have a wish 
for a BREAK.

What do we need GOTO for in Red? GOTO END-PROGRAM ;)

Array type +1

Arnold: I haven't processed the list yet.

Array type + 2, no matter if you processed it :-)

Having an array type is probably not as useful as you might think. 
The only real advantage I see is the ability to add optional bound-checking, 
which should protect from a whole class of errors.

Array syntax is a little more "average" programmer friendly than 
allocating memory and user pointers though :-)

But only just a little! :D


@Doc I guessed that! It looks other way for outsider(s) (undecided)

Peter, it is possible to add literal array notation support without 
adding an array type.

Also, even if you can statically allocate memory, you still need 
dynamic allocations too.

Peter, what kind of "array syntax" do you have in mind?

For other purposes arrays are not a replacement for pointers. But 
for the majority of small uses of arrays they take away the need 
for the administration overhead. It is handy and easy.

Is there a Red/System page that states its goals? e.g., Is Red/System 
meant to be bare bones, or do you see adding some higher level elements, 
like D. I ask because D has various array types, and didn't know 
if you planned to implment a few core elements at the lowest level, 
so they can be used in Red/System, and then just exposed to Red.

Goals are stated since the beginning here: http://static.red-lang.org/red-system-specs.html#section-1

Red/System is supposed to remain small in order to be usable as a 
Red dialect for low-level programming. I don't have any plans to 
add higher-level features, because they will overlap or collide with 
Red's own features.

So, it's fine to add Red/System features as long as it helps Red 
language construction or extends the low-level accessing abilitites.