|
|
|
|
"Michael Schlenker" <schlenk@uni-oldenburg.de> wrote in message
news:2gftn1F2g20qU1@uni-berlin.de...
> mao wrote:
>
> Maybe this helps a bit:
> http://mini.net/tcl/1643
>
> Michael
Thanks!
But I've red all that :)
"BNF - Backus-Naur Form. A way of describing most modern computer languages
in terms of a tree of non-terminal and terminal tokens. Tcl is unusual in
that it is not defined this way..."
| |
|
|
|
|
| Kevin Kenny 2004-05-13, 9:36 am |
| "Michael Schlenker" <schlenk@uni-oldenburg.de> wrote in message
mao wrote:[color=darkred]
> Idiots from my college!
> It's not only hard, it's stupid...
Is the assignment to produce a parser for Tcl, or one for
"your favorite programming language?" If the latter, choose
a different language! Seriously, Tcl isn't the sort of
language that Yacc was designed to parse. Its syntax is
too simple - implying that a parser will give less
information about the script being parsed than one would
ordinarily expect.
--
73 de ke9tv/2, Kevin
| |
|
|
| Donal K. Fellows 2004-05-14, 7:31 am |
| Kevin Kenny wrote:
> Is the assignment to produce a parser for Tcl, or one for
> "your favorite programming language?" If the latter, choose
> a different language! Seriously, Tcl isn't the sort of
> language that Yacc was designed to parse. Its syntax is
> too simple - implying that a parser will give less
> information about the script being parsed than one would
> ordinarily expect.
To elaborate, yes you can do a yacc-style parser for Tcl, capturing the
information described on the Tcl(n) manual page. It's just that this is
not a level that people usually think about when describing programming
languages. The key to understanding Tcl is that it is virtually all
defined at a deeper level of abstraction (which I've seen many names
for, but I happen to think of as the "Turing" level.) All languages with
meaningful libraries actually operate there in practice (would you try
to understand Java without the java.lang package or the ability to
dynamically load classes?) but Tcl operates much more completely at that
level; the fact that things that are builtin keywords in other languages
are just normal commands in Tcl is a key part of Tcl's strength. IMHO it
is a reflection of the deep reality of computer programming that all is
mutable, and it also makes it easy to do really need tricks too. :^)
It's only a problem for the formal grammar people.
Donal.
| |
|
|
"Kevin Kenny" <kennykb@acm.org> wrote in message
news:40A371D6.9000308@acm.org...
> "Michael Schlenker" <schlenk@uni-oldenburg.de> wrote in message
>
> mao wrote:
>
> Is the assignment to produce a parser for Tcl, or one for
> "your favorite programming language?" If the latter, choose
> a different language! Seriously, Tcl isn't the sort of
> language that Yacc was designed to parse. Its syntax is
> too simple - implying that a parser will give less
> information about the script being parsed than one would
> ordinarily expect.
>
> --
> 73 de ke9tv/2, Kevin
It has to be Tcl and they want it to work like it does for
"normal" languages.I don't think it's possible since
you don't know the results of substitutions when parsing. For example:
f {string}{return $string ;}
set a 7 ; is equal to :
[f "set"] a 7;
but this should be a syntax error :
[f "something"] a 7;
How am I supposed to know what f returns??
The man pages only describe rooles for substitutions, grouping and
separating arguments and statements,
but I need rooles for every single command.
| |
| Darren New 2004-05-14, 3:32 pm |
| mao wrote:
> How am I supposed to know what f returns??
And you forgot
proc try {one two} [read $x]
try 3 4
| |
| Don Porter 2004-05-14, 4:32 pm |
| mao wrote:
> set a 7 ; is equal to :
> [f "set"] a 7;
> but this should be a syntax error :
> [f "something"] a 7;
No, both of those commands are in valid Tcl syntax.
The second one will raise a runtime error, but no parser can tell you
that.
--
| Don Porter Mathematical and Computational Sciences Division |
| donald.porter@nist.gov Information Technology Laboratory |
| http://math.nist.gov/~DPorter/ NIST |
|_______________________________________
_______________________________|
| |
| Robert Seeger 2004-05-21, 9:32 am |
| The second one "may" raise a runtime error, not will. Just for clarity's
sake, f could be defined as:
proc f {args} {
return set
}
Just a random minor correction :)
Rob Seeger
Don Porter wrote:
> mao wrote:
>
>
>
> No, both of those commands are in valid Tcl syntax.
>
> The second one will raise a runtime error, but no parser can tell you
> that.
>
|
|
|
|