Article View: comp.lang.functional
Article #596concrete vs abstract syntax or syntax trees
From: Dave MacQueen
Date: Tue, 29 Sep 1992 03:09
Date: Tue, 29 Sep 1992 03:09
46 lines
2900 bytes
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!dbmReferences:
<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