digitalmars.D - D grammar

Ivan Senji (450/450) Aug 21 2004 Well this is as far as i can get it at this moment (no more time availab...

kinghajj (4/27) Aug 21 2004 OK, I've looked at enough at the posts on the "D Grammar", so, I have on...

Ivan Senji (7/16) Aug 21 2004 Grammar,

kinghajj (3/20) Aug 21 2004 OK, then how do you "generate" that? Is there some program that looks at...

Stephan Wienczny (4/10) Aug 21 2004 You write it yourself. Then you use a tool like antlr (antlr.org) to

teqDruid (4/15) Aug 21 2004 What tool will interpret the syntax posted? antlr won't take it (at lea...

Ivan Senji (9/24) Aug 21 2004 Only my tool (probbably) the way that it is written, but i don't see a

Johannes (2/4) Sep 11 2007 Could this be some wierd thing with Windows XP not using the same path s...

Johannes (1/1) Sep 11 2007 Sorry, Web-News bugged me into posting in the wrong group.

Ivan Senji (12/35) Aug 22 2004 I forgot to mention that if you remove "type" from basic_type grammar

Ilya Minkov (9/18) Aug 23 2004 I wonder what exactly causes the abiguity. What rules exactly conflict?

Andy Friesen (4/17) Aug 23 2004 I hit an issue like this just yesterday.

Stephan Wienczny (3/26) Aug 23 2004 Isn't that decided during semantic analysis?
Russ Lewis (8/27) Aug 23 2004 You can't do a YACC C grammar without a lot of hacking. The example

Walter (6/14) Aug 28 2004 No.

Walter (4/6) Aug 28 2004 That's resolved with the rule "if it parses as a declaration, it is a

Ivan Senji (4/11) Aug 29 2004 I figured that out from parse.c but how do you
Roberto Mariottini (8/15) Aug 30 2004 Walter, what about supporting an optional ':' to use in declarations, li...

Andy Friesen (10/34) Aug 30 2004 This is really easy to resolve with ANTLR:
Derek Parnell (11/35) Aug 30 2004 I imagine that the current recommended style is ...

Id (6/7) Aug 30 2004 For D 2.0, (unless total backwards compatibility source code is needed.....

Ilya Minkov (4/6) Aug 30 2004 =B0 is not ASCII.

Regan Heath (13/46) Aug 30 2004 Actually the style guide says to "avoid pointless type aliases" and list...

Ivan Senji (10/60) Aug 31 2004 wrote:

Stephan Wienczny (5/16) Aug 31 2004 I would suggest to use "var" as this is one letter less ;-P

Id (4/20) Aug 31 2004 Or, in all case, as the � character which I suggested for pointers is no...

Sean Kelly (5/15) Aug 31 2004 Why not:

Ivan Senji (8/24) Aug 31 2004 can

J C Calvarese (10/41) Aug 31 2004 Would you like this better?

Derek Parnell (25/63) Aug 31 2004 I was thinking that, '*' used as a pointer type is 'attached' or associa...
Id (18/24) Aug 31 2004 Painful? That's becuase you haven't seen this yet! ;) :
Roberto Mariottini (14/20) Aug 31 2004 I like better my proposal:

Regan Heath (16/40) Aug 31 2004

Ivan Senji (32/50) Aug 23 2004 Andy Friesens example desribes the problem corectly:

Andy Friesen (8/40) Aug 24 2004 I'll admit, though, that I haven't tested it as much as I ought to, and

Ivan Senji (9/49) Aug 24 2004 ugly bit)

antiAlias (5/22) Aug 24 2004 FWIW, I think what you're doing is highly commendable! Nice work, dude. ...

Ivan Senji (10/35) Aug 24 2004 slow

Ilya Minkov (22/46) Aug 27 2004 Everything that can be taken for a declaration is.

Ivan Senji (16/62) Aug 29 2004 Then i wouln't try :)

"Ivan Senji" <ivan.senji public.srce.hr> writes:

Well this is as far as i can get it at this moment (no more time available
to
spen on this)

The only things (as far as i can tell) that make it not a real D grammar
is
<STATEMENT> -> synchronized <STATEMENT>
<STATEMENT> -> synchronized ( <EXPRESSION> ) <STATEMENT>

I can't think of a way to write this in an unambigous way now.
And i didn't solve the problem of type<->expression
so it accepts a language in wich you have to write type infront of type
name.

like:
int something;   =>  type int something;

int func(char[] bla){}  =>  type int func(type char[] bla){}

Charlie? Sammy? Wanna try fixing this thing with types?
I think it could be done at a cost of a much uglier grammar.

Not saying that it isn't ugly now. Sorry for all those upercase names
(those are the ones that i wrote or inspired by Java lalr(1) grammar),
the ones in mixeded case are borowed form Walter's spec.

As it is this gramamr is lr(1) and it's parser is a little over 5000 states.
It would probbably even be lalr(1) but with much less states.

Attached is the grammar file (in my stupid format),
and the file i was able to parse (no lexer i have so it looks strange :)




begin 666 passed_test.TXT


M(#L-"FEM<&]R="!I9&X +"!I9&X +"!I9&X +"!I9&X .PT*:6UP;W)T(&ED
M;B N(&ED;B L(&ED;B N(&ED;B N(&ED;B L(&ED;B N(&ED;B N(&ED;B N

M:6X :61N("$ *"!T>7!E(&ED;B!;(%T +"!T>7!E(&)I=" I(#L-"FUI>&EN

M;B N(&ED;B A("  ='EP92!C:&%R("D :61N(#L-"GT-"G9E<G-I;VX *"!I


M9&X +"!I9&X +"!]( T*"79E<G-I;VX *"!I9&X *0T*"7L-" D)='EP92!I

M('1Y<&4 8FET(%T :61N(#L-
M;B!;(&ED;B K(&ED;B N+B!I9&X ?'P :61N(%T +2T .PT*( EI9&X 6R!I

M=')U92 I( T*"0EF;W)E86-H("  :6YO=70 ='EP92!I9&X :61N(#L :61N
M("X :61N("D-" D)>PT*"0D)>PT*"0D)"6EF("  :61N("D-" D)"0D):61N
M("LK(#L-
M*"!I9&X *0T*"0D)"0EI9B H(&ED;B \(&ED;B I(&ED;B K/2!I9&X .PT*
M"0D)"0EE;'-E(&ED;B O/2!I9&X .PT*"0D)"65L<V4 :61N("4](&ED;B [

M" D)"6ED;B M/2!I9&X +B!I9&X (2 H('1Y<&4 =F]I9" I(#L-" EI9B H
M('1R=64 *0T*"0E[('T-" EE;'-E(&EF("  9F%L<V4 *0T*"0E[('T-" EE




M72!;('1Y<&4 :61N("X :61N(%T 6R!T>7!E("X :61N(%T :61N("P :61N
M(#L-



M:6%S('1Y<&4 8VAA<B!;(%T 6R!=(&1E;&5G871E("  ='EP92!C:&%R("H 

M8VQA<W, :61N(#H ='EP92 N(&ED;B A("  ='EP92!I9&X (2 H("D +B!I



M("$ *"!T>7!E(&1C:&%R(%L 72 I(%L 72!I9&X +"!I9&X .PT*"0D)='EP
M92 N(&ED;B A("  ='EP92!D8VAA<B!;(%T *2 N(&ED;B!I9&X +"!I9&X 

M:61N("$ *" I(&ED;B H("XN+B I('L ?0T*"71Y<&4 :6YT."!;('1Y<&4 


M" T*8VQA<W, :61N("  86QI87, :61N(#T ='EP92!I;G0X("D .B!P=6)L




M("D-" E["0T*"7T-"GT-" T*=6YI='1E<W0-"GL-" EA<W-E<G0 *"!N97< 
M='EP92!I9&X *" I("H ;F5W("  :61N("D ='EP92!I9&X *"!I9&X +"!I
M9&X *2  *2 [( T*"6%S<V5R=" H("  :6YT-C1V("L :6YT-C1V('X <W1R
M:6YG("D )2!T:&ES("X :61N("X :61N(#T
M<W-E<G0 *"!T<G5E("$](&9A;'-E("$]('1R=64 (3T 9F%L<V4 /3T 9F%L

M("  ='EP92!T>7!E;V8 *"!I;G0S,G8 *2 I(#L-" ET>7!E:60 *"!T>7!E

M("  :61N(#P
M(#L-
M(#T


`
end

begin 666 Dgram.txt
M/$U/1%5,13X +3X ;6]D=6QE(#Q)1$Y?3$E35#X

M3$E35#X
M4SX-"CQ$14-,7T1%1E,^("T^("0-" T*/$1%0TQ?1$5&/B M/B \14Y533X-
M"CQ$14-,7T1%1CX +3X /$%'1U)%1T%413X-"CQ$14-,7T1%1CX +3X /$E-
M4$]25#X-"CQ$14-,7T1%1CX +3X /$U)6$E./ T*/$1%0TQ?1$5&/B M/B \


M1%1/4CX-"CQ$14-,7T1%1CX +3X :6YV87)I86YT(#Q35

M("T^(&YE=R \4$%204U%5$524SX /$-/3E1204-44SX-"CQ$14-,7T1%1CX 
M+3X 9&5L971E(#Q005)!345415)3/B \0T].5%)!0U13/ T*/$1%0TQ?1$5&
M/B M/B!S=&%T:6, =&AI<R H("D /$-/3E1204-44SX-"CQ$14-,7T1%1CX 
M+3X <W1A=&EC('X =&AI<R H("D /$-/3E1204-44SX-"CQ$14-,7T1%1CX 
M+3X <W1A=&EC(&%S<V5R=" H(#Q%6%!215-324]./B I(#L-"CQ$14-,7T1%
M1CX +3X /$1%0TQ?1$5&4U]!5%))0CX /$),3T-+/ T*/$1%0TQ?1$5&/B M


M051224(^(#Q
M1E-?051224(^(#Q



M3%]$14937T%44DE"/B M/B!A8G-T<F%C= T*"3Q$14-,7T1%1E-?051224(^
M("T^('-Y;F-H<F]N:7IE9 T*"3Q$14-,7T1%1E-?051224(^("T^(&1E<')E

M1$5&4U]!5%))0CX +3X <&%C:V%G90T*"3Q$14-,7T1%1E-?051224(^("T^
M('!R;W1E8W1E9 T*"3Q$14-,7T1%1E-?051224(^("T^('!U8FQI8PT*"3Q$

M:6=N("  :6YT,S)V("D /$),3T-+/ T*/$1%0TQ?1$5&/B M/B!A;&EG;B \

M4E\[/ T*/$1%0TQ?1$5&/B M/B!P<F%G;6$ *"!I9&X +" \05)'54U%3E13

M.SX +3X /$),3T-+/ T*/$1%0TQ?1$5&/B M/B!E>'1E<FX *"!I9&X *2 \

M3%]$148^("T^(&1E8G5G(#T :61N(#L
M(#T :6YT,S)V(#L-"CQ$14-,7T1%1CX +3X 9&5B=6< *" \1$5"54=?0T].
M1$E424]./B I(#Q
M54=?0T].1$E424]./B I(#Q
M148^("T^('9E<G-I;VX /2!I9&X .PT*/$1%0TQ?1$5&/B M/B!V97)S:6]N
M(#T :6YT,S)V(#L-"CQ$14-,7T1%1CX +3X =F5R<VEO;B H(#Q615)324].



M4$]25%].04U%4SX +3X /$E$3E],25-4/B -"CQ)35!/4E1?3D%-15,^("T^
M(#Q)1$Y?3$E35#X
M4U1!5$5-14Y44SX +3X /%-4051%345.5#X
M5$5-14Y44SX +3X ) T*/%-4051%345.5%]/4E].3U0^("T^(#Q35$%414U%

M("T^(#Q/4$5.7U-4051%345.5#X-"CQ35$%414U%3E0^("T^(#Q

M24]./ T*/$-,3U-%1%]35$%414U%3E0^("T^('L /%-4051%345.5%,^('T-

M3E]35$%414U%3E0^("T^('-W:71C:" H(#Q%6%!215-324]./B I(#Q/4$5.
M7U-4051%345.5#X

M5$%414U%3E0^("T^(&-A<V4 /$%34TE'3E]%6%!3/B Z(#Q/4$5.7U-4051%
M345.5#X
M4%,^(#H
M("T^(&1E9F%U;'0 .B \3U!%3E]35$%414U%3E0^( T*/$-,3U-%1%]35$%4
M14U%3E0^("T^(&1E9F%U;'0 .B \0TQ/4T5$7U-4051%345.5#X
M4$5.7U-4051%345.5#X +3X =F]L871I;&4 /$]014Y?4U1!5$5-14Y4/B -

M345.5#X
M/B!W:&EL92 H(#Q%6%!215-324]./B I( T*/$-,3U-%1%]35$%414U%3E0^


M4T5$7U-4051%345.5#X +3X 8V]N=&EN=64 .PT*/$-,3U-%1%]35$%414U%
M3E0^("T^(')E='5R;B \15A04D534TE/3E]/4E].3U0^(#L-" T*/"U35$%4
M14U%3E0^("T^('-Y;F-H<F]N:7IE9" \4U1!5$5-14Y4/ T*/"U35$%414U%
M3E0^("T^('-Y;F-H<F]N:7IE9" H(#Q%6%!215-324]./B I(#Q35$%414U%

M3CX .PT*/$-,3U-%1%]35$%414U%3E0^("T^(#Q4
M/%1R>5-T871E;65N=#X +3X =')Y('L /%-4051%345.5%,^('T /$-A=&-H

M/$-A=&-H97,^(&9I;F%L;'D >R \4U1!5$5-14Y44SX ?0T*"3Q4<GE3=&%T
M96UE;G0^("T^('1R>2![(#Q35$%414U%3E13/B!](&9I;F%L;'D >R \4U1!







M5#X +3X :68 *" \15A04D534TE/3CX *2 \4U1!5$5-14Y4/ T*/$]014Y?
M4U1!5$5-14Y4/B M/B!I9B H(#Q%6%!215-324]./B I(#Q
M5$5-14Y4/B!E;'-E(#Q/4$5.7U-4051%345.5#X-
M14Y4/B M/B!I9B H(#Q%6%!215-324]./B I(#Q
M/B!E;'-E(#Q
M/B M/B!D96)U9R \1$5"54=?0T].1$E424]./B \4U1!5$5-14Y4/ T*/$]0
M14Y?4U1!5$5-14Y4/B M/B!D96)U9R \1$5"54=?0T].1$E424]./B \0TQ/
M4T5$7U-4051%345.5#X (&5L<V4 /$]014Y?4U1!5$5-14Y4/ T*/$-,3U-%
M1%]35$%414U%3E0^("T^(&1E8G5G(#Q
M141?4U1!5$5-14Y4/B!E;'-E(#Q
M14Y?4U1!5$5-14Y4/B M/B!D96)U9R H(#Q
M/%-4051%345.5#X-"CQ/4$5.7U-4051%345.5#X +3X 9&5B=6< *" \1$5"
M54=?0T].1$E424]./B I(#Q

M1$5"54=?0T].1$E424]./B I(#Q
M3$]3141?4U1!5$5-14Y4/B -" T*/$]014Y?4U1!5$5-14Y4/B M/B!V97)S
M:6]N("  /%9%4E-)3TY?0T].1$E424]./B I(#Q35

M("D /$-,3U-%1%]35$%414U%3E0^("!E;'-E(#Q/4$5.7U-4051%345.5#X-

M1$E424]./B I(#Q
M5$5-14Y4/B -" T*/$]014Y?4U1!5$5-14Y4/B M/B!W:71H("  /$584%)%

M/B M/B!W:71H("  /$584%)%4U-)3TX^("D /$-,3U-%1%]35$%414U%3E0^


M:&EL92 H(#Q%6%!215-324]./B I(#Q
M/$]014Y?4U1!5$5-14Y4/B M/B!F;W( *" \4U1!5$5-14Y47T]27TY/5#X 
M.R \15A04D534TE/3E]/4E].3U0^(#L /$584%)%4U-)3TY?3U)?3D]4/B I
M(#Q/4$5.7U-4051%345.5#X
M("  /%-4051%345.5%]/4E].3U0^(#L /$584%)%4U-)3TY?3U)?3D]4/B [
M(#Q%6%!215-324].7T]27TY/5#X *2 \0TQ/4T5$7U-4051%345.5#X
M"CQ/4$5.7U-4051%345.5#X +3X 9F]R96%C:" H(#Q)3D]55%]/4E].3U0^
M(#Q

M3E0^( T*/$-,3U-%1%]35$%414U%3E0^("T^(&9O<F5A8V  *" \24Y/551?
M3U)?3D]4/B \0D%324-?5%E013X /$1%0TQ!4D%43U(^(#Q-3U)%7TE.3U54


M3U(^("T^("P /$E.3U547T]27TY/5#X
M5$]2/B \34]215])3D]55%]"05-)0U]465]$14-,05)!5$]2/ T*"3Q-3U)%



M345.5%,^("T^("D-" T*"3Q!4D=5345.5%-?3U)?3D]4/B M/B H(#Q!4D=5

M6%!3/B M/B \05-324=.7T584#X-"CQ!4U-)1TY?15A04SX +3X /$%34TE'

M4TE'3E]%6%!3/ T*/$584%)%4U-)3TY?3U)?3D]4/B M/B \15A04D534TE/
M3CX-"CQ%6%!215-324].7T]27TY/5#X
M+3X /$-/3D1?15A0/ T*/$%34TE'3E]%6% ^("T^(#Q
M4TE'3E]/4#X
M24=.7T]0/B M/B K/0T*/$%34TE'3E]/4#X +3X +3T-"CQ!4U-)1TY?3U ^


M3E]/4#X
M+3X /#P

M(#H
M4D]27T584#X
M7T584#X ('Q\(" \04Y$04Y$7T584#X-" T*/$%.1$%.1%]%6% ^("T^(#Q/



M"CQ83U)?15A0/B M/B \6$]27T584#X 7B \04Y$7T584#X-" T*/$%.1%]%
M6% ^("T^(#Q
M(#Q
M54%,7T584#X +3X /$5154%,7T584#X /$5154%,7T]0/B \4D5,7T584#X-
M"CQ%455!3%]/4#X +3X /3T-"CQ%455!3%]/4#X +3X (3T-"CQ%455!3%]/
M4#X
M/%-(24947T584#X-"CQ214Q?15A0/B M/B \4D5,7T584#X /%)%3%]/4#X 
M/%-(24947T584#X-"CQ214Q?3U ^("T^(#P-"CQ214Q?3U ^("T^(#P

M/0T*/%)%3%]/4#X
M+3X /#X
M7T]0/B M/B A/ T*/%)%3%]/4#X

M2$E&5%]%6% ^(#Q32$E&5%]/4#X
M(#P
M041$7T584#X
M(#Q!1$1?3U ^(#Q-54Q?15A0/ T*/$%$1%]/4#X +3X *PT*/$%$1%]/4#X 
M+3X +0T*/$%$1%]/4#X
M7T584#X-"CQ-54Q?15A0/B M/B \54Y!4EE?15A0/B \355,7T]0/B \355,
M7T584#X-"CQ-54Q?3U ^("T^("H-"CQ-54Q?3U ^("T^("\-"CQ-54Q?3U ^



M65]/4#X +3X ? T*/%5.05)97T]0/B M/B!D96QE=&4-"CQ53D%265]/4#X 
M+3X 8V%S=" H(#Q4>7!E/B I( T*/%5.05)97T584#X +3X /%5.05)97T]0
M/B \54Y!4EE?15A0/ T*/%5.05)97T584#X +3X /$Y%5U]%6%!215-324].
M/ T*/$Y%5U]%6%!215-324]./B M/B!N97< /$%21U5-14Y44U]/4E].3U0^
M(#Q"05-)0U]465!%/B \4U1!4E,^(%L /$%34TE'3E]%6% ^(%T /$1%0TQ!
M4D%43U(^( T*/$Y%5U]%6%!215-324]./B M/B!N97< /$%21U5-14Y44U]/
M4E].3U0^(#Q"05-)0U]465!%/B \4U1!4E,^("  /$%21U5-14Y44SX-"CQ5
M3D%265]%6% ^("T^("  /$584%)%4U-)3TX^("D /%!/4U1?15A0/ T*/%5.
M05)97T584#X

M/%!/4U1?15A07U-4549&/B M/B N(&ED;B -" D\4$]35%]%6%!?4U151D8^

M15A07U-4549&/B M/B K*R -" D\4$]35%]%6%!?4U151D8^("T^("TM( T*
M"3Q03U-47T584%]35%5&1CX +3X *" \05)'54U%3E13/B -" D\4$]35%]%
M6%!?4U151D8^("T^(%L 72 -" D\4$]35%]%6%!?4U151D8^("T^(%L /$%3
M4TE'3E]%6% ^("XN(#Q!4U-)1TY?15A0/B!=( T*"3Q03U-47T584%]35%5&



M;B -"CQ04DE-05)97T584%]35%5&1CX +3X :61N("$ /%1%35!,051%7T%2




M4U151D8^("T^('5N<S8T= T*/%!224U!4EE?15A07U-4549&/B M/B!F;&]A


M/B M/B!I;6%G:6YA<GDS,G8-"CQ04DE-05)97T584%]35%5&1CX +3X :6UA


M4U151D8^("T^('1R=64-"CQ04DE-05)97T584%]35%5&1CX +3X 9F%L<V4-
M"CQ04DE-05)97T584%]35%5&1CX +3X 8VAA<G8-"CQ04DE-05)97T584%]3

M= T*/%!224U!4EE?15A07U-4549&/B M/B!S=')I;F<-"CQ04DE-05)97T58

M4$537U ^("T^('9O:60-" D\0D%324-?5%E015-?6#X +3X :6YT. T*"3Q"
M05-)0U]465!%4U]8/B M/B!I;G0Q- T*"3Q"05-)0U]465!%4U]8/B M/B!U
M;G,Q- T*"3Q"05-)0U]465!%4U]8/B M/B!I;G0S, T*"3Q"05-)0U]465!%
M4U]8/B M/B!U;G,S, T*"3Q"05-)0U]465!%4U]8/B M/B!I;G0V- T*"3Q"
M05-)0U]465!%4U]8/B M/B!U;G,V- T*"3Q"05-)0U]465!%4U]8/B M/B!F

M5%E015-?6#X +3X 9FQO870X, T*"3Q"05-)0U]465!%4U]8/B M/B!I;6%G
M:6YA<GDS, T*"3Q"05-)0U]465!%4U]8/B M/B!I;6%G:6YA<GDV- T*"3Q"
M05-)0U]465!%4U]8/B M/B!I;6%G:6YA<GDX, T*"3Q"05-)0U]465!%4U]8
M/B M/B!C;VUP;&5X,S(-" D\0D%324-?5%E015-?6#X

M4U]8/B M/B!B:70-" D\0D%324-?5%E015-?6#X +3X 8VAA< T*"3Q"05-)
M0U]465!%4U]8/B M/B!W8VAA< T*"3Q"05-)0U]465!%4U]8/B M/B!D8VAA
M< T*/%!224U!4EE?15A07U-4549&/B M/B!T>7!E;V8 *" \15A04D534TE/
M3CX *0T*/%!224U!4EE?15A07U-4549&/B M/B!T>7!E:60 *" \5'EP93X 
M*0T*/%!224U!4EE?15A07U-4549&/B M/B!A<W-E<G0 *" \05-324=.7T58
M4#X

M65!%/B M/B!T>7!E(#Q)1$Y?3$E35#X (2 \5$5-4$Q!5$5?05)'54U%3E1?
M3$E35#X /$1/5%]!3D1?34]215]414U03$%415]!4D=5345.5%],25-4/ T*

M4D=5345.5%],25-4/B -" D\1$]47T%.1%]-3U)%7U1%35!,051%7T%21U5-
M14Y47TQ)4U0^("T^("X :61N(#Q$3U1?04Y$7TU/4D5?5$5-4$Q!5$5?05)'
M54U%3E1?3$E35#X-" D\1$]47T%.1%]-3U)%7U1%35!,051%7T%21U5-14Y4

M345.5%],25-4/B M/B N(&ED;B A(#Q414U03$%415]!4D=5345.5%],25-4

M5%]!3D1?34]215]414U03$%415]!4D=5345.5%],25-4/B M/B N(&ED;B A
M(#Q414U03
M<&4 /$1/5%]!3D1?34]215]414U03$%415]!4D=5345.5%],25-4/ T*/$)!


M54U%3E13/B  *0T*/%1%35!,051%7T%21U5-14Y47TQ)4U0^("T^("  *0T*
M/%1%35!,051%7T%21U5-14Y4/B M/B \5'EP93X-"CQ414U03$%415]!4D=5
M345.5#X
M/B \5$5-4$Q!5$5?05)'54U%3E0^( T*/%1%35!,051%7T%21U5-14Y44SX 
M+3X /%1%35!,051%7T%21U5-14Y4/B L(#Q414U03$%415]!4D=5345.5%,^

M5$]2/ T*/$1%0TQ!4D%43U(^("T^(&ED; T*/$1%0TQ!4D%43U(^("T^("  
M/$1%0TQ!4D%43U(^("D-"CQ$14-,05)!5$]2/B M/B!I9&X /$1E8VQA<F%T
M;W)3=69F:7AE<SX-"CQ$14-,05)!5$]2/B M/B H(#Q$14-,05)!5$]2/B I
M(#Q
M/ D\1&5C;&%R871O<E-U9F9I>#X-"CQ$96-L87)A=&]R4W5F9FEX97,^("T^
M"3Q$96-L87)A=&]R4W5F9FEX/B \1&5C;&%R871O<E-U9F9I>&5S/ T*/$1E
M8VQA<F%T;W)3=69F:7 ^("T^(%L 70T*/$1E8VQA<F%T;W)3=69F:7 ^("T^
M(%L /$584%)%4U-)3TX^(%T-"CQ$96-L87)A=&]R4W5F9FEX/B M/B!;(#Q4


M;&%R871O<C(^("T^(#Q"05-)0U]465!%,CX /$1E8VQA<F%T;W(R/ T*/$1E
M8VQA<F%T;W(R/B M/B H(#Q$96-L87)A=&]R,CX *0T*/$1E8VQA<F%T;W(R
M/B M/B H(#Q$96-L87)A=&]R,CX *2 \1&5C;&%R871O<E-U9F9I>&5S/ T*


M3$%2051)3TX^("T^(#Q


M3E]!5%))0CX +3X <W1A=&EC( T*"3Q$14-,05)!5$E/3E]!5%))0CX +3X 





M3E1204-44SX-"CQ$14-,05)!5$]24SX +3X /$1E8VQA<F%T;W));FET:6%L
M:7IE<CX-"CQ$14-,05)!5$]24SX +3X /$1E8VQA<F%T;W));FET:6%L:7IE
M<CX +" \1&5C;&%R871O<DED96YT:69I97),:7-T/ T*/$1E8VQA<F%T;W))


M8VQA<F%T;W))9&5N=&EF:65R3&ES=#X +3X /$1E8VQA<F%T;W))9&5N=&EF
M:65R/ T*/$1E8VQA<F%T;W))9&5N=&EF:65R3&ES=#X +3X /$1E8VQA<F%T
M;W))9&5N=&EF:65R/B L(#Q
M1&5C;&%R871O<DED96YT:69I97(^("T^(&ED; T*/$1E8VQA<F%T;W))9&5N




M04-44SX +3X .PT*/$-/3E1204-44SX +3X :6X >R \4U1!5$5-14Y44SX 



M24-?5%E013(^("T^(%L /$584%)%4U-)3TX^(%T-"CQ"05-)0U]465!%,CX 




M("D-" D\4$%204U3/B M/B N+BX *0T*"0D\24Y?3U547TE.3U547T504SX 
M+3X :6X-" D)/$E.7T]55%])3D]55%]%4%,^("T^(&]U= T*"0D\24Y?3U54
M7TE.3U547T504SX +3X :6YO=70-" D)/$E.7T]55%])3D]55%]%4%,^("T^

M4$4^(#Q$14-,05)!5$]2/B ](#Q!4U-)1TY?15A0/B \4$%204U37T5.1#X-

M(#Q$14-,05)!5$]2/B \4$%204U37T5.1#X-" D\4$%204U3/B M/B \24Y?
M3U547TE.3U547T504SX /%1Y<&4^(#Q005)!35-?14Y$/ T*"3Q005)!35-?

M14Y533X +3X 96YU;2!I9&X /$5N=6U";V1Y/ T*/$5.54T^("T^(&5N=6T 
M/$5N=6U";V1Y/ T*/$5.54T^("T^(&5N=6T :61N(#H /%1Y<&4^(#Q%;G5M
M0F]D>3X-"CQ%3E5-/B M/B!E;G5M(#H /%1Y<&4^(#Q

M<SX ?0T*"0D\16YU;4UE;6)E<G,^("T^(#Q%;G5M365M8F5R/ T*"0D\16YU
M;4UE;6)E<G,^("T^(#Q
M+3X /$5N=6U-96UB97(^("P /$5N=6U-96UB97)S/ T*"0D\16YU;4UE;6)E

M4#X
M;B \5$5-4$Q!5$5?4$%204U%5$527TQ)4U1?3U)?3D]4/B \24Y(15))5#X 

M<W,-" D\0TQ!4U-?3U)?24Y415)&04-%/B M/B!I;G1E<F9A8V4-" D\24Y(
M15))5#X
M/$E.2$52251?3D585#X +3X /%1Y<&4^(#Q)3DA%4DE47TY%6%1?14Y$/ T*
M"3Q)3DA%4DE47TY%6%0^("T^('!R:79A=&4 /$E.2$52251?3D585#X-" D\
M24Y(15))5%].15A4/B M/B!P86-K86=E(#Q
M2$52251?3D585#X +3X <')O=&5C=&5D(#Q
M2$52251?3D585#X +3X <'5B;&EC(#Q
M4DE47TY%6%1?14Y$/B M/B L(#Q



M("T^(#Q35%)50U1?3U)?54Y)3TX^(#Q)1$Y?3U)?3D]4/B \5$5-4$Q!5$5?
M4$%204U%5$527TQ)4U1?3U)?3D]4/B \4U1254-47T]27U5.24].7T5.1#X-
M" D\4U1254-47T]27U5.24]./B M/B!S=')U8W0-" D\4U1254-47T]27U5.



M5$5?4$%204U%5$527TQ)4U0^('L /$1%0TQ?1$5&4SX ?0T*"0T*/%1%35!,
M051%7U!!4D%-151%4E],25-4/B M/B H(#Q414U03$%415]005)?3$E35%]3
M5%5&1CX-"CQ414U03$%415]005)!345415)?3$E35#X
M4$Q!5$5?4$%27TQ)4U1?4U151D8^("T^(&%L:6%S(&ED;B \5$5-4$Q!5$5?
M4$%27TQ)4U1?4U151D9?14Y$/ T*/%1%35!,051%7U!!4E],25-47U-4549&
M/B M/B!A;&EA<R!I9&X /2 \5'EP93X /%1%35!,051%7U!!4E],25-47U-4
M549&7T5.1#X-"CQ414U03$%415]005)?3$E35%]35%5&1CX +3X :61N(#H 
M/%1Y<&4^(#Q414U03
M5$5?4$%27TQ)4U1?4U151D8^("T^(&ED;B ](#Q4>7!E/B \5$5-4$Q!5$5?
M4$%27TQ)4U1?4U151D9?14Y$/ T*/%1%35!,051%7U!!4E],25-47U-4549&
M/B M/B!I9&X /%1%35!,051%7U!!4E],25-47U-4549&7T5.1#X-"CQ414U0
M3$%415]005)?3$E35%]35%5&1CX +3X /%1Y<&4^(#H /$-/3D1%6% ^(#Q4

M4U1?4U151D8^("T^(#Q4>7!E/B ](#Q
M7TQ)4U1?4U151D9?14Y$/ T*/%1%35!,051%7U!!4E],25-47U-4549&/B M
M/B \5'EP93X /%1%35!,051%7U!!4E],25-47U-4549&7T5.1#X-"CQ414U0
M3$%415]005)?3$E35%]35%5&1E]%3D0^("T^("P /%1%35!,051%7U!!4E],
M25-47U-4549&/ T*/%1%35!,051%7U!!4E],25-47U-4549&7T5.1#X +3X 

M34E824X^("T^(&UI>&EN('1Y<&5O9B H(#Q%6%!215-324]./B I("X :61N
M(#Q-25A)3E]005)4,CX-"CQ-25A)3CX +3X ;6EX:6X :61N(#Q-25A)3E]0
M05)4,CX-"CQ-25A)3E]005)4,CX +3X (2 \5$5-4$Q!5$5?05)'54U%3E1?
M3$E35#X +B!I9&X /$U)6$E.7U!!4E0R/ T*/$U)6$E.7U!!4E0R/B M/B A
M(#Q414U03$%415]!4D=5345.5%],25-4/B \34E824Y?14Y$/ T*/$U)6$E.

M("T^(#Q-25A
M7T5.1#X
M4E].3U0^("T^("0-" T*/$143U(^("T^('X =&AI<R H("D /$-/3E1204-4



<1$5"54=?0T].1$E424]./B M/B!I;G0S,G8-" ``
`
end

Aug 21 2004

kinghajj <kinghajj_member pathlink.com> writes:

In article <cg7j4b$20cb$1 digitaldaemon.com>, Ivan Senji says...
Well this is as far as i can get it at this moment (no more time available
to
spen on this)

The only things (as far as i can tell) that make it not a real D grammar
is
<STATEMENT> -> synchronized <STATEMENT>
<STATEMENT> -> synchronized ( <EXPRESSION> ) <STATEMENT>

I can't think of a way to write this in an unambigous way now.
And i didn't solve the problem of type<->expression
so it accepts a language in wich you have to write type infront of type
name.

like:
int something;   =>  type int something;

int func(char[] bla){}  =>  type int func(type char[] bla){}

Charlie? Sammy? Wanna try fixing this thing with types?
I think it could be done at a cost of a much uglier grammar.

Not saying that it isn't ugly now. Sorry for all those upercase names
(those are the ones that i wrote or inspired by Java lalr(1) grammar),
the ones in mixeded case are borowed form Walter's spec.

As it is this gramamr is lr(1) and it's parser is a little over 5000 states.
It would probbably even be lalr(1) but with much less states.

Attached is the grammar file (in my stupid format),
and the file i was able to parse (no lexer i have so it looks strange :)

OK, I've looked at enough at the posts on the "D Grammar", so, I have one
question: WHAT THE HELL ARE YOU TALKING ABOUT? What do you mean by D Grammar,
and what's a grammar file???

Aug 21 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"kinghajj" <kinghajj_member pathlink.com> wrote in message
news:cg7r2u$2420$1 digitaldaemon.com...
 In article <cg7j4b$20cb$1 digitaldaemon.com>, Ivan Senji says...
Attached is the grammar file (in my stupid format),
and the file i was able to parse (no lexer i have so it looks strange :)

 OK, I've looked at enough at the posts on the "D Grammar", so, I have one
 question: WHAT THE HELL ARE YOU TALKING ABOUT? What do you mean by D

Grammar,
 and what's a grammar file???

A gramamr is a formal description of a syntax of a language.
D Grammar is a grammar that describes syntax of D language.
A grammar file is a file containing grammar rules

:)

Aug 21 2004

kinghajj <kinghajj_member pathlink.com> writes:

In article <cg8b6o$2cm7$1 digitaldaemon.com>, Ivan Senji says...
"kinghajj" <kinghajj_member pathlink.com> wrote in message
news:cg7r2u$2420$1 digitaldaemon.com...
 In article <cg7j4b$20cb$1 digitaldaemon.com>, Ivan Senji says...
Attached is the grammar file (in my stupid format),
and the file i was able to parse (no lexer i have so it looks strange :)

 OK, I've looked at enough at the posts on the "D Grammar", so, I have one
 question: WHAT THE HELL ARE YOU TALKING ABOUT? What do you mean by D

Grammar,
 and what's a grammar file???

A gramamr is a formal description of a syntax of a language.
D Grammar is a grammar that describes syntax of D language.
A grammar file is a file containing grammar rules

:)

OK, then how do you "generate" that? Is there some program that looks at sample
D code and somehow comes up with a grammar, or do you *write* it yourself?

Aug 21 2004

Stephan Wienczny <Stephan Wienczny.de> writes:

kinghajj wrote:
 
 
 OK, then how do you "generate" that? Is there some program that looks at sample
 D code and somehow comes up with a grammar, or do you *write* it yourself?
 
 

You write it yourself. Then you use a tool like antlr (antlr.org) to 
generate something useful.

Wienczny

Aug 21 2004

teqDruid <me teqdruid.com> writes:

What tool will interpret the syntax posted?  antlr won't take it (at least
not without some options I'm unaware of)

John

On Sun, 22 Aug 2004 01:55:54 +0200, Stephan Wienczny wrote:

 kinghajj wrote:
 
 
 OK, then how do you "generate" that? Is there some program that looks at sample
 D code and somehow comes up with a grammar, or do you *write* it yourself?
 
 

 You write it yourself. Then you use a tool like antlr (antlr.org) to 
 generate something useful.
 
 Wienczny

Aug 21 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"teqDruid" <me teqdruid.com> wrote in message
news:pan.2004.08.22.00.43.31.983992 teqdruid.com...
 What tool will interpret the syntax posted?  antlr won't take it (at least
 not without some options I'm unaware of)

Only my tool (probbably) the way that it is written, but i don't see a
problem
in rewriting it to antlr's or any other style. I can't do it because i  have
never
used antlr but it shouldn't be to difficult.

 John

 On Sun, 22 Aug 2004 01:55:54 +0200, Stephan Wienczny wrote:

 kinghajj wrote:
 OK, then how do you "generate" that? Is there some program that looks



at sample
 D code and somehow comes up with a grammar, or do you *write* it



yourself?

 You write it yourself. Then you use a tool like antlr (antlr.org) to
 generate something useful.

 Wienczny

Aug 21 2004

Johannes <getridofcrap.johannes.oberg gmail.com> writes:

 Where did the c:\d\ directory come from?

From one of the wiki4d "Evaulation Guide". I tried just making \DMD and \DM
first, and setting the path in different ways.

 Add dm\bin and dmd\bin to the path, and you're done.

Could this be some wierd thing with Windows XP not using the same path system
as real DOS?

Sep 11 2007

Johannes <getridofcrap.johannes.oberg gmail.com> writes:

Sorry, Web-News bugged me into posting in the wrong group.

Sep 11 2007

"Ivan Senji" <ivan.senji public.srce.hr> writes:

I forgot to mention that if you remove "type" from basic_type grammar
rule you get an ambigous LR(1) grammar but it is still possible to
parse that language with a parser i used to call nondeterministic LR(1)
before i found out it is actually Generalized LR or GLR.

The only sad thing is that this parser takes much more time
to parse because there are more parsers working in parallel.
My test file with an unamibouous grammar parses in 30ms
while this one with the GLR parser takes 2s, although it would
probably be possible to optimize both GLR parser and grammar.


"Ivan Senji" <ivan.senji public.srce.hr> wrote in message
news:cg7j4b$20cb$1 digitaldaemon.com...
 Well this is as far as i can get it at this moment (no more time available
 to
 spen on this)

 The only things (as far as i can tell) that make it not a real D grammar
 is
 <STATEMENT> -> synchronized <STATEMENT>
 <STATEMENT> -> synchronized ( <EXPRESSION> ) <STATEMENT>

 I can't think of a way to write this in an unambigous way now.
 And i didn't solve the problem of type<->expression
 so it accepts a language in wich you have to write type infront of type
 name.

 like:
 int something;   =>  type int something;

 int func(char[] bla){}  =>  type int func(type char[] bla){}

 Charlie? Sammy? Wanna try fixing this thing with types?
 I think it could be done at a cost of a much uglier grammar.

 Not saying that it isn't ugly now. Sorry for all those upercase names
 (those are the ones that i wrote or inspired by Java lalr(1) grammar),
 the ones in mixeded case are borowed form Walter's spec.

 As it is this gramamr is lr(1) and it's parser is a little over 5000

states.
 It would probbably even be lalr(1) but with much less states.

 Attached is the grammar file (in my stupid format),
 and the file i was able to parse (no lexer i have so it looks strange :)

Aug 22 2004

Ilya Minkov <minkov cs.tum.edu> writes:

Ivan Senji schrieb:

 I forgot to mention that if you remove "type" from basic_type grammar
 rule you get an ambigous LR(1) grammar but it is still possible to
 parse that language with a parser i used to call nondeterministic LR(1)
 before i found out it is actually Generalized LR or GLR.

I wonder what exactly causes the abiguity. What rules exactly conflict? 
Cannot the decision be shifted out?

And finally, C also has to deal with it someway. Did you base your D 
grammar on an existing YACC C grammar?

 The only sad thing is that this parser takes much more time
 to parse because there are more parsers working in parallel.
 My test file with an unamibouous grammar parses in 30ms
 while this one with the GLR parser takes 2s, although it would
 probably be possible to optimize both GLR parser and grammar.

Why don't you drop the table-based parsing altogether? It's always slow 
in practice anyway! Even the GCC crew seasoned at table-based pasing 
thinks so. Even, it is "considered harmful for reengineering purposes".

-eye

Aug 23 2004

Andy Friesen <andy ikagames.com> writes:

Ilya Minkov wrote:
 Ivan Senji schrieb:
 
 I forgot to mention that if you remove "type" from basic_type grammar
 rule you get an ambigous LR(1) grammar but it is still possible to
 parse that language with a parser i used to call nondeterministic LR(1)
 before i found out it is actually Generalized LR or GLR.

 
 
 I wonder what exactly causes the abiguity. What rules exactly conflict? 
 Cannot the decision be shifted out?
 
 And finally, C also has to deal with it someway. Did you base your D 
 grammar on an existing YACC C grammar?

I hit an issue like this just yesterday.

     a * b; // is it a local variable or a multiplication?

  -- andy

Aug 23 2004

Stephan Wienczny <Stephan Wienczny.de> writes:

Andy Friesen wrote:
 Ilya Minkov wrote:
 
 Ivan Senji schrieb:

 I forgot to mention that if you remove "type" from basic_type grammar
 rule you get an ambigous LR(1) grammar but it is still possible to
 parse that language with a parser i used to call nondeterministic LR(1)
 before i found out it is actually Generalized LR or GLR.



 I wonder what exactly causes the abiguity. What rules exactly 
 conflict? Cannot the decision be shifted out?

 And finally, C also has to deal with it someway. Did you base your D 
 grammar on an existing YACC C grammar?

 
 
 I hit an issue like this just yesterday.
 
     a * b; // is it a local variable or a multiplication?
 
  -- andy

Isn't that decided during semantic analysis?

Stephan

Aug 23 2004

Russ Lewis <spamhole-2001-07-16 deming-os.org> writes:

Andy Friesen wrote:
 Ilya Minkov wrote:
 
 Ivan Senji schrieb:

 I forgot to mention that if you remove "type" from basic_type grammar
 rule you get an ambigous LR(1) grammar but it is still possible to
 parse that language with a parser i used to call nondeterministic LR(1)
 before i found out it is actually Generalized LR or GLR.



 I wonder what exactly causes the abiguity. What rules exactly 
 conflict? Cannot the decision be shifted out?

 And finally, C also has to deal with it someway. Did you base your D 
 grammar on an existing YACC C grammar?


You can't do a YACC C grammar without a lot of hacking.  The example 
below is just one reason why.

 I hit an issue like this just yesterday.
 
     a * b; // is it a local variable or a multiplication?

In D, the rule is (or at least, used to be) that if it looks like either 
a no-op expression or a type, then it must be a type.  In the example 
above, it must be a type.

WALTER: Has this changed since you implemented opMul()?  What if opMul() 
has side effects?

Aug 23 2004

"Walter" <newshound digitalmars.com> writes:

"Russ Lewis" <spamhole-2001-07-16 deming-os.org> wrote in message
news:cgdrmm$176$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

     a * b; // is it a local variable or a multiplication?

 In D, the rule is (or at least, used to be) that if it looks like either
 a no-op expression or a type, then it must be a type.  In the example
 above, it must be a type.

 WALTER: Has this changed since you implemented opMul()?

No.

 What if opMul() has side effects?

Writing it as:
    (a * b);
will cause it to be parsed as a multiply.

Aug 28 2004

"Walter" <newshound digitalmars.com> writes:

"Andy Friesen" <andy ikagames.com> wrote in message
news:cgdqeq$ig$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

      a * b; // is it a local variable or a multiplication?

That's resolved with the rule "if it parses as a declaration, it is a
declaration."

Aug 28 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Walter" <newshound digitalmars.com> wrote in message
news:cgqo26$3m5$1 digitaldaemon.com...
 "Andy Friesen" <andy ikagames.com> wrote in message
 news:cgdqeq$ig$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

      a * b; // is it a local variable or a multiplication?

 That's resolved with the rule "if it parses as a declaration, it is a
 declaration."

I figured that out from parse.c but how do you
write a grammar rule for that rule ;)

Aug 29 2004

Roberto Mariottini <Roberto_member pathlink.com> writes:

In article <cgqo26$3m5$1 digitaldaemon.com>, Walter says...
"Andy Friesen" <andy ikagames.com> wrote in message
news:cgdqeq$ig$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

      a * b; // is it a local variable or a multiplication?

That's resolved with the rule "if it parses as a declaration, it is a
declaration."

Walter, what about supporting an optional ':' to use in declarations, like this:

a* : b; // b is of type a*

this can be useful also for type lists:

int*[] : a, b, c, d; // all of type int*[]

All this is for clarity only. I don't know if this can help to disambiguate or
will only cause trouble to the parser.

Ciao

Aug 30 2004

Andy Friesen <andy ikagames.com> writes:

Roberto Mariottini wrote:

 In article <cgqo26$3m5$1 digitaldaemon.com>, Walter says...
 
"Andy Friesen" <andy ikagames.com> wrote in message
news:cgdqeq$ig$1 digitaldaemon.com...

I hit an issue like this just yesterday.

     a * b; // is it a local variable or a multiplication?

That's resolved with the rule "if it parses as a declaration, it is a
declaration."

 
 
 Walter, what about supporting an optional ':' to use in declarations, like
this:
 
 a* : b; // b is of type a*
 
 this can be useful also for type lists:
 
 int*[] : a, b, c, d; // all of type int*[]
 
 All this is for clarity only. I don't know if this can help to disambiguate or
 will only cause trouble to the parser.

This is really easy to resolve with ANTLR:

     statement
             // if it could be a type, assume it is a type
         :   (type) => type Identifier
             // else maybe it's an expression
         |   expression
         |   ...
         ;

  -- andy

Aug 30 2004

Derek Parnell <derek psych.ward> writes:

On Mon, 30 Aug 2004 07:32:30 +0000 (UTC), Roberto Mariottini wrote:

 In article <cgqo26$3m5$1 digitaldaemon.com>, Walter says...
"Andy Friesen" <andy ikagames.com> wrote in message
news:cgdqeq$ig$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

      a * b; // is it a local variable or a multiplication?

That's resolved with the rule "if it parses as a declaration, it is a
declaration."

 
 Walter, what about supporting an optional ':' to use in declarations, like
this:
 
 a* : b; // b is of type a*
 
 this can be useful also for type lists:
 
 int*[] : a, b, c, d; // all of type int*[]
 
 All this is for clarity only. I don't know if this can help to disambiguate or
 will only cause trouble to the parser.
 
 Ciao

I imagine that the current recommended style is ...

 alias a* ap;
 ap b; // b is of type a* (aka ap)

 alias int*[] ipa;
 ipa a, b, c, d; // all of type int*[] (aka ipa)

Its a pity that '*' is used for two totally different syntax purposes.

-- 
Derek
Melbourne, Australia
30/Aug/04 5:52:34 PM

Aug 30 2004

Id <Id_member pathlink.com> writes:

In article <cgumig$28n8$1 digitaldaemon.com>, Derek Parnell says...

Its a pity that '*' is used for two totally different syntax purposes.

For D 2.0, (unless total backwards compatibility source code is needed...) in
order to avoid confusion between the multiplication operator and pointer, what
about if:

"*" continues being used for multiplications (eg: a*=b; //multiplies a*b)
"�" indicates a pointer (eg: long� foo; //pointer to a long)

Aug 30 2004

Ilya Minkov <minkov cs.tum.edu> writes:

Id schrieb:

 "*" continues being used for multiplications (eg: a*=3Db; //multiplies =

a*b)
 "=BA" indicates a pointer (eg: long=BA foo; //pointer to a long)

=B0 is not ASCII.

-eye

Aug 30 2004

Regan Heath <regan netwin.co.nz> writes:

On Mon, 30 Aug 2004 17:56:00 +1000, Derek Parnell <derek psych.ward> wrote:

 On Mon, 30 Aug 2004 07:32:30 +0000 (UTC), Roberto Mariottini wrote:

 In article <cgqo26$3m5$1 digitaldaemon.com>, Walter says...
 "Andy Friesen" <andy ikagames.com> wrote in message
 news:cgdqeq$ig$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

      a * b; // is it a local variable or a multiplication?

 That's resolved with the rule "if it parses as a declaration, it is a
 declaration."

 Walter, what about supporting an optional ':' to use in declarations, 
 like this:

 a* : b; // b is of type a*

 this can be useful also for type lists:

 int*[] : a, b, c, d; // all of type int*[]

 All this is for clarity only. I don't know if this can help to 
 disambiguate or
 will only cause trouble to the parser.

 Ciao

 I imagine that the current recommended style is ...

  alias a* ap;
  ap b; // b is of type a* (aka ap)

Actually the style guide says to "avoid pointless type aliases" and lists 
the following as pointless:

alias void VOID;
alias int INT;
alias int* pint;

the last is suspiciously like the example you give above.

  alias int*[] ipa;
  ipa a, b, c, d; // all of type int*[] (aka ipa)

 Its a pity that '*' is used for two totally different syntax purposes.

Yeah.. if only pointers and multiplication weren't so useful we could 
remove one of them. Luckily the need for pointers has lessened in D, as 
compared to C/C++.

Regan

-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Aug 30 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Regan Heath" <regan netwin.co.nz> wrote in message
news:opsdkgbpiy5a2sq9 digitalmars.com...
 On Mon, 30 Aug 2004 17:56:00 +1000, Derek Parnell <derek psych.ward>

wrote:
 On Mon, 30 Aug 2004 07:32:30 +0000 (UTC), Roberto Mariottini wrote:

 In article <cgqo26$3m5$1 digitaldaemon.com>, Walter says...
 "Andy Friesen" <andy ikagames.com> wrote in message
 news:cgdqeq$ig$1 digitaldaemon.com...
 I hit an issue like this just yesterday.

      a * b; // is it a local variable or a multiplication?

 That's resolved with the rule "if it parses as a declaration, it is a
 declaration."

 Walter, what about supporting an optional ':' to use in declarations,
 like this:

 a* : b; // b is of type a*

 this can be useful also for type lists:

 int*[] : a, b, c, d; // all of type int*[]

 All this is for clarity only. I don't know if this can help to
 disambiguate or
 will only cause trouble to the parser.

 Ciao

 I imagine that the current recommended style is ...

  alias a* ap;
  ap b; // b is of type a* (aka ap)

 Actually the style guide says to "avoid pointless type aliases" and lists
 the following as pointless:

 alias void VOID;
 alias int INT;
 alias int* pint;

 the last is suspiciously like the example you give above.

  alias int*[] ipa;
  ipa a, b, c, d; // all of type int*[] (aka ipa)

 Its a pity that '*' is used for two totally different syntax purposes.

 Yeah.. if only pointers and multiplication weren't so useful we could
 remove one of them. Luckily the need for pointers has lessened in D, as
 compared to C/C++.

But pointers are not a problem here, types are. Because in "a * b" a can
be both type and an object. A simple solution would be to mark types
some way, like:
type a* b; //declaration
a*b; //expression

But who would like to write "type" before every type in a Cstyle
language? :)

 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Aug 31 2004

Stephan Wienczny <Stephan Wienczny.de> writes:

Ivan Senji wrote:
 
 But pointers are not a problem here, types are. Because in "a * b" a can
 be both type and an object. A simple solution would be to mark types
 some way, like:
 type a* b; //declaration
 a*b; //expression
 
 But who would like to write "type" before every type in a Cstyle
 language? :)
 
 

I would suggest to use "var" as this is one letter less ;-P
For me it would not be that problem to use such a style. It could make 
reading sources easier.

Stephan

Aug 31 2004

Id <Id_member pathlink.com> writes:

In article <ch21n2$qdh$1 digitaldaemon.com>, Stephan Wienczny says...
Ivan Senji wrote:
 
 But pointers are not a problem here, types are. Because in "a * b" a can
 be both type and an object. A simple solution would be to mark types
 some way, like:
 type a* b; //declaration
 a*b; //expression
 
 But who would like to write "type" before every type in a Cstyle
 language? :)
 
 

I would suggest to use "var" as this is one letter less ;-P
For me it would not be that problem to use such a style. It could make 
reading sources easier.

Stephan

Or, in all case, as the � character which I suggested for pointers is not in the
7bit ASCII table (oops... ��'), what about using "   " for pointers? that is:

cent  foo; // foo is a overused name which manages to be a pointer to a cent ;P

Aug 31 2004

Sean Kelly <sean f4.ca> writes:

In article <ch21n2$qdh$1 digitaldaemon.com>, Stephan Wienczny says...
Ivan Senji wrote:
 
 But pointers are not a problem here, types are. Because in "a * b" a can
 be both type and an object. A simple solution would be to mark types
 some way, like:
 type a* b; //declaration
 a*b; //expression
 
 But who would like to write "type" before every type in a Cstyle
 language? :)


Why not:

a* b; // declaration
(a*b); // expression


Sean

Aug 31 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Sean Kelly" <sean f4.ca> wrote in message
news:ch2lcv$15l7$1 digitaldaemon.com...
 In article <ch21n2$qdh$1 digitaldaemon.com>, Stephan Wienczny says...
Ivan Senji wrote:
 But pointers are not a problem here, types are. Because in "a * b" a



can
 be both type and an object. A simple solution would be to mark types
 some way, like:
 type a* b; //declaration
 a*b; //expression

 But who would like to write "type" before every type in a Cstyle
 language? :)


 Why not:

 a* b; // declaration
 (a*b); // expression

It is the way it is now, but:
a/b;  //expression
a+b; //expression
a*b; //declaration

I don't like it.

 Sean

Aug 31 2004

J C Calvarese <jcc7 cox.net> writes:

Ivan Senji wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
 news:ch2lcv$15l7$1 digitaldaemon.com...
 
In article <ch21n2$qdh$1 digitaldaemon.com>, Stephan Wienczny says...

Ivan Senji wrote:

But pointers are not a problem here, types are. Because in "a * b" a



 
 can
 
be both type and an object. A simple solution would be to mark types
some way, like:
type a* b; //declaration
a*b; //expression

But who would like to write "type" before every type in a Cstyle
language? :)


Why not:

a* b; // declaration
(a*b); // expression

 
 
 It is the way it is now, but:
 a/b;  //expression
 a+b; //expression
 a*b; //declaration
 
 I don't like it.

Would you like this better?

cast(thisIsAnExpression) (a*b); //expression
type(thisIsADeclaration)  a*b;  //declaration

Perfectly clear.
Painful to type.
Hurts my eyes. Ow.

-- 
Justin (a/k/a jcc7)
http://jcc_7.tripod.com/d/

Aug 31 2004

Derek Parnell <derek psych.ward> writes:

On Tue, 31 Aug 2004 17:39:27 -0500, J C Calvarese wrote:

 Ivan Senji wrote:
 "Sean Kelly" <sean f4.ca> wrote in message
 news:ch2lcv$15l7$1 digitaldaemon.com...
 
In article <ch21n2$qdh$1 digitaldaemon.com>, Stephan Wienczny says...

Ivan Senji wrote:

But pointers are not a problem here, types are. Because in "a * b" a



 
 can
 
be both type and an object. A simple solution would be to mark types
some way, like:
type a* b; //declaration
a*b; //expression

But who would like to write "type" before every type in a Cstyle
language? :)


Why not:

a* b; // declaration
(a*b); // expression



I was thinking that, '*' used as a pointer type is 'attached' or associated
with the left hand expression, that is the 'a'. So to make that obvious one
could code ...

   (a*)b; // declaration. 

However that is interpreted as a depreciated cast!

 It is the way it is now, but:
 a/b;  //expression
 a+b; //expression
 a*b; //declaration
 
 I don't like it.


Hmmm... when put like that it does seem a tad inconsistent.

 Would you like this better?
 
 cast(thisIsAnExpression) (a*b); //expression
 type(thisIsADeclaration)  a*b;  //declaration
 
 Perfectly clear.
 Painful to type.
 Hurts my eyes. Ow.

So back on the 'cast' sort of syntax...

   type(a*)b; // declaration

as it reads "I am declaring a variable called 'b' of type a*"

This seems to work in the general case ...

declaration::"type" "(" type_expression ")" newident [, newident ]... ";"
newident:: identifier [ "=" initval ]
initval:: ( literal | classinit )
classinit:: "new"  classname  [ "(" parmlist ")" ]


type(int) d;
type(Foo) f;
type(Bar[]*) b;
type(XYZ*[]) x;


One would only need to use this 'type' syntax to remove ambiguity and still
have consistent expression syntax.

-- 
Derek
Melbourne, Australia
1/Sep/04 9:28:59 AM

Aug 31 2004

Id <Id_member pathlink.com> writes:

In article <ch2un1$1a8k$1 digitaldaemon.com>, J C Calvarese says...

Would you like this better?

cast(thisIsAnExpression) (a*b); //expression
type(thisIsADeclaration)  a*b;  //declaration

Perfectly clear.
Painful to type.
Hurts my eyes. Ow.

Painful? That's becuase you haven't seen this yet! ;) :

public static headache main()             // returns a headache, for sure :P
{
#define <'*',!pointer, 0>;           // code 0 assigned to pointer   
#define <'*',!mult_operand, 1>;      // code 1 assigned to mult_operand
foo*<0> a=0x0040_0000;               // a is a pointer to a foo
long n1=5, n2=7, n3=9, n4=-12;
n1*<1>=n2;                           // multiplies n1*n2
n3=n1*<2>n4;                         // error, code 2 for '*' not specified
return null;
}

Ok, after this joke... you could have heard what I proposed before (which seemed
to be ignored...) �_�' .
What about if the ' ' character was used for pointers? it's a simple,
straightforward way! :

a*b;     // expression - ol' school multiplication
foo  b;  // declaration - b is a pointer to a foo

Aug 31 2004

Roberto Mariottini <Roberto_member pathlink.com> writes:

In article <ch2un1$1a8k$1 digitaldaemon.com>, J C Calvarese says...

[...]
Would you like this better?

cast(thisIsAnExpression) (a*b); //expression
type(thisIsADeclaration)  a*b;  //declaration

Perfectly clear.
Painful to type.
Hurts my eyes. Ow.

I like better my proposal:

a * b; // expression
a* : b; // declaration

I know that typing a ':' for every declaration is not for lazy people, so I'd
let it optional, used to make things clearer, or only when an ambiguity is
found:

a b; // no ambiguity: declaration
a[] b; // ditto
a : b; // OK, ':' is redundant 
a* : b; // ambiguous, must use ':' to be a declaration

And so on.

Ciao

Aug 31 2004

Regan Heath <regan netwin.co.nz> writes:

On Tue, 31 Aug 2004 15:27:34 +0200, Ivan Senji <ivan.senji public.srce.hr> 
wrote:
 "Regan Heath" <regan netwin.co.nz> wrote in message
 news:opsdkgbpiy5a2sq9 digitalmars.com...
 On Mon, 30 Aug 2004 17:56:00 +1000, Derek Parnell <derek psych.ward>


<snip>

  alias int*[] ipa;
  ipa a, b, c, d; // all of type int*[] (aka ipa)

 Its a pity that '*' is used for two totally different syntax purposes.

 Yeah.. if only pointers and multiplication weren't so useful we could
 remove one of them. Luckily the need for pointers has lessened in D, as
 compared to C/C++.

 But pointers are not a problem here, types are.

Isn't a pointer a type?

 Because in "a * b" a can
 be both type and an object.

I realise that.

Question: If there was no such thing as a pointer, what does "a * b" mean?
Answer: multiplication

Question: If there was no such thing as multiplication, what does "a * b" 
mean?
Answer: a pointer to an 'a' called 'b'.

 A simple solution would be to mark types
 some way, like:
 type a* b; //declaration
 a*b; //expression

 But who would like to write "type" before every type in a Cstyle
 language? :)

Walter said "a * b" will be interpreted as a pointer, to cause it to be an 
expression you use braces eg. (a * b)

That seems to me to be an ok solution.

Regan

 Regan

 --
 Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/




-- 
Using M2, Opera's revolutionary e-mail client: http://www.opera.com/m2/

Aug 31 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:cgdp33$30rl$1 digitaldaemon.com...
 Ivan Senji schrieb:

 I forgot to mention that if you remove "type" from basic_type grammar
 rule you get an ambigous LR(1) grammar but it is still possible to
 parse that language with a parser i used to call nondeterministic LR(1)
 before i found out it is actually Generalized LR or GLR.

 I wonder what exactly causes the abiguity. What rules exactly conflict?
 Cannot the decision be shifted out?

Andy Friesens example desribes the problem corectly:
 a * b;
Is "a" a type and i'm declaring a pointer to that type,
or am i just mulitplying a and b?

DMD also has problems with this:
"proba2.d(13): a is used as a type"

The grammar rules could probbably be rewriten to combine these
two cases into one case, but i haven't yet found the courage (or time)
to try it.

 And finally, C also has to deal with it someway. Did you base your D
 grammar on an existing YACC C grammar?

Some parts are but i will have to look into it to see how it solves the
problems of this type, although i suspect it uses some aditional
disambiguating rules because it has:
ifStatement -> if ( expression ) statement else statement
ifStatement -> if ( expression ) statement

and this isn't reall lr(1).


 The only sad thing is that this parser takes much more time
 to parse because there are more parsers working in parallel.
 My test file with an unamibouous grammar parses in 30ms
 while this one with the GLR parser takes 2s, although it would
 probably be possible to optimize both GLR parser and grammar.

 Why don't you drop the table-based parsing altogether? It's always slow
 in practice anyway! Even the GCC crew seasoned at table-based pasing
 thinks so. Even, it is "considered harmful for reengineering purposes".

Well i wrote a program to generate that table and if i dropped it
it would mean that writing it was a waste of time :)
Maybe it is slow but there are advantages: i have to write the table
generator and simulator once and can use it with any grammar:
For example i have used it so far to parse C,D,Java, our simple-project
programming language at the university and a bunch of small grammars.

I use it as a toy and a tool to help me write a grammar for a hypothetical
programming language based on D. I make a syntax change and in a
couple of minutes i can test it: i have a syntax tree to see if the results
are good, and i have plans to create a recursive descent parser generator
that would traverse this tree, and  i know it will be slow but it is a lot
of fun!
:)

Can you please explain why it is: "considered harmful for reengineering
purposes". ?

 -eye

Aug 23 2004

Andy Friesen <andy ikagames.com> writes:

Ivan Senji wrote:
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:cgdp33$30rl$1 digitaldaemon.com...
 
Ivan Senji schrieb:


I forgot to mention that if you remove "type" from basic_type grammar
rule you get an ambigous LR(1) grammar but it is still possible to
parse that language with a parser i used to call nondeterministic LR(1)
before i found out it is actually Generalized LR or GLR.

I wonder what exactly causes the abiguity. What rules exactly conflict?
Cannot the decision be shifted out?

 
 
 Andy Friesens example desribes the problem corectly:
  a * b;
 Is "a" a type and i'm declaring a pointer to that type,
 or am i just mulitplying a and b?
 
 DMD also has problems with this:
 "proba2.d(13): a is used as a type"
 
 The grammar rules could probbably be rewriten to combine these
 two cases into one case, but i haven't yet found the courage (or time)
 to try it.

This is what I did:

 TypeOrExpression
     : Type IDENTIFIER // it's a local
     | Type IDENTIFIER '=' ConditionalExpression // initialized local
     | Type AssignOp ConditionalExpression // expression (this is the ugly bit)
     | AssignExpression // expression
     ;

I'll admit, though, that I haven't tested it as much as I ought to, and 
it certainly has its share of problems. (like allowing statements like 
"int = 8")

(I really should look into replacing it with an ANTLR grammar.  It 
behaves in a much more intuitive manner, I think)

  -- andy

Aug 24 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Andy Friesen" <andy ikagames.com> wrote in message
news:cgep6c$gaj$1 digitaldaemon.com...
 Ivan Senji wrote:
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 news:cgdp33$30rl$1 digitaldaemon.com...

Ivan Senji schrieb:


I forgot to mention that if you remove "type" from basic_type grammar
rule you get an ambigous LR(1) grammar but it is still possible to
parse that language with a parser i used to call nondeterministic LR(1)
before i found out it is actually Generalized LR or GLR.

I wonder what exactly causes the abiguity. What rules exactly conflict?
Cannot the decision be shifted out?


 Andy Friesens example desribes the problem corectly:
  a * b;
 Is "a" a type and i'm declaring a pointer to that type,
 or am i just mulitplying a and b?

 DMD also has problems with this:
 "proba2.d(13): a is used as a type"

 The grammar rules could probbably be rewriten to combine these
 two cases into one case, but i haven't yet found the courage (or time)
 to try it.

 This is what I did:

 TypeOrExpression
     : Type IDENTIFIER // it's a local
     | Type IDENTIFIER '=' ConditionalExpression // initialized local
     | Type AssignOp ConditionalExpression // expression (this is the


ugly bit)
     | AssignExpression // expression
     ;


Where does this go? ( :) )
i have this part causing problems:
<ClosedStatement> -> <Declaration>
<ClosedStatement> -> <Expression>  ;

Can i find your grammar somewhere, maybe combine them and
create a better one?

 I'll admit, though, that I haven't tested it as much as I ought to, and
 it certainly has its share of problems. (like allowing statements like
 "int = 8")

 (I really should look into replacing it with an ANTLR grammar.  It
 behaves in a much more intuitive manner, I think)

   -- andy

Aug 24 2004

"antiAlias" <fu bar.com> writes:

"Ivan Senji" <ivan.senji public.srce.hr> .
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 Why don't you drop the table-based parsing altogether? It's always slow
 in practice anyway! Even the GCC crew seasoned at table-based pasing
 thinks so. Even, it is "considered harmful for reengineering purposes".

 Well i wrote a program to generate that table and if i dropped it
 it would mean that writing it was a waste of time :)
 Maybe it is slow but there are advantages: i have to write the table
 generator and simulator once and can use it with any grammar:
 For example i have used it so far to parse C,D,Java, our simple-project
 programming language at the university and a bunch of small grammars.

 I use it as a toy and a tool to help me write a grammar for a hypothetical
 programming language based on D. I make a syntax change and in a
 couple of minutes i can test it: i have a syntax tree to see if the

results
 are good, and i have plans to create a recursive descent parser generator
 that would traverse this tree, and  i know it will be slow but it is a lot
 of fun!
 :)

FWIW, I think what you're doing is highly commendable! Nice work, dude. Wish
I could have hired someone like yourself last year for a somewhat related
project.

Aug 24 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"antiAlias" <fu bar.com> wrote in message
news:cgepb9$geg$1 digitaldaemon.com...
 "Ivan Senji" <ivan.senji public.srce.hr> .
 "Ilya Minkov" <minkov cs.tum.edu> wrote in message
 Why don't you drop the table-based parsing altogether? It's always



slow
 in practice anyway! Even the GCC crew seasoned at table-based pasing
 thinks so. Even, it is "considered harmful for reengineering



purposes".
 Well i wrote a program to generate that table and if i dropped it
 it would mean that writing it was a waste of time :)
 Maybe it is slow but there are advantages: i have to write the table
 generator and simulator once and can use it with any grammar:
 For example i have used it so far to parse C,D,Java, our simple-project
 programming language at the university and a bunch of small grammars.

 I use it as a toy and a tool to help me write a grammar for a


hypothetical
 programming language based on D. I make a syntax change and in a
 couple of minutes i can test it: i have a syntax tree to see if the

 results
 are good, and i have plans to create a recursive descent parser


generator
 that would traverse this tree, and  i know it will be slow but it is a


lot
 of fun!
 :)

 FWIW, I think what you're doing is highly commendable! Nice work, dude.

Not really, it is just a matter of implementing an algorithm not very
different
then any other algorithm. :)

 Wish
 I could have hired someone like yourself last year for a somewhat related
 project.

Aug 24 2004

Ilya Minkov <minkov cs.tum.edu> writes:

Ivan Senji schrieb:

 Andy Friesens example desribes the problem corectly:
  a * b;
 Is "a" a type and i'm declaring a pointer to that type,
 or am i just mulitplying a and b?

Everything that can be taken for a declaration is.

On the other hand, YACC would want that also to work like that in the
middle of the expression, right?

 DMD also has problems with this:
 "proba2.d(13): a is used as a type"

DMD lives from expectations. It knows not to expect a declaration within
the expression, but what you are trying to parse is a statement.

 The grammar rules could probbably be rewriten to combine these
 two cases into one case, but i haven't yet found the courage (or time)
 to try it.

I think *this* is the reason why it's "considered harmful". :)

 Well i wrote a program to generate that table and if i dropped it
 it would mean that writing it was a waste of time :)

If your target was to learn to write one, then why was it a waste of
time? :)

 Maybe it is slow but there are advantages: i have to write the table
 generator and simulator once and can use it with any grammar:
 For example i have used it so far to parse C,D,Java, our simple-project
 programming language at the university and a bunch of small grammars.

Simulator?

 I use it as a toy and a tool to help me write a grammar for a hypothetical
 programming language based on D. I make a syntax change and in a
 couple of minutes i can test it: i have a syntax tree to see if the results
 are good, and i have plans to create a recursive descent parser generator
 that would traverse this tree, and  i know it will be slow but it is a lot
 of fun!
 :)

Why should it be slow?

 Can you please explain why it is: "considered harmful for reengineering
 purposes". ?

There was an article i ran over once, i didn't really like its tone but
the points seem to be valid... I think it was on parsing COBOL, where
many sorts of syntax extensions appeared over years. And the
requierement for parsing was then, that syntax parts could be enabled
and disabled, which is possible with recursive descent parsers (though i
don't know whether any automatic generator has such an ability), but
problematic with table-based systems. Other problem was if the grammar
would need to be slightly extended, it might provoke a disproportinate
amount of editing to disambiguate it - apart from GLR of course, but
what would be the advantage compared to recursive?

-eye

Aug 27 2004

"Ivan Senji" <ivan.senji public.srce.hr> writes:

"Ilya Minkov" <minkov cs.tum.edu> wrote in message
news:cgo4fg$207v$2 digitaldaemon.com...
 Ivan Senji schrieb:

 Andy Friesens example desribes the problem corectly:
  a * b;
 Is "a" a type and i'm declaring a pointer to that type,
 or am i just mulitplying a and b?

 Everything that can be taken for a declaration is.

 On the other hand, YACC would want that also to work like that in the
 middle of the expression, right?

 DMD also has problems with this:
 "proba2.d(13): a is used as a type"

 DMD lives from expectations. It knows not to expect a declaration within
 the expression, but what you are trying to parse is a statement.

 The grammar rules could probbably be rewriten to combine these
 two cases into one case, but i haven't yet found the courage (or time)
 to try it.

 I think *this* is the reason why it's "considered harmful". :)

Then i wouln't try  :)

 Well i wrote a program to generate that table and if i dropped it
 it would mean that writing it was a waste of time :)

 If your target was to learn to write one, then why was it a waste of
 time? :)

You are absolutely right, nothing you learn to do is a waste of time.
(almost nothing)

 Maybe it is slow but there are advantages: i have to write the table
 generator and simulator once and can use it with any grammar:
 For example i have used it so far to parse C,D,Java, our simple-project
 programming language at the university and a bunch of small grammars.

 Simulator?

Ah! It is my English! When i said "simulator" it is actually a part of
program
that takes an input string and a table and as output it returns 0 or more
parse trees.

 I use it as a toy and a tool to help me write a grammar for a


hypothetical
 programming language based on D. I make a syntax change and in a
 couple of minutes i can test it: i have a syntax tree to see if the


results
 are good, and i have plans to create a recursive descent parser


generator
 that would traverse this tree, and  i know it will be slow but it is a


lot
 of fun!
 :)

 Why should it be slow?

Atlest slower than a normal recursive descent parser because this one
will first do the parsing part with a table.

 Can you please explain why it is: "considered harmful for reengineering
 purposes". ?

 There was an article i ran over once, i didn't really like its tone but
 the points seem to be valid... I think it was on parsing COBOL, where
 many sorts of syntax extensions appeared over years. And the
 requierement for parsing was then, that syntax parts could be enabled
 and disabled, which is possible with recursive descent parsers (though i
 don't know whether any automatic generator has such an ability), but
 problematic with table-based systems. Other problem was if the grammar
 would need to be slightly extended, it might provoke a disproportinate
 amount of editing to disambiguate it - apart from GLR of course, but
 what would be the advantage compared to recursive?

I see! Thanks

 -eye

Aug 29 2004

D Programming

C/C++ Programming

Other

digitalmars.D - D grammar