World: r3wp

funcallA arglist next_token ----- CFG grammar cannot distinguish 
args from arglist from next_token.

you probably used hacks over CFG that make it non-CFG

arglist --- args separated by spaces

no. as i've said before, you simply cannot explicitly model e.g. 
funcalls

i.e. you won't get a "funcall" node in the AST

well. I'll go rest a bit today =)

Evgeniy: thanks for bringing up that issue in the BNF doc, we'll 
need to fix that description somehow.

Dockimbel: I think there may be more issues with the grammar. I think 
I'll continue tomorrow.

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

Henrik, networking is already available

Haha. The following is indistinguishable in space-ignoring versions 
of Coco/R, so spaces must be modeled via the grammar, too:

word1: word2

word1 :func2

the first line is assignment, the second line depends on the meaning 
of word1

though :func2 could be included into TOKENS section

<code-block> ::= [ {<statement> | <expression> | <comment>}+   ]
      A

btw are definitions allowed inside the code blocks?

Evgeniy, the : is part of the first token in the first case, and 
part of the second token in the second case, it isn't a separate 
token. The values a: and :a are related semantically, not syntactically.

The assignment is semantic, not syntactic. Other Red dialects may 
or may not associate a set-word with assignment.

Or you could think of it as a higher-level syntax, above the tokenization 
level.

You could try to make the Coco/R syntax specific to the Red/System 
dialect or you could make at least the tokenizer general for Red 
code and implement the Red/System dialect in the parse rules. The 
latter would be a more useful approach for REBOL-like languages :)

Well. I give up. I don't like languages with preprocessors since 
they are slower than languages with no preprocessor. So I send an 
original .ATG to Dockimbel, and stop my work. Looking at the RED 
spec made me sigh about the preprocessor.

And I am restarting my work on simple Oberon-like language.

I was just talking about the token portion of the Coco/R syntax rules, 
as opposed to the parse rule portion. But agreed, any Oberon-like 
language will have a simpler syntax than any REBOL-like language, 
and will have been designed with LL(1 or so) in mind.

paths seems to be tokens, too

Paths are made up of tokens, yes, just like the other block types 
except with more restrictions about what types of data may go in 
the paths. I don't (currently) know what subset of path syntax and 
semantics that Red/System supports though.

In some other REBOL-like languages there are some inherent conflicts 
between some path element types (notably dates) and the path separator 
/ itself, plus the final : on a set-path is considered part of the 
path instead of being a set-word element contained in the path, and 
the same for a leading : in a get-path not being part of a get-word 
first element (in R3). There's a fairly well-defined set of precedence 
rules, but for REBOL-like languages other than Red those rules are 
not very well documented, and they can therefore sometimes vary from 
language to language.

Evgeniy, function calls are not really part of the syntax in REBOL, 
or Topaz and i think even Red/System. So, yes, it is a CFG, it's 
just not like other languages (more like XML or JSON).

Doc - congrats on finishing floating support in Red/System. Now all 
to-do list items seems to be done right? So time to move on onto 
Red itself? :-)

Doc, According your slides, Red's boxed value composes of 4-byte 
head and 12-byte payload. Why so? I guess R3 is 2-byte head and 10-byte 
payload. Just curious. :-)

Pekr: thanks but only the float-partial branch is done (still some 
bugs to fix also).

Jerry: values needs space to store various flags, and type information. 
Also, payload access needs to be 32-bit aligned at least.

Why do you think that the R3 values header is 2 bytes long only?

2-byte head is just my guess. 10-byte payload is my guess too, based 
on the max limit of tuple!. With your explaination, now I know why 
4-12 is choosed. Thanks.

is it possible to get pointer value from variable declared as c-string?

R3 has 16 bytes cells, too

Oldes, wrap it in a struct. I call those references

If you mean a pointer to the string payload, that's what a c-string 
already is

I guess R3 is 2-byte head and 10-byte payload.
 - that is a wrong guess

Raspberrypi shipping any day now! http://www.raspberrypi.org/Lets 
see Red on it!

Oldes: A c-string is a byte-ptr!. It can be cast to an int-ptr! if 
needed.

Kaj: I cannot compile GTK+ examples anymore using the latest GTK+ 
binding version...Where can I find the missing GLib.reds file?

Here http://red.esperconsultancy.nl/Red-GLib/info/12c18cb30c?

Thanks Peter.

Kaj: I gave a new try on making the GTK+ binding work on Linux/ARM, 
I was able to track the crash up to the call to `gtk-append-container` 
from `gtk-window` function. The argument values passed are:

    window: 0006C000 value: 12

which results in a Runtime Error 1: access violation (segfault)

Kaj: my problem is, that I have a routine: MagickRelinquishMemory 
which should release memory from routines where some returns c-string, 
and some for example pointer to array values... So the best would 
be to accept pointer! with MagickRelinquishMemory, but still to be 
able return just c-string from some routines, if you understand me. 
I know there are workarounds, but it could be quite simple

What about implementing any-pointer! type?

Oldes: why can't use simply use type casting when required?

and is it possible to cast pointer from c-string?

Sure: 

    p: declare int-ptr!
    s: as c-string! p		;-- or use `as-c-string` defined