Exotic Programming Ideas: Module Systems

Post by ufo » Sat, Nov 14, 2020, 12:52 AM UTC

tel wrote: post #49

horsawlarway wrote: post #24

Coming in without much OCaml experience, I don't really think this is a great demonstration of why this construct has value. I don't really want to read a long form description of the OCaml implementation of modules. I want a comparison to the languages he dismissed at the beginning of the article, and a discussion of why this feature has some value that isn't provided by those languages. Basically - This feels like…

It's absolutely a different approach to generics. Or, rather, that's the ringer. I want to say first: OCaml's take on modules is just a really nice way of doing namespacing as well. Secondly, generics depend upon (a) having a means to discuss functionality which abstracts over one or more types and certain behaviors those types must support, (b) having a means to bundle up one or more types along with some behaviors,…

Post by girvo » Sat, Nov 14, 2020, 3:29 AM UTC

zcesur wrote: post #44

karmakaze wrote: post #39

Earlier quoted context omitted.

Not possible, but an approximation: interface Mappable , T> { flatMap (f: (x: T) => Mappable ): Mappable ; } class Maybe implements Mappable , T> { x: T | undefined; public flatMap (f: (x: T) => Maybe ): Maybe { if (this.x) { return f(this.x); } return Maybe.nothing(); } }

Yes, in fact this reminds me of the HKT implementation[1] found in fp-ts[2][3] interface HKT { _URI: F _A: A } interface Mappable { map (f: (a: A) => B, fa: HKT ): HKT } where F is a unique identifier representing the type constructor and A its type parameter. [1]: https://www.cl.cam.ac.uk/~jdy22/papers/lightweight-higher-ki... [2]: https://github.com/gcanti/fp-ts [3]: https://gist.github.com/gcanti/2b455c5008c2e1674…

Post by tel » Tue, Nov 17, 2020, 2:43 AM UTC

patrec wrote: post #54

tel wrote: post #49

Earlier quoted context omitted.

It's absolutely a different approach to generics. Or, rather, that's the ringer. I want to say first: OCaml's take on modules is just a really nice way of doing namespacing as well. Secondly, generics depend upon (a) having a means to discuss functionality which abstracts over one or more types and certain behaviors those types must support, (b) having a means to bundle up one or more types along with some behaviors,…

All the languages you mention have parameterized types, so I don't see why anyone would be tempted to use subtyping rather than generics. The only reason I could see is wanting to parameterize at runtime, but it's not immediately obvious to me that graphs with runtime parameterized edge and nodes are something you'd want on a regular basis. Am I missing some subtlety?

Post by ratmice » Wed, Nov 25, 2020, 11:30 AM UTC

elbear wrote: post #56

ratmice wrote: post #46

Earlier quoted context omitted.

Seems like it, but typeclasses are inherently anti-modular, they provide a globally coherent unique instance. consider the Ord typeclass giving a single ordering for a specific type. To reverse the order you need to create a new type with a new instance of ord which reverses it. Where in a module system its perfectly fine to have multiple instances of Ord for a given type. One gives global consistency where the other…

When you put it like that, modules sound more powerful than typeclasses. Is there any situation where typeclasses are superior to modules?