Typed Guile?

Typed Guile?

[thorsopia]

Hi,

The first part of this message may look irrelevent, but you'll
understand why I decided to start this way.

I'm going to write a library.

Here is the list of things I care about (from the most important to
the least important):

 - Strict type system;
 - Wide community;
 - Performance.

There are several candidates:

 - Haskell;
 - Typed Racket;
 - Typed Clojure*.

Which one should I choose?

(Please don't answer right now.)

I've already tried to ask TR people:

"Typed Racket is designed for Racket. One day Guile will have a Typed
Guile companion, and Chez Scheme may have a Typed Chez companion but
until then TR is for Racket." [1]

Is it this bad? Do we really need Typed Guile?

Can we somehow adapt the static code to achieve its features in Guile?

I'm really concerned about code reuse. It's time to stop reinventing
the wheel.

My writing skills are not very great...
So I'm going to summarize the above:

 1. What language should I choose for my library?
 2. Do we need Typed Guile?

* I know nothing about TC's type system, but it's a possible candidate.

[1] http://lists.racket-lang.org/users/archive/2012-September/054037.html
    (This is not the first message on this thread.)

Re: Typed Guile?

[Noah Lavine]

Hello,

Here are a few random thoughts: I had a project a little while ago to
try to get some of the benefit of static typing in Guile. It never
went very far, but actually some of the same machinery is coming to
the surface in the compiler anyway. I think it could be taken farther,
to the point that Guile really would have the benefits of a
statically-typed language.

However, what's in Guile right now is not that, and it might take some
work to get it there. So no, Guile is not statically typed right now.

Performance is another interesting question. Of the things you named,
only Guile doesn't compile to native code (yet), so that's going to be
a performance hit. However, performance is relative. Since you didn't
list C or Fortran as choices, you don't care about having extreme
control over what your machine is doing; I don't know enough about
your goals to know whether Guile will give you the performance you
want. But Guile can be extended in C, so you have the option to go as
fast as you want.

That's the best I can do without knowing more about your library.

Thanks,
Noah Lavine

On Tue, Sep 18, 2012 at 10:06 PM,  <thorsopia@lavabit.com> wrote:
> Hi,
>
> The first part of this message may look irrelevent, but you'll
> understand why I decided to start this way.
>
> I'm going to write a library.
>
> Here is the list of things I care about (from the most important to
> the least important):
>
>  - Strict type system;
>  - Wide community;
>  - Performance.
>
> There are several candidates:
>
>  - Haskell;
>  - Typed Racket;
>  - Typed Clojure*.
>
> Which one should I choose?
>
> (Please don't answer right now.)
>
> I've already tried to ask TR people:
>
> "Typed Racket is designed for Racket. One day Guile will have a Typed
> Guile companion, and Chez Scheme may have a Typed Chez companion but
> until then TR is for Racket." [1]
>
> Is it this bad? Do we really need Typed Guile?
>
> Can we somehow adapt the static code to achieve its features in Guile?
>
> I'm really concerned about code reuse. It's time to stop reinventing
> the wheel.
>
> My writing skills are not very great...
> So I'm going to summarize the above:
>
>  1. What language should I choose for my library?
>  2. Do we need Typed Guile?
>
> * I know nothing about TC's type system, but it's a possible candidate.
>
> [1] http://lists.racket-lang.org/users/archive/2012-September/054037.html
>     (This is not the first message on this thread.)
>
>
>
>

Re: Typed Guile?

[thorsopia]

Noah,

Can Guile use a library written on a typed language?

I understand that it's not going to work out of the box, but what would be
easier to adapt: Haskell, Typed Racket or Typed Clojure*?

Re: Typed Guile?

[Noah Lavine]

It entirely depends on the typed language. Anything that can compile
to a C-compatible binary should be usable.

I believe that Haskell can do that. You have to explicitly write what
the C entry points are going to be, which might be tedious, but I
think it's for the best anyway. See
http://www.haskell.org/haskellwiki/FFI_Introduction .

I don't know enough about Typed Racket or Typed Clojure to know if
they could do that.

Noah

On Wed, Sep 19, 2012 at 10:24 AM,  <thorsopia@lavabit.com> wrote:
> Noah,
>
> Can Guile use a library written on a typed language?
>
> I understand that it's not going to work out of the box, but what would be
> easier to adapt: Haskell, Typed Racket or Typed Clojure*?
>
>
>

Re: Typed Guile?

[Ian Price]

thorsopia@lavabit.com writes:

> "Typed Racket is designed for Racket. One day Guile will have a Typed
> Guile companion, and Chez Scheme may have a Typed Chez companion but
> until then TR is for Racket." [1]
>
> Is it this bad? Do we really need Typed Guile?

Is what bad? The state of code reuse? yes, frankly.
Do we need typed guile? I dunno, maybe, couldn't hurt. Stis already has
some work porting racket contracts[0], which is kind of a first step.
Languages are going to head in the mixed static/dynamic route anyway, so
it would be worth it to get a head start :P

> Can we somehow adapt the static code to achieve its features in Guile?
Yes, and no. Guile is obviously extensible through C, and it does
support the addition of new languages, and you could write a typed one
if you want, _but_ if you are using it from guile, you will need to do
some sort of type checking at the interface, since obviously all that
can get removed from within static code. This is how racket's contracts
work IIRC. They are enforced at the boundary, but unnecessary inside the
module. 

> My writing skills are not very great...
> So I'm going to summarize the above:
>
>  1. What language should I choose for my library?
What ever you want, as long as it's C, or supported in guile
(Scheme/elisp-sorta/js-sorta), or you write your own $lang library for guile.

0. https://gitorious.org/guile-contract
I haven't actually used this yet, since stis has far too many toys to
play with :) It looks like it's all scheme though, so I could create a
guildhall package for others.

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Typed Guile?

[Panicz Maciej Godek]

> The first part of this message may look irrelevent, but you'll
> understand why I decided to start this way.
>
> I'm going to write a library.
>
> Here is the list of things I care about (from the most important to
> the least important):
>
>  - Strict type system;
>  - Wide community;
>  - Performance.
>
> There are several candidates:
>
>  - Haskell;
>  - Typed Racket;
>  - Typed Clojure*.
>
> Which one should I choose?
>
> (Please don't answer right now.)

Oh, come on, it's been months!

> I've already tried to ask TR people:
>
> "Typed Racket is designed for Racket. One day Guile will have a Typed
> Guile companion, and Chez Scheme may have a Typed Chez companion but
> until then TR is for Racket." [1]
>
> Is it this bad? Do we really need Typed Guile?
>
> Can we somehow adapt the static code to achieve its features in Guile?
>
> I'm really concerned about code reuse. It's time to stop reinventing
> the wheel.
>
> My writing skills are not very great...
> So I'm going to summarize the above:
>
>  1. What language should I choose for my library?
>  2. Do we need Typed Guile?

I'm glad that you wrote. I'm really dying for a good type system for
guile. Obviously, type system can, in the long run, have some positive
impact on performance, as it allows to avoid run-time type checking.
But this isn't my concern for now.
For me, the biggest (and most urgent) issue is the expressive power of
the language, and second biggest, error-proneness.

I've heard a lot about the type system of Haskell, but I don't know
any details. Neither do I know much about racket's, but I know for
sure that it doesn't suit my taste.

There is, however, a good base for a type system shipped with guile's
GOOPS. And I think that it would be wisest to extend it, so the
language remains coherent.

GOOPS' type system is lacking two features, the first one being the
return value of a procedure, and the second, types for collections.

So I think, that type annotation for the return value of a method
could be a coherent extension to the existing system. For example, one
could write:
(define-method (name (arg1 <type1>) ... (argN <typeN>)) : <return-type>
  body ...)
slightly extending the define-method as it is used today.

The second postulate is more difficult to agree upon with. I think the
nicest way would be to use the omnipresent pattern language, so for
instance the procedure taking the list of numbers could be written as:
(define-method (mean (S (<number> ...))) : <number>
  (/ (apply + S) (length S)))

(define-method (mean (v #(<real> ...))) : <number>
  (mean (vector->list v)))

It could be similarly used to define methods with variable number of
arguments of the same type, e.g.
(define-method (mean (n <number>) . (rest (<number> ...))) : <number>
  (mean (cons n rest)))

Unfortunately, the pattern language alone would be insufficient, at
least not in its present shape. That's because we would also like to
be able to specify the types of hashes and procedures, like below
(it's actually inspired by the code that I'm writing at the moment):
(define-method
  (handle-clients
    (connection (<number> . <number>))
    (clients (hash (<number> . <number>) (hash <symbol> <procedure>)))
    (handle-new-connection ((procedure <number>) : (hash <symbol>
<procedure>))))
  [body])

I don't know to what extent is this readable. My intention is that the
syntax (hash <key-type> <value-type>) would express a hash table such
that all its keys are of type <key-type>, and values of <value-type>,
respectively.
Similarly, ((procedure <arg1-type> ... <argN-type>) : <return-type>)
stands for the procedure of a certain type.
This notation is just a proposition for what I'm willing to express.
There is a question regarding the implementation, however (especially,
defining new types). I think it would be a problem for the
pattern-matcher to distinguish between (hash <key-type> <value-type>)
[a hash] and (<hash> <key-type> <value-type>) [a list], so maybe
another notation would be required (like (% hash ...), (% procedure
...), or #%hash(<k> <v>) ..., or something similar).

I think that parsimony is one of the advantages of such a type system.
One could say that having any type system is better than having none,
but I don't think that this refers to the realm of Scheme :)
Secondly, building it atop of GOOPS would be valuable in this respect,
that it could be later adapted by the chicken's scheme COOPS object
system, which also derived from CLOS and seems compatible with GOOPS
(vide http://wiki.call-cc.org/eggref/4/coops).

I don't know what the rest of the community has to say about this, but
if you managed to implement this, I can promise that you'd have at
least one user :)

(Among the things that I dislike in the typed Racket is that firstly
it posits plurality without necessity, introducing labels like Listof,
that a programmer needs to memoize or look up in the documentation,
and secondly, it introduces not-much-telling identifier :, which,
although looks joyfully when used ("(:"), is quite far from the spirit
of SICP)

BTW Does anyone here know what does the #& ("box") quasi-pattern in
the Shinn-Wright pattern matcher stand for?

Best regards :)
M.

Re: Typed Guile?

[Ludovic Courtès]

Hi,

Panicz Maciej Godek <godek.maciek@gmail.com> skribis:

> There is, however, a good base for a type system shipped with guile's
> GOOPS. And I think that it would be wisest to extend it, so the
> language remains coherent.

GOOPS provides nothing beyond syntactic support.  It’s only about
dynamic typing.

For static typing, you’d need (at least) the ability to pass type
annotations along with tree-il objects, and a type inference system.

[...]

> BTW Does anyone here know what does the #& ("box") quasi-pattern in
> the Shinn-Wright pattern matcher stand for?

Good question, but AFAICS it’s not in Alex Shinn’s version.

Ludo’.

Re: Typed Guile?

[Ian Price]

Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> I've heard a lot about the type system of Haskell, but I don't know
> any details. Neither do I know much about racket's, but I know for
> sure that it doesn't suit my taste.
How can you accurately judge something you don't know much about?

> GOOPS' type system is lacking two features, the first one being the
> return value of a procedure, and the second, types for collections.
>
> So I think, that type annotation for the return value of a method
> could be a coherent extension to the existing system. For example, one
> could write:
> (define-method (name (arg1 <type1>) ... (argN <typeN>)) : <return-type>
>   body ...)
> slightly extending the define-method as it is used today.
Adding syntax for this is easy, but it would completely change the
nature of Scheme. How does a procedure know which type to return?

It can either infer it, which requires more than a simple extension of
goops, or you can return some sort of "value", than you then tell which
type you expect it to have. Which may mess with the order of
evaluation (I'd more time to think about this), and wouldn't play well
with non-goops procedures.

At least, these are my immediate reactions, I will be happy to be proved
wrong. (I'm going to CC Typed Racket's SamTH, I expect a clos-like
solution has been suggested to him many times, and he might have some
better idea of the pros/cons of this)

> The second postulate is more difficult to agree upon with. I think the
> nicest way would be to use the omnipresent pattern language, so for
> instance the procedure taking the list of numbers could be written as:
> (define-method (mean (S (<number> ...))) : <number>
>   (/ (apply + S) (length S)))
>
> (define-method (mean (v #(<real> ...))) : <number>
>   (mean (vector->list v)))
>
> It could be similarly used to define methods with variable number of
> arguments of the same type, e.g.
> (define-method (mean (n <number>) . (rest (<number> ...))) : <number>
>   (mean (cons n rest)))

This will not work with arbitrary user defined collections?

> Unfortunately, the pattern language alone would be insufficient, at
> least not in its present shape. That's because we would also like to
> be able to specify the types of hashes and procedures, like below
> (it's actually inspired by the code that I'm writing at the moment):
> (define-method
>   (handle-clients
>     (connection (<number> . <number>))
>     (clients (hash (<number> . <number>) (hash <symbol> <procedure>)))
>     (handle-new-connection ((procedure <number>) : (hash <symbol>
> <procedure>))))
>   [body])
>
> I don't know to what extent is this readable. My intention is that the
> syntax (hash <key-type> <value-type>) would express a hash table such
> that all its keys are of type <key-type>, and values of <value-type>,
> respectively.
> Similarly, ((procedure <arg1-type> ... <argN-type>) : <return-type>)
> stands for the procedure of a certain type.
> This notation is just a proposition for what I'm willing to express.
> There is a question regarding the implementation, however (especially,
> defining new types). I think it would be a problem for the
> pattern-matcher to distinguish between (hash <key-type> <value-type>)
> [a hash] and (<hash> <key-type> <value-type>) [a list], so maybe
> another notation would be required (like (% hash ...), (% procedure
> ...), or #%hash(<k> <v>) ..., or something similar).
>
> I think that parsimony is one of the advantages of such a type system.
> One could say that having any type system is better than having none,
> but I don't think that this refers to the realm of Scheme :)
> Secondly, building it atop of GOOPS would be valuable in this respect,
> that it could be later adapted by the chicken's scheme COOPS object
> system, which also derived from CLOS and seems compatible with GOOPS
> (vide http://wiki.call-cc.org/eggref/4/coops).
>
> I don't know what the rest of the community has to say about this, but
> if you managed to implement this, I can promise that you'd have at
> least one user :)

Unless you give me more details about how this is to work, I think an
implementation is out of the question.

> (Among the things that I dislike in the typed Racket is that firstly
> it posits plurality without necessity, introducing labels like Listof,
> that a programmer needs to memoize or look up in the documentation,
> and secondly, it introduces not-much-telling identifier :, which,
> although looks joyfully when used ("(:"), is quite far from the spirit
> of SICP)
>
> BTW Does anyone here know what does the #& ("box") quasi-pattern in
> the Shinn-Wright pattern matcher stand for?
A box is, more or less, a one element vector. Guile does not have a box
type, nor reader syntax for it, arguably it should...

-- 
Ian Price -- shift-reset.com

"Programming is like pinball. The reward for doing it well is
the opportunity to do it again" - from "The Wizardy Compiled"

Re: Typed Guile?

[Sam Tobin-Hochstadt]

[Replying just to this small bit. Also not on guile-user, so please cc
me on replies]

On Thu, Nov 8, 2012 at 3:46 PM, Ian Price <ianprice90@googlemail.com> wrote:
>
> At least, these are my immediate reactions, I will be happy to be proved
> wrong. (I'm going to CC Typed Racket's SamTH, I expect a clos-like
> solution has been suggested to him many times, and he might have some
> better idea of the pros/cons of this)

Racket does not make much use of CLOS-style object systems [1], so I
haven't thought about adding something like this to Typed Racket.
We've recently been developing a generics system in Racket [2], when
it comes time to handle that in Typed Racket it may result in
revisiting this question, although it is also single dispatch.

Type systems for CLOS-like systems have been looked at in the past by
Craig Chambers, among others.

[1] Eli Barzilay has implemented one in Swindle, but it's rarely used.
 The class-based OO system in Racket *is* widely used.
[2] http://docs.racket-lang.org/reference/struct-generics.html
--
sam th
samth@ccs.neu.edu

Re: Typed Guile?

[Panicz Maciej Godek]

2012/11/8 Ian Price <ianprice90@googlemail.com>:
>> I've heard a lot about the type system of Haskell, but I don't know
>> any details. Neither do I know much about racket's, but I know for
>> sure that it doesn't suit my taste.
> How can you accurately judge something you don't know much about?

Because it's my taste that I'm judging, and on this I'm the expert :)
(Obviously, I did a tiny research before responding to the e-mail,
but as a language the TR system seemed too far away from scheme
and too complex syntactically and lexically. Perhaps it's just the appearance,
semantically meaningless, to be pleonastic, but I find the aesthetic part
of programmer's experience quite significant)

>> GOOPS' type system is lacking two features, the first one being the
>> return value of a procedure, and the second, types for collections.
>>
>> So I think, that type annotation for the return value of a method
>> could be a coherent extension to the existing system. For example, one
>> could write:
>> (define-method (name (arg1 <type1>) ... (argN <typeN>)) : <return-type>
>>   body ...)
>> slightly extending the define-method as it is used today.
> Adding syntax for this is easy, but it would completely change the
> nature of Scheme. How does a procedure know which type to return?

I think I see the point. This is indeed a good question, and an
interesting task,
but initially it could be implemented only partially (we just check whether
the declared argument types match, so for instance if we had a
((p1 <type1>) : <type2>) and (p2 <type2>), and then we could typecheck
that (p2 (p1 x)) is OK at least in terms of declaration, and we could
additionally issue runtime warnings if the actual return type didn't match
the intended one).
More sophisticated type inference could be developed later, and the
type system could prove useful even without it.
And I don't know what you mean when you say about "changing
the nature of Scheme". I think it's understood that the type system
is completely optional.

> It can either infer it, which requires more than a simple extension of
> goops, or you can return some sort of "value", than you then tell which
> type you expect it to have. Which may mess with the order of
> evaluation (I'd more time to think about this), and wouldn't play well
> with non-goops procedures.

I'm not sure if I read you right, but perhaps it would be enough to
implement type system for goops procedures only. And I think that type
checking could be a separate stage, independent from compilation or
evaluation -- but that's mainly because I don't know much about
guile's evaluator nor compiler.

[...]
>> It could be similarly used to define methods with variable number of
>> arguments of the same type, e.g.
>> (define-method (mean (n <number>) . (rest (<number> ...))) : <number>
>>   (mean (cons n rest)))
>
> This will not work with arbitrary user defined collections?

I'd need to see an example. (As I remarked, my main intent in having a
type system is to make the code clearer). I can't even imagine how
does one define a collection in Scheme.
But I agree that the notation that I proposed has some serious
deficiencies. For instance, how to mark the type of a procedure that
takes whatever arguments, and returns a strict type?
((procedure . args) : <type>)?
((procedure . <top>) : <type>)?
Is it ok that this specification is a nested list?

>> I don't know what the rest of the community has to say about this, but
>> if you managed to implement this, I can promise that you'd have at
>> least one user :)
>
> Unless you give me more details about how this is to work, I think an
> implementation is out of the question.

As I said, initially it could be a stage separate from compilation and
evaluation.
I even think that the type inference wouldn't need to be so
complicated, because there are strict rules regarding which value is
the value of expression. If it's a conditional, we just check return
values of both branches. If it's a call/cc, we check all the calls of
its argument's argument, and so on, ad finitum :)
Obviously, some compiler optimizations regarding the types could be
added with the time, but for now I don't consider them crucial.
That's how I see it, more or less.

>> BTW Does anyone here know what does the #& ("box") quasi-pattern in
>> the Shinn-Wright pattern matcher stand for?
> A box is, more or less, a one element vector. Guile does not have a box
> type, nor reader syntax for it, arguably it should...

Thanks a lot :)
MG