🚀 go-pugleaf

RetroBBS NetNews Server

Inspired by RockSolid Light RIP Retro Guy

Article View: comp.lang.functional
Article #596

concrete vs abstract syntax or syntax trees

#596
From: Dave MacQueen
Date: Tue, 29 Sep 1992 03:09
46 lines
2900 bytes
It is certainly nice to be able to manipulate programs in terms of a
straightfoward structural representation.  However, this doesn't mean
that one has to be content with a primitive concrete syntax such as
Lisp's.  It suffices to have a parser that translates one's concrete
syntax into a more convenient representation for manipulation by
programs.  For instance, the next release of SML of NJ will provide
a syntax tree datatype, currently called ast (but this name may change
before the release) which is fairly close to the concrete syntax.
Of course, parentheses have nothing to do with the representation of
of programs in terms of a syntactic datatype.  [Note also that Lisp
S-expressions are not equivalent to an abstract syntax representation
for Lisp -- most S-expressions do not correspond to well formed Lisp
programs or expressions.]

Anyone who prefers Lisp style concrete syntax is free to define such
a syntax for, say, Standard ML.  They could then write a parser that
would translate their syntax into a type like ast for processing by
the rest of the compiler.  The ast representation mentioned above is
"pre-elaboration", meaning static analysis and type checking take
place after the construction of the ast representation of a program.
This makes the parser's task fairly simple.

Actually, I would prefer to move further away from Lisp style syntax.
One of the unfortunate aspects of SML syntax is the overloading and
consequent over-use of parentheses.  Parentheses play three main
roles:

 (1) grouping (this is the most fundamental role)

 (2) bracketing tuples as in (1, true, "abc")

 (3) bracketing sequence expressions, as in (print "a"; print "b")

I would prefer to use different notations for (2) and (3).  Angle
brackets would be appropriate for (2), but are unfortunately not
available in ascii (maybe it's time to move on to the ISO Latin 8 bit
character set?).  For (3) the traditional Algol "begin ... end"
notation would probably be fine.

Dave MacQueen
macqueen@research.att.com
Room 2A-431, AT&T Bell Labs, 600 Mountain Ave, Murray Hill, NJ 07974
--
Dave MacQueen
macqueen@research.att.com
Room 2A-431, AT&T Bell Labs, 600 Mountain Ave, Murray Hill, NJ 07974
Technical Details
Message-ID: <DBM.92Sep28220940@ai.allegra.att.com>
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!uwm.edu!linac!att!att!dptg!ulysses!ulysses!dbm
References: <1992Sep26.212935.26809@eng.umd.edu> <1992Sep28.120225.9524@odin.diku.dk> <TMB.92Sep28144424@arolla.idiap.ch> <annius.717696151@freyr> <TMB.92Sep28223555@arolla.idiap.ch>

Show Full Headers
Complete Article Headers
Newsgroups: comp.lang.functional
Path: arc1-ca.pugleaf.net!sparky!uunet!wupost!uwm.edu!linac!att!att!dptg!ulysses!ulysses!dbm
From: dbm@allegra.att.com (Dave MacQueen)
Subject: concrete vs abstract syntax or syntax trees
Sender: netnews@ulysses.att.com (Steve Bellovin)
Message-ID: <DBM.92Sep28220940@ai.allegra.att.com>
In-Reply-To: tmb@arolla.idiap.ch's message of 29 Sep 92 02:35:55 GMT
Date: Tue, 29 Sep 1992 03:09:40 GMT
References: <1992Sep26.212935.26809@eng.umd.edu> <1992Sep28.120225.9524@odin.diku.dk>
 <TMB.92Sep28144424@arolla.idiap.ch> <annius.717696151@freyr>
 <TMB.92Sep28223555@arolla.idiap.ch>
Organization: AT&T Bell Laboratories
Lines: 46