Strong typed system

[btanksley@hifn.com]

From: Armin Rigo [mailto:arigo@planetquake.com]

>[First of all, excuse me if the principles I expose have already been
>discussed. I am new to the Tunes project and the mailing list 
>archives are very large !]

Welcome in!

>There are two basic principles a modern system should, in my 
>opinion, rely on :

> * as far as possible, the system manages communication
>   between applications (let's call them "modules"); it
>   is *not* the application that should directly ask the
>   system (or other modules) for some functionnalities.

I agree that the system should manage communication.  I don't understand
what you mean by saying that the application should never ask the system;
how will the system be able to manage something that never occurs?

> * the system must know exactly what it is doing at any time.

I have no idea what you mean by this.  In keeping with my reputation, this
means that I must violently oppose you.  :-)

Seriously, though, my general philosophy of programming is to give the
computer as little to do as possible at any given time.  If I made the
computer responsible for "knowing" what it was doing, that would be another
level of bugs to creep in.  I would rather the computer simply DO what I
told it to.

>The second point asks for an advocacy of strongly typed systems. [note:
>below I go against some important points of languages like Slate. If I
>miss something important please attack my position.]

Will do ;-).

Strong typing serves two purposes: first, to catch category errors, and
second, to permit conveniences such as polymorphism.  I don't see how it
helps a system know anything.

>Let's consider the language level first. It seems to me quite 
>natural to
>ask for the type of the objects you are working with to define the
>possible operations on them. It seems obvious, but as far as I know no
>programming language applies this rule at the syntax level : using an
>operator, calling a function or sending a message is always something
>defined (and allowed) by the syntax. This is true if you are 
>considering
>either Pascal/C++-like languages, in which "foo(a,b)" is syntactically
>correct whatever "foo", "a" and "b" are, or Lisp/Forth-like languages,
>where it is even worse, because the problem of a fixed syntax 
>is solved by
>introducing a very general unified syntax, so that something like "(1 2
>3)" is always syntactically correct.

The "problem" you're looking at here is that all the languages you mention
(except Forth) use a context-independant parser, and you've identified that
parser with their syntax.  That's not really correct; in reality, the syntax
for those languages cannot be described by BNF because it's context
dependant.

Context dependancy means that some things -- for example, type errors -- can
be caught at compile time.  Indeed, all of the languages you list do that.

Forth is an oddball, because it doesn't have a parser.  There is nonetheless
a static type system for Forth which handles polymorphism correctly.

So your complaints about these languages are incorrect; they all meet your
requirements, and you haven't noticed simply because you're only looking at
the BNF.

>I believe that such a general syntax misses the point. Of 
>course it opens
>the door to powerful metaprogramming possibilities, but it 
>lets us write
>just too many "correct" but meaningless expressions. This is against
>Tunes' philosophy of Precision. Also, the fact that the syntax 
>itself no
>longer means anything, in the sense that all expressions share the same
>syntax, is not satisfying in my opinion.

I like Forth, in which expressions have no syntax.

At any rate, this has little to do with Tunes.  You're assuming a single
language with a single representation; Tunes wants to have a single language
with multiple representations.  Syntax is only a surface issue, although
it's an important one.  The less syntax Tunes has, the more flexibly it'll
be able to represent its code.

>This solution is to be thought in a more general scope, based on the
>principle that the type of the data that the language/the 
>system/whatever
>else manipulates is fundamental. For example, with that idea in mind, a
>parser-generated binary version of the source code could be 
>very compact,
>because there is no need to encode the number of arguments of the
>expression, for example -- this is determined by the type of the
>expression itself.

This is used in Oberon's slimBinaries.  Although you DO realise that the
type of the expression DOES encode the number of arguments; it's fundamental
information theory that SOMEONE has to.  I think what you're saying is that
this info is encoded incrementally, with each part encoding ONLY what it
uniquely needs to know and which wasn't already encoded.

>This seems to address a number of the problems listed in "LLL
>difficulties" (http://tunes.org/LLL/index.html#Difficulties). 
>All data in
>memory must be of known type, so there is no need for tricks like
>specifying in the low bit of integers whether the data is an 
>integer or a
>pointer. Similarily, the "mark" pass of the garbage collector becomes
>straightforward and opens to great optimizations.

Who knows the type?  Someone must.  Personally, I believe that it's enough
that the programmer knows and his compiler checks, and then with a secure
binary the user's loader should check -- but Tunes seems to believe that the
runtime system should also know the type.

Really, though, your ideas make sense.  If type info is stored in a system,
it really does make sense to store it incrementally, rather than
redundantly.

>Armin Rigo

-Billy