What IS a 'toy' compiler?

V.C. Sreedhar <sreedhar@binkley.cs.mcgill.ca> wrote:
VC> We would like to know from others who have implemented
VC> compilers (not toys)...


Thinking about this made me go 'Hmmm.....' Here's a question: What
defines a 'toy' and what defines a 'compiler'?


      - File I/O or Random access File I/O as part of the language
          specification? (This would then make all "C" compilers 'toys')
      - Self Compilable? (Cobol Compilers are now 'toys')
      - Not Self Compilable (This would then exclude many Pascal Compilers
          and assemblers written in assembly language. UCSD Pascal is an
          extended implementation and is _not_ a toy; the compiler and
          operating system were written in Pascal.)


The real answer should be simple:


      - Capable of compiling into an executable form, programs which can
          do 'real' work? This one isn't bad, but there are enough features
          in the 'toy' compiler, enough that an application could just
          'sneak by' and be coded using that much of the language as the
          compiler supports, you could concevably use it. Perhaps in that
          case it's not a 'toy'?


Size of a compiler won't help much either. I have more than three
different Pascal Compiler sources on hand. One of them is the 'Facilis'
compiler, which I think is over 2500 lines. Lacking file I/O (other than
Input and Output) and lacking the goto statement, it can be classed as a
'toy' since it is not self-compilable and isn't good for most 'real-world'
applications.


Another compiler I have, written under contract to the U.S. National
Bureau of Standards (now NIST) which is a full Pascal Compiler,
self-compilable, but lacks string capabilities and random file I/O. It is
about 7,000 lines. (String capability wasn't defined by Wirth and didn't
come out until UCSD added that and specifications for random file I/O.)
This compiler is not a toy.


Neither is the one from the Australian Atomic Energy Commission (AAEC) for
the IBM-370, which has the same things missing for the same reason. It is
about 5,600 lines plus about another 6,000 in IBM 370 assembly language.
On an IBM-370, the lack of random-access file capability - no VSAM (IBM's
name for B-Trees) access - in effect makes the compiler 'all but' a toy.
There are too many applications which mandate the absolute need for random
file I/O. And if it's not available, the compiler isn't usable for those
applications. It's not that the compiler is a 'toy' it's that the design
specification that the compiler is targeted for (the 1970 Jensen & Wirth
specification for Pascal) is inadequate. Some might say that because the
standard is inadequate, any 'standard' Pascal is a 'toy'. In a way,
that's probably true; sometimes the standard is a joke; nobody would
seriously implement ANSI Standard Basic because the language would be
unusable.


What for one person is a decent compiler for implementing certain
applications and has all of the features of a language, can be to another
person a worthless 'toy' piece of junk. It all depends on whether the
compiler does what you need.


Somehow I get the feeling the real answer to the question "What is a 'toy'
compiler?" can only be answered the way a judge was rumored to have
answered the question "What is 'obscenity'?"


"I don't know, but I know it when I see it!"
---
Paul Robinson -- TDARCOS@MCIMAIL.COM
[My rule of thumb is that it's not a toy if someone other than its author
voluntarily uses it. -John]
--

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