Porting to statically typed languages

[Joel Shellman]

I think I have sufficient idea of what needs to happen for the JVM
port that I'm starting to mess around with it. But I very quickly run
into a challenge.

Java is a statically typed language, but as far as I know, the other
ports done so far are to languages which are not statically typed. For
the first effort, I guess I can use java.lang.Object for all
parameters and always return java.lang.Object, but I really don't want
to do that as an end.

And I just realized... this might get rather tricky if I have to
simultaneously support "typeless" mode and typed mode, since I would
want to use different bytecode for typed mode.

It appears that Kl has no type information, which means I can't even
generate typed bytecode for a function since I can't know it's
signature.

This seems to me like it would be a problem for porting to any
statically typed language.

[Mark Tarver]

KL is indeed untyped because the Shen source generates largely s-exprs
which comprise heterogeneous list and vectors of all kinds. This type
is so general that there is little provision for it in typed
programming languages because it is too loose to be useful..

Regarding generated typed Java from Shen, you also have to consider
that the Shen type system is very powerful and therefore things that
are type-expressible in Shen might not be expressible in a typed
platform. You would find it extraordinarily hard to implement Shen in
say ML.

My only other observation is that Clojure is untyped and AFAIK
compiles directly to the JVM. So it should be possible to compile
KLambda to JVM I would think.

Mark

[Dmitry Cherkassov]

Are functions' signatures stored in some hash table via declare
procedure in KL?
If so one could redefine declare function to allow signature storing in
bytcode?

--
With best regards,
Dmitry

[Joel Shellman]

> My only other observation is that Clojure is untyped and AFAIK
> compiles directly to the JVM.  So it should be possible to compile
> KLambda to JVM I would think.

Sorry if I wasn't clear. As I mentioned "I can use java.lang.Object
for all parameters and always return java.lang.Object". That's what
clojure is doing. That's what clojure does for clojure code (even
unrelated to kl/shen) since it is not statically typed.

My concern was that I had an assumption that this would lead to slower
code. However, after my previous post, I ran a benchmark and
discovered for a naive little method, the performance was the same
(within noise) for calling a method with String vs. Object. My
understanding is this is because the JIT these days is very
intelligent and it probably compiled a specialized case that ignored
the casting and such. That's one reason microbenchmarks can be
difficult to interpret :)

That's fine for now, but we are going to run into situations where the
performance difference is going to be very real, especially when
primitives get involved and large numeric processing and such things.
So for those things... maybe that's where we'll have to put in some
extensions in shen to deal with it.

But at this point, I'll proceed with untyped.

> KL is indeed untyped because the Shen source generates largely s-exprs
> which comprise heterogeneous list and vectors of all kinds. This type
> is so general that there is little provision for it in typed
> programming languages because it is too loose to be useful..

That said, working with Haskell has me thinking about typing
everything being interesting. I don't think there's any reason that
you can't type things like that--it might be a rather complex type,
though. I interpret your statement as, perhaps you could type it, but
would there be any benefit to that effort?

What's the point of typing macros? Since we generally run meta-compile
(macro expansion) at the same time as compile (same user action),
we're going to get the type errors at exactly the same time regardless
of whether the macros are typed.

[Mark Tarver]

It can be easily done but tends to contribute little of value and
creates large search spaces in certain situations.

> What's the point of typing macros? Since we generally run meta-compile
> (macro expansion) at the same time as compile (same user action),
> we're going to get the type errors at exactly the same time regardless
> of whether the macros are typed.

Correct.

[Mark Tarver]

> That's fine for now, but we are going to run into situations where the
> performance difference is going to be very real, especially when
> primitives get involved and large numeric processing and such things.
> So for those things... maybe that's where we'll have to put in some
> extensions in shen to deal with it.

Something I should point out - KL has provision for type information
in the spec, though in the current build I'm not doing much with it.
See

http://www.shenlanguage.org/Documentation/shendoc.htm#Type
declarations

Mark

[Mark Tarver]

They are not in hash tables for a complex reason but they can be
accessed fairly easily.

Mark

[Raoul Duke]

>> That's fine for now, but we are going to run into situations where the
>> performance difference is going to be very real, especially when
>> primitives get involved and large numeric processing and such things.
>> So for those things... maybe that's where we'll have to put in some
>> extensions in shen to deal with it.

if Shen code should be callbackable from the underlying host platform,
would typing have to get involved there as well?

[Mark Tarver]

> if Shen code should be callbackable from the underlying host platform,
> would typing have to get involved there as well?

These questions kind of puzzle me.

The point about Shen was that it is supposed to be (and is) portable.
This means that you can generate from any Shen program, the native
code of the platform P and (using suitable bits of Shen source) run it
and hack it if you want. So the question of 'How does Shen
communicate with P and vice-versa?' should not arise (it should be
equivalent to 'How does P communicate with P?'). This is particularly
true because Shen plugs into the native data types for strings etc.

(The FFI solution in the Shen library actually was not aimed at this
question at all, but at getting Shen to communicate with a non-
platform language.)

This view came unstuck with JS and Clojure for different reasons.
With JS because the JS port could not meet one important part of the
Shendoc spec - the ability to write to a file. With Clojure, I'm not
too sure what the problem is - it looks like a package issue.

C:\Users\Mark Tarver\Documents\Computer Science\Languages\Shen\Shen
3.2\Platform
s\Clojure>java -jar shen.clj-0.1.2-standalone.jar

Shen 2010, copyright (C) 2010 Mark Tarver
www.lambdassociates.org, version 3.1
running under Clojure, implementation: Clojure 1.4.0-beta4 [jvm
1.6.0_13]
port 0.1.2 ported by HÕkan RÕberg


(0-) (first [1 2 3]) {first is CAR in Clojure}
java.lang.NullPointerException

(1-) (foo 3)
java.lang.NullPointerException

(2-)

Mark

[Joel Shellman]

Curiously enough, as I'm working on shen-jvm, the hardest thing so far
is what I'm fighting with right now: implementing the arithmetic
functions +,-,*,/. I can't know the types of the parameters to them
until runtime, but the bytecode to execute a + operation depends on
the types (LADD vs. DADD). So... at this point, I have to do all sorts
of casts and conditions. Very icky. Still hoping a better solution
presents itself, but without type info... it's not looking good.