3 ms·

How can you translate from python to a static language, when the code is written for the interfaces, and not types? How willl you translate a function receiving

How can you translate from python to a static language, when the code is written for the interfaces, and not types? How willl you translate a function receiving a (possibly custom) iterable, when the function doesn't care about the type, but just whether it implements a next() method?

sbmassey 14y ago
Haskell type classes are sufficiently flexible to represent things like 'does this type have a next method' without having to instrument the actual type.
- pimentel 14y ago
  But could that kind of type system be considered similar to the usual Java-like little-flexible static typing? I think I would prefer a static vs dynamic implemented as Java vs Python (since those are usually the subjects on every one of these discussions)
  - hythloday 14y ago
    It's identical, conceptually. A type class can be thought of as a degenerate kind of Adapter pattern.
  - ufo 14y ago
    ALthough the name is confusing type classes are very much like interfaces in Java: you define a set of operations that you want and then instantiate concrete types to that interface. The major differences between type classes and interfaces are: * In Java interfaces the interfaced type is restricted to the first argument (the this). In Haskell interfaces the interfaced type can also appear on return values and arguments. * In Java you need to decide what interfaces to implement when you create your class. Haskell allows interfaces to be implemented for previously existing types. * Java allows for subtyping. You can turn a monomorphic program into a polymorphic one just by creating subclasses while in Haskell you would need to rewrite your code to be explicitly polymorphic.
dons 14y ago
> the function doesn't care about the type, but just whether it implements a next() method? You're describing an "existential" type.
- dllthomas 14y ago
  ... or a typeclass.
pja 14y ago
Hindley-Milner type systems to the rescue! (With a sprinkling of Haskell style type classes.) f :: Iterable a => a -> b f x = (do stuff with x...) f is defined to be constrained to accept only on types which implement the Iterable interface (however that's defined) as it's first argument and the compiler (or interpreter) will enforce that constraint.
- emillon 14y ago
  > Hindley-Milner type systems to the rescue! You're implying that all type-systems derived from HM have a form of bounded polymorphism. They're not, for example OCaml does not have type classes (you could probably encode a lot into objects, though).
  - carterschonwald 14y ago
    False, ocaml has type classes now! (or maybe I'm thinking of coq)
    - pja 14y ago
      I don't think so: If you want the equivalent of Haskell type classes in OCaml then you have to either use a functors or some sort of class IIRC. I'm sure Oleg will have done something though. I believe they're experimental in Coq.
      - carterschonwald 14y ago
        yup, you're right, you got to use functors or go home. Yeup, some folks did show the functors + modules \equiv type classes in some sense, for system F or a variant thereof. Theres also an oleg approach too I think.
  - gtani 14y ago
    TYpe classes and the ML module system overlap in capabilities http://www.cse.unsw.edu.au/~chak/papers/WC06.html http://www.cse.unsw.edu.au/~chak/papers/WC06.html
troels 14y ago
There's a difference between the implementation type and the protocol type. Or as Java calls them - Classes and Interfaces. Unfortunately most classical OO language collate the two, causing much confusion.
Symmetry 14y ago
Haskell's typeclasses are very close to this, but even closer is Go. You just define and interface and the functions that require it, and the compiler goes off and check's by itself whether the type you're passing in satifies the interface - no need for you to annotate it yourself. You lose Haskell's nifty "deriving" feature, but it's even closer to Python's duck typing with compile time checks.
JustinJ70s 14y ago
Scala's type system can handle this as it support type safe duck typing.

sbmassey 14y ago

Haskell type classes are sufficiently flexible to represent things like 'does this type have a next method' without having to instrument the actual type.

pimentel 14y ago
But could that kind of type system be considered similar to the usual Java-like little-flexible static typing? I think I would prefer a static vs dynamic implemented as Java vs Python (since those are usually the subjects on every one of these discussions)
- hythloday 14y ago
  It's identical, conceptually. A type class can be thought of as a degenerate kind of Adapter pattern.
- ufo 14y ago
  ALthough the name is confusing type classes are very much like interfaces in Java: you define a set of operations that you want and then instantiate concrete types to that interface. The major differences between type classes and interfaces are: * In Java interfaces the interfaced type is restricted to the first argument (the this). In Haskell interfaces the interfaced type can also appear on return values and arguments. * In Java you need to decide what interfaces to implement when you create your class. Haskell allows interfaces to be implemented for previously existing types. * Java allows for subtyping. You can turn a monomorphic program into a polymorphic one just by creating subclasses while in Haskell you would need to rewrite your code to be explicitly polymorphic.

dons 14y ago

> the function doesn't care about the type, but just whether it implements a next() method? You're describing an "existential" type.

dllthomas 14y ago
... or a typeclass.

pja 14y ago

Hindley-Milner type systems to the rescue! (With a sprinkling of Haskell style type classes.) f :: Iterable a => a -> b f x = (do stuff with x...) f is defined to be constrained to accept only on types which implement the Iterable interface (however that's defined) as it's first argument and the compiler (or interpreter) will enforce that constraint.

emillon 14y ago
> Hindley-Milner type systems to the rescue! You're implying that all type-systems derived from HM have a form of bounded polymorphism. They're not, for example OCaml does not have type classes (you could probably encode a lot into objects, though).
- carterschonwald 14y ago
  False, ocaml has type classes now! (or maybe I'm thinking of coq)
  - pja 14y ago
    I don't think so: If you want the equivalent of Haskell type classes in OCaml then you have to either use a functors or some sort of class IIRC. I'm sure Oleg will have done something though. I believe they're experimental in Coq.
    - carterschonwald 14y ago
      yup, you're right, you got to use functors or go home. Yeup, some folks did show the functors + modules \equiv type classes in some sense, for system F or a variant thereof. Theres also an oleg approach too I think.
- gtani 14y ago
  TYpe classes and the ML module system overlap in capabilities http://www.cse.unsw.edu.au/~chak/papers/WC06.html http://www.cse.unsw.edu.au/~chak/papers/WC06.html

troels 14y ago

There's a difference between the implementation type and the protocol type. Or as Java calls them - Classes and Interfaces. Unfortunately most classical OO language collate the two, causing much confusion.

Symmetry 14y ago

Haskell's typeclasses are very close to this, but even closer is Go. You just define and interface and the functions that require it, and the compiler goes off and check's by itself whether the type you're passing in satifies the interface - no need for you to annotate it yourself. You lose Haskell's nifty "deriving" feature, but it's even closer to Python's duck typing with compile time checks.

JustinJ70s 14y ago

Scala's type system can handle this as it support type safe duck typing.