Re: Parsing functions - do I need a keyword like 'def' to indicate a function?

Matt C. asked:
>I'm trying to create a simple scripting language using lex and yacc. I've
>noticed that the grammars for most scripting languages have some kind of
>keyword in front of function declarations.
...
>I was wondering why that is. I suspect the point is to avoid of ambiguity
>with other language constructs, but I'm not sure. If possible, I don't want
>to use a keyword.
...
>Does anyone have any suggestions as to whether or not I should have/need a
>keyword in front?


Two answers:


1) You don't *NEED* a keyword in front. It is perfectly possible to
      design an unambiguous grammar with no leading keyword to introduce
      declarations.


2) That being said. It is often easier/better to have an introductory
      keyword for declarations. The simple rule of thumb is that if
      every production begins with a unique token (keyword), the language
      is trivially LL(1). That has benefits beyond just the parsing
      phase. Not only are languages that follow that perscription easier
      to parse mechanically (i.e. by your computer running your parser),
      but also they are easier for humans to read. Everything is
      "trivially" clear and unambiguous.


That is not to say you can't make a clear and easy to understand (and
to parse) language without initial keywords (point 1). And, if you
find that the keywords are making your language "harder" rather than
"easier", drop them. However, remember that the most important
clients are probably the users who will modify scripts written by
someone else. If you can do something to make their life easier, that
is probably a benefit (point 2). This is defintely a case where you
need to make a judgement call.


Write scripts in your desired notation, especially taking short-cuts
if your notation allows them. Better yet, get your friends to write
some scripts for you. Compare the scripts to make sure that items
which are semantically different, don't look similar (especially not
subtly different). The worst propertly a language can have is a small
change in syntax equal a big change in semantics, epsecially if both
semantics are valid but different. You want most typos to be caught
early when they are cheap.


After you have done that exercise, imagine then extnesions to your
language that might come about. Make certain that you aren't boxing
yourself into a corner where you might want to add some feature, but
when you get to adding that feature, you are going to run into
notational problems because of the current notation you have chosen.
Hope this helps,
-Chris


*****************************************************************************
Chris Clark Internet : compres@world.std.com
Compiler Resources, Inc. Web Site : http://world.std.com/~compres
23 Bailey Rd voice : (508) 435-5016
Berlin, MA 01503 USA fax : (978) 838-0263 (24 hours)
------------------------------------------------------------------------------

Return to the comp.compilers page.
Search the comp.compilers archives again.