Another reason to like static types

[Joel Shellman]

Where on the to do list is providing type annotations to kl?

Will the type annotations be limited to kl types? For example, I need
the type annotation to tell me whether it's a float or int. Can it do
that? If not, I'll need to figure out how to make that work. I need to
be able to know at compile time the types of numbers (float or int or
maybe other things) going into arithmetic.

Doing arithmetic is messy without knowing types at compile time. The
bytecodes I had to do to deal with just two types (long and double)
was many 10's of bytecodes. It should be just 3, or even just 1 if you
don't count loading the params.

Here's the equivalent Java source code I had to use just to do a
simple addition (it might not have to be quite this ugly, but I did it
this way to make sure it worked):

Object x = 10l;
Object y = 7l;
if (x instanceof Long && y instanceof Long) {
return (long) x + (long) y;
} else {
return (x instanceof Long ?
(double)(((Long)x).longValue()) : (double) x)
+
(y instanceof Long ?
(double)(((Long)y).longValue()) : (double) y);
}

I decompiled clojure and it's even bigger to do addition, though it
deals with more than 2 numeric types.

[Mark Tarver]

On May 26, 9:33 pm, Joel Shellman <j...@mentics.com> wrote:
> Where on the to do list is providing type annotations to kl?

It's there but not high because I placed portability above performance
in my design. However ongoing work with Carl may change that. Like
most people, I follow my interests unless there is some financial
incentive to do something outside of them. Generating reliable type
annotations can be done, but the degree to which these can be used
will vary from platform to platform. I'll say that IMO the route to
generating these annotations lies in dependent types. It would take
some space to explain the correct approach here and it would need to
be tested.

>
> Will the type annotations be limited to kl types? For example, I need
> the type annotation to tell me whether it's a float or int. Can it do
> that? If not, I'll need to figure out how to make that work. I need to
> be able to know at compile time the types of numbers (float or int or
> maybe other things) going into arithmetic.

As regards the spec; there is no restriction. Again the range of
useful types will depend on the resources of the platform.

> Doing arithmetic is messy without knowing types at compile time. The
> bytecodes I had to do to deal with just two types (long and double)
> was many 10's of bytecodes. It should be just 3, or even just 1 if you
> don't count loading the params.
>
> Here's the equivalent Java source code I had to use just to do a
> simple addition (it might not have to be quite this ugly, but I did it
> this way to make sure it worked):
>
>         Object x = 10l;
>         Object y = 7l;
>         if (x instanceof Long && y instanceof Long) {
>             return (long) x + (long) y;
>         } else {
>             return (x instanceof Long ?
> (double)(((Long)x).longValue()) : (double) x)
>                     +
>                     (y instanceof Long ?
> (double)(((Long)y).longValue()) : (double) y);
>         }
>
> I decompiled clojure and it's even bigger to do addition, though it
> deals with more than 2 numeric types.

Yes; this is because Shen and CL (+ prob. Clojure though I've not used
the raw REPL) have a free-wheeling approach to arithmetic which allows
you to mix different numeric types and still get a result. At a lower
level this can turn into a big case statement in which flexibility is
paid for by dynamic checking.

Mark

[Joel Shellman]

> Yes; this is because Shen and CL (+ prob. Clojure though I've not used
> the raw REPL) have a free-wheeling approach to arithmetic which allows
> you to mix different numeric types and still get a result.  At a lower
> level this can turn into a big case statement in which flexibility is
> paid for by dynamic checking.

That's exactly what it is in Clojure. It's a big case statement
including not just primitives but things like BigDecimal, too.