World: r3wp
[Red] Red language group
older newer | first last |
Evgeniy Philippov 31-Jan-2012 [4647] | spaces are delimiters |
Andreas 31-Jan-2012 [4648] | how do you parse `foo bar 1 2`? |
Evgeniy Philippov 31-Jan-2012 [4649] | depends on the definitions of foo and other tokens. I.e. on context |
Andreas 31-Jan-2012 [4650x3] | exactly |
so if you want a context-free grammar which models nested calls, you'd need funcall delimitation | |
(which is what doc said) | |
Evgeniy Philippov 31-Jan-2012 [4653x3] | no. not delimiters are issue. |
end of list of arguments is uncertain | |
with CFG | |
Andreas 31-Jan-2012 [4656] | read again: i said "funcall delimitation" |
Evgeniy Philippov 31-Jan-2012 [4657x2] | this is ambiguous |
and nested calls are implementable without any delimitation | |
Andreas 31-Jan-2012 [4659x2] | on the other hand, i'm certain that you can model Red/System's syntactical structure with a context-free grammar. it's just that the CST/AST would look quite different from other languages (i.e. in that it does not explicitly model function call structures) |
(pretty much the same as for REBOL) | |
Evgeniy Philippov 31-Jan-2012 [4661x2] | you're wrong |
for example | |
Andreas 31-Jan-2012 [4663] | as i've done this several times before, i'm quite confident that i'm not wrong :) |
Evgeniy Philippov 31-Jan-2012 [4664x3] | 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 | |
Andreas 31-Jan-2012 [4667x2] | 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 | |
Evgeniy Philippov 31-Jan-2012 [4669] | well. I'll go rest a bit today =) |
Dockimbel 31-Jan-2012 [4670] | Evgeniy: thanks for bringing up that issue in the BNF doc, we'll need to fix that description somehow. |
Evgeniy Philippov 31-Jan-2012 [4671] | Dockimbel: I think there may be more issues with the grammar. I think I'll continue tomorrow. |
Kaj 31-Jan-2012 [4672x2] | I suppose there are some internal priorities for Red as well, such as when for example networking becomes relevant. |
Henrik, networking is already available | |
Evgeniy Philippov 1-Feb-2012 [4674x7] | 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? | |
BrianH 1-Feb-2012 [4681x4] | 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 :) | |
Evgeniy Philippov 1-Feb-2012 [4685x2] | 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. | |
BrianH 1-Feb-2012 [4687] | 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. |
Evgeniy Philippov 1-Feb-2012 [4688] | paths seems to be tokens, too |
BrianH 1-Feb-2012 [4689x2] | 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. | |
Gabriele 1-Feb-2012 [4691] | 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). |
Pekr 1-Feb-2012 [4692] | 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? :-) |
Jerry 1-Feb-2012 [4693] | 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. :-) |
Dockimbel 1-Feb-2012 [4694x3] | 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? | |
older newer | first last |