[apt4ssx8] Re: APT Grammar
- From: "Kent A. Reed" <kentallanreed@xxxxxxxxx>
- To: apt4ssx8@xxxxxxxxxxxxx
- Date: Fri, 22 Jun 2012 10:27:29 -0400
On 6/22/2012 1:06 AM, Brent Muller wrote:
<...stuff about X3.37-1999...>
I don't know that the standard was ever even used by anyone- there are some
pretty glaring errors in the syntax that someone who was actually applying it
would catch. I like the newer language features, but the standard is really
huge- they left out the KITCHN and SINK keywords, but that's about it. I
think trying to implement the whole thing would distract from the important
things of the project, if that was even a direction we wanted to go.
That's the trouble with standards committees. Everybody brings their
favorite topics to the table. They manage to reach consensus by being
inclusive and vague.
Some committees work under a strict rule that no proposal be considered
until after it has been implemented by someone. About the time Version 3
of IGES was released, we adopted the Clapp rule (no new functionality be
accepted for consideration unless at least two parties assert they need
it to interchange information) and its Harrod amendment (no new feature
be approved until it has been implemented by and used to interchange
information among least three different parties). Unfortunately, the
ISO/STEP chairman believed his committee was being
pro-active---developing standards for technology that didn't exist
yet---and therefore shouldn't be held back by such mundane concerns.
Much merriment ensured.
As for errors in syntax, many language standards contain them. Here we
have committees working on languages that are to be processed by machine
and they construct their manuscripts by manual typewriter and word
processor. The ISO committee that produced a standard version of EBNF
was so bold as to call out some of the offenders by way of explaining
why it thought its own work was necessary and useful.
I mention this because I have the outlines of a parser in the Aptos
code. It already does quite a bit of the ANSI syntax, and creates a
parse tree using Yacc.
<snip>
Now that I've waved my prejudice around, I'll say that comparing what
you've already done with what I'm trying to do (and with my
understanding of ANSI X3.37-1999) would be interesting. Is your grammar
anywhere I can see it?
Yes. If you go to sourceforge and browse the repository, you can look at the
yacc and lex files I created. It will be in the aptos section of the cvs
repository. You can also download a sandbox via cvs and using "aptos" as the
project name.
My apology. I'm sure I looked over your repository at some time but once
I downloaded the APT360 code I forgot about the rest.
I've extracted lists of processor and postprocessor words from your file
apt.y, combined the two, removed duplicates, and posted the resulting
file, aptos-vocab.unix (.unix --> "\n" newlines) to my google site along
with some trivial statistics from comparisons of this list with my
apt360 list.
The section 2 code is pretty complete and debugged- I remember reading the
history of Apt, and I think I remember reading Doug Ross saying that MIT had
to help out the industry people who were having problems with it. That's one
reason I don't want to touch section 2. If you want to know kind of how
section 2 works, the only place I have found the math explained is in
"Computational Geometry for Design and Manufacture" by Faux and Pratt, in the
last chapter. The details of implementing it, however, would be the gory
part.
I totally agree, and thanks for the reference.
We've learned a lot about language design since then, though, and language
design in section 1 is the best place to improve Apt, IMHO. Structured
programming constructs and local variables come to mind.
Agreed. While I attribute a number of the offensively unstructured bits
in APT360 to its built-by-a-committee approach rather than to FORTRAN,
there's no point in perpetrating any of the madness.
I implemented the C language routines in apt360 as much like the original
assembler as I could guess, and that meant doing things in a way that would be
totally obsolete today. When you run apt360, you will notice that there are a
lot of ".tap" files created. (cl.tap, pro.tap, srf.tap, poc.tap, err.tap).
That's because when they ran out of the memory on these machines that had no
dynamic memory, they wrote to tape. So the cl.tap file is the output file for
the post-processor, for example, and the srf.tap file saves the variables of
large surfaces (I think- been a while). As a result of the parse, the
geometry statements are calculated in canonical form, and the motion
statements are put in symbolic form in pro.tap in prep for section 2.
Afterward, section 3 did any transforms, like INDEX and COPY, TRACUT, etc.,
and generated the cl.tap. Section 4 was the post-processor.
I twigged to the working files right away probably because I used to
have to deal with such things myself. I know it has become trite to say
this, but my iPhone has more compute power and more storage capacity
than the biggest mainframe I could access up until the time I turned to
workstations in the 1990s, and I don't have to share my iPhone with all
the other users. Well, I tell a lie. My grandkids are constantly
borrowing it to play Angry Birds.
I think you did a yeoman's job transliterating the ASM routines. The
biggest disadvantage of transliteration is that it brings forward a lot
of goofiness about tapes (both mag and punched) and access methods but
you got it to work. To quote my Aussie friends, "Good on ya, mate."
The interesting thing for me was the pro.tap file- this is in a form that is
binary and created from section one. The pro.tap file is the clean division and
the possible link between a new frontend that I mentioned. I actually started
on this in aptos, and you might see what I was doing if you look at the aptos
code. We would just need to have a frontend create a pro.tap file (probably in
memory instead of tape) and then send it to section 2. Voila, functioning Apt
with new language constructs, yet very solid. Something similar could be done
with the ssx8 code, I would think.
Good idea. I saw your beginnings of an annotated pro.tap record in your
documentation but didn't pursue it at the time because of my own
intentions/biases. Let's hope the ssx8 code does indeed show up. I
suspect it will be mostly the APT4 code we already know and love,
augmented with experimental sculptured surface support. I can hope it
will include some clean up and restructuring, and maybe even introduce
random-access disk storage, but I'm not planning on it.
Regards,
Kent
Other related posts:
