Re: language design tradeoffs

alvin@eyepoint.com (Alvin Starr)
Tue, 22 Sep 1992 03:31:14 GMT

          From comp.compilers

Related articles
[24 earlier articles]
Re: language design tradeoffs eifrig@beanworld.cs.jhu.edu (1992-09-19)
Re: language design tradeoffs maxtal@extro.ucc.su.OZ.AU (1992-09-21)
Re: language design tradeoffs jch@rdg.dec.com (1992-09-21)
Re: language design tradeoffs nickh@CS.CMU.EDU (1992-09-21)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-21)
Re: language design tradeoffs raveling@Unify.com (1992-09-21)
Re: language design tradeoffs alvin@eyepoint.com (1992-09-22)
Re: language design tradeoffs kcoppes@aardvark.den.mmc.com (1992-09-22)
Re: language design tradeoffs dmason@plg.uwaterloo.ca (1992-09-22)
Re: language design tradeoffs tmb@arolla.idiap.ch (1992-09-23)
Re: language design tradeoffs jlg@cochiti.lanl.gov (1992-09-23)
Re: language design tradeoffs bromage@mullauna.cs.mu.OZ.AU (1992-09-24)
Re: language design tradeoffs alvin@eyepoint.com (1992-09-24)
[4 later articles]
| List of all articles for this month |

Newsgroups: comp.compilers,comp.human-factors
From: alvin@eyepoint.com (Alvin Starr)
Organization: eyepoint
Date: Tue, 22 Sep 1992 03:31:14 GMT
References: 92-09-048 92-09-095
Keywords: design



macrakis@osf.org (Stavros Macrakis) writes:
>>There are other possible conventions, as used in, e.g., Ada:


>>1) Use "end X" where X is the name of the opening delimiter, e.g. "end
>> loop;", "end record;" etc.


>>2) Use "end X" where X is the name of the named unit (e.g. function,
>> module, ...).


bromage@mullauna.cs.mu.OZ.AU (Andrew Bromage) writes:
>The problem here is that you end up with an amazingly verbose language
>like Pascal, which is a pain to type in.


Is a little verbosity a bad thing? I work with a language(Turing) that will
allow short forms so that
if a < b then
x := y
end if
    can become
[a<b:x:=y]
    the second is much harder to maintain when an 80,000 line program is
    completly written this way.


>My favourite solution comes from BASIC, where the statement terminator :
>is an _extension_ to the normal business of using EOL do terminate a
>statement. More modern versions of similar ideas can be found in languages
>like Turing.


Turing has no statment seperators/terminators.


>How do you allow the omission of the semicolon in languages like this at
>the end of a line? It's easy using a predictive parser because the end of
>the statement can be predicted. Does anyone have a "best way" of doing
>this with an LR parser?


There is no need for a language to require staement seperators or
terminators a little judicious design can get you around that problem.
Turing is an example of such a language.


Turing uses a PDA discription language called S/SL to help generate
various stages of compilation (scanning/syntax/semantic/code-generation).
S/SL claims to be equal in descriptive power to an LR(k) parser. At one
point in Turing's history a yacc grammer was generated to verify that the
language had no context sensitive features.
--
Alvin Starr || voice: (416)513-6717
Eyepoint Inc. || fax: (416)513-6718
alvin@eyepoint.com ||
--


Post a followup to this message

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