! versus @, optional typing?

[Brian T Rice]

On Wed, 4 Jun 2003, Paul Dufresne wrote:

> I am confuse by both having @ and !.
>
> As I understood, x!Boolean means x is of type Boolean,
> and x at Boolean, is a Compiler hint suggesting were to compile the method.
> But how do you define the type of an object?

The type system is fairly poor right now. It's hardcoded for now.

Eventually we (this most likely means "I") will work on a way to infer an
object's applicability to a type to be based on some inference, but this
is not a schedulable feature.

> Well, I have some problems distinguishing between:
> _@(Boolean) foo: [bar].
> and
> _!Boolean foo: [bar].

Well, considering that the latter is totally invalid, since there is no @
to distinguish it from a message-send, there's not much to be confused
about. :) The first implies the second, basically.

Type annotations say absolutely nothing about dispatch. If we were to do
that, we'd invite all kinds of algorithmic complexities to the dispatch
system. Imagine adding a type saying that a method needs an argument
Integer to be prime! It just doesn't work.

The type annotations are efficiency hints; they serve a totally different
function. They exist to assist the type inferencer, which is the real star
of the show (this is what makes "@(Boolean traits)" lead the compiler to
know "!Boolean" in advance). Furthermore, type annotations on the input
arguments to a named method have to be made in the block header, if I
remember correctly (we may have allowed it in the signature as long as
some dispatch notation was also used).

> I can hardly imagine:
> _!Boolean at String foo: [bar].
> Why one would compile code on a Boolean type in String.

Sure, this should generate a compilation error, or at least discard the
type annotation, because the dispatch is the meaningful annotation and
takes precedence over the typing.

> Will we remove @ from Slate, one day, just keeping ! ?

Nope. They serve totally different purposes.

In a sense, both will "go away" if we manage to create an IDE where these
annotations are made graphically or spatially, but the essential meanings
should stay.

-- 
Brian T. Rice
LOGOS Research and Development
http://tunes.org/~water/