World: r3wp

Sorry, I meant "An error..."

A warning might be a better solution.

And would avoid to add them in the "keywords list".

should this:
	#enum test! [foo: 3]
	f: func[foo [c-string!]][print foo]
	f "bar"
throw a declaration error or print "bar"?

Declaration error.

Any idea what else should be tested? https://github.com/Oldes/Red/blob/float-partial/red-system/tests/source/compiler/enum-test.r

Looking at it...

Hmm, you should have separated the compilation tests from the language 
features tests...but no problem, Peter could split that later.

A test with enum vs define?

Oh I see there's already one for that.

Multiple enums using the same name {#enum test! [...] #enum test! 
[...]}?

Setting an enumerated symbol to a value that is not an integer?

BTW, there's a `print-wide` function defined at runtime for printing 
with a blank space between values. :-)

I think that it should be enough tests for a start.

done.. you can find complete diff for the pull request here: https://github.com/dockimbel/Red/pull/201/files

Code review of your pull request finished. Only minor things except 
maybe for the addition in `get-variable-spec` that might cause some 
issues.

Also, do not forget to `git rebase` your forked branch to get all 
the latest commits.

Why is not c-string! available in pointer-syntax rule?

Because, pointer [byte!] == c-string!

And because pointers on pointers are not allowed.

How to define in RedS struct like:

typedef struct Info
{
  InfoType
    type;
  struct Info
    *next;
} Info;

Struct aliases are there for that. See http://static.red-lang.org/red-system-specs.html#section-4.5.5

info!: alias struct! [
    type [...]
    next [info!]
]

Then you can just do for example:

s: declare info!
p: declare info!

s/next: p

yes... just tested... it works

I am currently entering a formal EBNF Coco/R .ATG grammar for Red/System 
as specified in the BNF doc at the site.

Coco/R is LL(1)/LL(k). This grammar would automagically yield a new 
lexer for Red/System.

The Coco/R is GPL. The compiler/lexer produced by Coco/R is of unspecified 
license.

Typed in. Several dozens of LL(1) warnings.

Good as long as there's no error. ;-)

Just remind me please .. when is work starting on RED itself?

Dockimbel - those warnings mean ambiguities

I currently try to resolve them

Is http://www.red-lang.org/p/roadmap.html
Bootstrap 4 referring to the RED language?

In the roadmap, Red refers to Red proper, Red/System to Red/System. 
Easy as pie :)

So yes, bootstrap steps 3, 4, 5 refer to implementing parts of Red 
proper.

Evgeniy: you can email the fixes to Rudolf directly or to me ([nr-:-red-lang-:-org]).

Graham: it should have started a month ago, but I've postponed it 
to add floating point support to Red/System. The work on Red should 
start in a week.

If the grammar is OK, there will be new interpreter for Red/System 
soon :)

Ok, thanks guys

Evgeniy: we'll see how far can go Coco/R. :-)

It would be nice for newbies in the about page to have a statement 
of what you will be able to do with RED when "complete"

eg. system utilities, web apps, cgi scripting, desktop apps ..etc

And if there's a plan for a GUI

I suppose there are some internal priorities for Red as well, such 
as when for example networking becomes relevant.

I would hope Red adopts one of the existing GUI solutions.

As opposed to writing a dialected GUI?

Newbies info: well, from all the presentations slides, you can see 
that Red is meant to be a "general purpose" programming language, 
so making any list of possible applications would be restrictive 
and probably also premature as Red is not yet implemented.


GUI is certainly a feature to have, but I wouldn't make it part of 
the "core" language, rather handle it as library. One remark about 
future Red GUI support, there will probably be several GUI frameworks 
available (we already have GTK+, I'll add a native one, and someone 
could contribute a View clone), I'll try to put a common VID-like 
dialect on top of them, so we can quickly switch from one to another 
with minimal changes needed.

That would be wonderful!

You can also add HTML5 to the list of future GUI frameworks. ;-)