Newsgroups: comp.lang.dylan
Path: cantaloupe.srv.cs.cmu.edu!das-news2.harvard.edu!news2.near.net!news.mathworks.com!udel!gatech!howland.reston.ans.net!news.sprintlink.net!uunet!in1.uu.net!newsflash.concordia.ca!news.mcgill.ca!DMI.USherb.CA!clouso.crim.ca!IRO.UMontreal.CA!saguenay.iro.umontreal.ca!premont
From: premont@IRO.UMontreal.CA (Patrick Premont)
Subject: Re: Dylan Competitive Analysis: Dylan vs. SmalltalkAgents?
Message-ID: <D56zEH.BCu@IRO.UMontreal.CA>
Sender: news@IRO.UMontreal.CA
Organization: Universite de Montreal
X-Newsreader: TIN [version 1.2 PL2]
References: <13808.9503011536@subnode.aiai.ed.ac.uk> <3j2s8r$ohh@cantaloupe.srv.cs.cmu.edu> <CONVERSE.95Mar2125940@orca.uchicago.edu> <3jde3u$aha@cantaloupe.srv.cs.cmu.edu> <3jmfdq$1n3@gap.cco.caltech.edu>
Date: Thu, 9 Mar 1995 21:23:04 GMT
Lines: 49

Seth LaForge (sethml@sloth.ugcs.caltech.edu) wrote:

: I would tend to agree that a standard, more machine-manipulatable form
: would be useful.  How about s-expressions?  In fact, how about the
: original prefix notation described in DRM?

If I may voice my opinion on that matter, I would suggest we do NOT
use s-expressions. By s-expression I understand a list whose first
element is an operator and the rest are its arguments.

In Dylan it would look like that
list(\+,3,4)

Note we would need a quote objet to distinguish between constants (which
may be lists) and programs.

Instead I think we should use instances of a class <program> to
represent programs.

The class hiearchy could look like that :

<program>
  <call>
    <function-call>
    <macro-call>
  <constant>
  <variable-reference>

So a Dylan implementation writen in Dylan could define
generic functions like CPS-convert, compile, analyse, optimize, ...
with methods for each type of program constuct.

It would be nice if the <program> class had a slot called something
like annotations. Or maybe that would be the job of an
<annotated-program> class. This would be very useful when performing
an analysis on a program.

: I think it would be a very Good Think if Dylan implementation were
: required to support both the infix and the prefix forms.  There would
: also have to be a defined transformation between the forms, so that
: any infix expression could transformed into the prefix form.  It might
: be handy to be able to the reverse transformation as well.  This would
: have several possible benefits:

The parsed representation of Dylan programs should be distinguished from
the sequence-of-characters representation of Dylan programs. Once parsing
is done, the question of using prefix or infix notation becomes irrelevent.

Patrick Premont
