r3wp [groups: 83 posts: 189283]
  • Home
  • Script library
  • AltME Archive
  • Mailing list
  • Articles Index
  • Site search
 

World: r3wp

[Red] Red language group

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?