Subject: Re: shootout: implementing an interpreter for a simple procedural language Minim
From: rpw3@rpw3.org (Rob Warnock)
Date: Tue, 14 Aug 2007 21:06:36 -0500
Newsgroups: comp.lang.lisp,comp.lang.functional
Message-ID: <-eOdnWEYuJ4xwl_bnZ2dnUVZ_rignZ2d@speakeasy.net>
Kaz Kylheku  <kkylheku@gmail.com> wrote:
+---------------
| On Aug 13, 2:06 pm, Thant Tessman <a...@standarddeviance.com> wrote:
| > A type system is a structure imposed on a computer program in such a way
| > that a machine can check for logical consistency.
| 
| This presents an incomplete, biased view of the role of types in
| programming.  Types arise because of the flexibility of representation
| within the computing machine. A given group of binary digits in memory
| represents information by some rules which govern its interpretation,
| and the set of permissible operations. These conventions together make
| up what we call type. Type tells us that some group of bits is a
| floating-point number, pointer to a linked list, integer, a UNICODE
| character, etc. The type information may be implicit: we are confident
| that some group of bits is an integer, because from the structure of
| the program it appears that the data originated from a function that
| reliably constructs only integers. Or the type information could be
| encoded with a few bits in the data item itself.
+---------------

To quote myself a bit from some years before
<news:QRKdnY0yjq6S9z-iXTWc-w@speakeasy.net>:

[In] the BLISS language data is completely *untyped*, it is
instead the *operators* which are typed, exactly as it is in
assembler languages. Thus BLISS's "+" is typed (int x int) -> int,
while BLISS's FADR (Floating ADd and Round) operator is typed
(float x float) -> float. The following code is a legal BLISS
expression[1], though probably not something anyone would want
to do very often:

    begin local a, b;
      a := 1.0 fadr 1.0;    ! that is, 2.0
      b := .a + 1;
      .b fsbr .a            ! fsbr is floating subtraction
    end

On a machine with IEEE floating point, that block should yield a
value of roughly 2.38e-07...  ;-}
...
Oddly enough, practical exerience in BLISS showed[2] that
"type errors" were one of the *least* common sources of programmer
error in BLISS code. Much more common were misplaced/missing/extra
dots (the "contents-of" operator) and semicolons (which in BLISS
are expression *separators*, not statement terminators).
...
[2] I *think* the following paper may be where this was reported,
    but I'm not completely sure:

	Wulf, W. A., et al., "Reflections on a Systems Programming
	Language," Proceedings of the SIGPLAN Symposium on System
	Implementation Languages, Purdue University, October 197l.

    It may have been here:

	Wulf, W. A., "Systems for Systems Implementors: Some Experiences
	from Bliss," Proceedings of the FJCC, November 1972. 

    Or somewhere else entirely (such as a paper called "Why the dot?",
    which I can't find a reference to at the moment)...


-Rob

-----
Rob Warnock			<rpw3@rpw3.org>
627 26th Avenue			<URL:http://rpw3.org/>
San Mateo, CA 94403		(650)572-2607