Re: Algol 60 Syntax

dsutton@acumen1.com (Dan Sutton)
19 Jan 2000 01:26:09 -0500

          From comp.compilers

Related articles
[4 earlier articles]
Re: Algol 60 Syntax dvdeug@x8b4e53cd.dhcp.okstate.edu (2000-01-15)
Re: Algol 60 Syntax wclodius@aol.com (2000-01-15)
Re: Algol 60 Syntax steve.ross@rmc-ltd.com (Steve Ross) (2000-01-15)
Re: Algol 60 Syntax Martin.Ward@smltd.com (2000-01-15)
Re: Algol 60 Syntax dsutton@acumen1.com (2000-01-15)
Re: Algol 60 Syntax mah@colorado.edu (ma haibing) (2000-01-15)
Re: Algol 60 Syntax dsutton@acumen1.com (2000-01-19)
Re: Algol 60 Syntax wclodius@lanl.gov (William B. Clodius) (2000-01-21)
| List of all articles for this month |
From: dsutton@acumen1.com (Dan Sutton)
Newsgroups: comp.compilers
Date: 19 Jan 2000 01:26:09 -0500
Organization: Opwernby, inc.
References: 00-01-037 00-01-052
Keywords: parse, UNCOL

>I wanted to sound a note of caution on the universal language
>transformation theme, though. The problem with transforming between
>two languages A and B via some interim representation R (Forth,
>byte-code, etc.) is that the interim form ends up as a sort of least
>common denominator. Each semantic unit of A (a data definition, a
>statement) maps onto one or more semantic units in R. This transform
>is easy.


>That's not to say that language transformation is a useless goal, but
>that it should always be a human-driven process, with the
>transformation tool as an aid, and never a fully-automated process.
>Other inputs, such as a model of the application architecture, can
>help produce a meaningful transformation.


Yes, I know. My problem is not so much matching syntax, but, as you
say, semantics. The goal, therefore, is to develop a functional
semantics representation notation (which may then be incorporated as
this interim representation) - a sort of BNF for semantics, as it
were: as you point out, this has so far proven to be impossible...


..but I'm willing to give it a go - I have an idea or two, but I must
confess that every time I try to nail down a *perfect* (?) algorithm,
I tend to fail, largely due to the vast amount of special cases,
although it seems to me that I'm missing something - perhaps the
special cases are a normal occurrence and should thus be regarded as
just another normal function, or something?


I get a bit farther each time, though - I still think it's possible:
after all, if one can describe to a person how to do it such that it
makes sense and they can continue to do it for code they've never
seen, then it must be possible to describe it to a machine, since
there are definitely rules involved.


I have a feeling that the thing will have to contain a certain amount
of AI (because a lot of what it will have to do will involve judgment
calls), and, for the same reason, also be able to be taught: I think
that, like a person, it will have to learn from experience rather than
having a preconceived notion of how to compile anything. Of course,
teaching it would be a rather time-consuming process, but, hell, it
beats sitting around getting smashed, anyway...


..if I succeed, however, I feel that I will probably sit around
getting smashed for a large part of that evening and most of the next
day.


Regards
Dan
[The huge number of special cases is the UNCOL heat death problem that I
referred to in a previous message. It's a very interesting problem, but
please look at previous failed efforts so you don't just fail the same way.
-John]







Post a followup to this message

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