<bluestorm_>
Myoma: what's wrong about typeclasses in this case ?
Linktim_ has quit [Read error: 110 (Connection timed out)]
Linktim_ has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
* Yoric[DT]
doesn't see where typeclasses are involved.
ikatz has quit [Read error: 110 (Connection timed out)]
<Smerdyakov>
Most languages have their features that most developers agree are silly, inelegant hacks that should be superceded, but type classes aren't one of those, so I think you, Myoma, should provide some justification after ruling them out in three words.
<bluestorm_>
Yoric[DT]: typeclasses are a solution to the equality problem
<Yoric[DT]>
Sure.
<Smerdyakov>
Yoric[DT], type classes for ordered and equality-comparable types.
<Yoric[DT]>
But I don't see where they appear in the entry.
<Yoric[DT]>
Hey, I know about using typeclasses for comparing.
<Smerdyakov>
SML has one fixed type class for equality types.
<bluestorm_>
btw Smerdyakov
<bluestorm_>
hm
<bluestorm_>
i was going to ask you if the SMLer can specify the equality relation himself, but i'm going to go for the doc instead
<Smerdyakov>
bluestorm_, I can answer, if you want, since the SML Definition isn't available for free. :P
<flux>
it's been said that type classes and modules are equal in power, but apparently they are not quite as useful in this case :)
<Smerdyakov>
flux, whoever says that has a bogus notion of "power."
<flux>
smerdyakov, well, I'm obviously referring to the paper that describes a mapping between them
<flux>
the notion of "power" is of course quite arbitrary and subjective :)
rby has quit ["Quitte"]
<Smerdyakov>
flux, it's trivial to write a program to translate between them, but that program is hard for humans to run manually when they code.
<flux>
have type classes for ocaml been investigated?
<flux>
there is gocaml, but that's something else
<bluestorm_>
Smerdyakov: after a little googling it seems the answer is "no"
<Myoma>
typeclasses are far too inexpressive
pango_ has quit [Remote closed the connection]
<Smerdyakov>
Myoma, but they solve the particular problem you mentioned.
<bluestorm_>
so the SML solution, while being nicer than the OCaml runtime-error, is not as flexible as the equality classes (in particular it looks like the "set equality" problem is not resolved)
<flux>
maybe when you fit those in ocaml which already has modules, you get something expressive.. (speculating)
<Myoma>
Smerdyakov: I want to build a lattice of types and have operations promote values into the lowest upper bound of the argument types
<bluestorm_>
use OOP ocaml ?
<bluestorm_>
(however, you'll have to do the promotion by hand)
<Myoma>
but I would like to resolve this at compile time
<bluestorm_>
which part ?
<bluestorm_>
in OCaml, the typing part is resolved at compile time, but not the method lookup iirc
pango_ has joined #ocaml
<Smerdyakov>
Myoma, hardly anyone wants this in practice, you know. It's fine to identify an opportunity for language improvement, but it's just irresponsible to act like type classes are crap because they don't make what you want instant.
<Smerdyakov>
Myoma, BTW, I do think you can do what you're asking using multi-parameter type classes.
Snark has quit ["Ex-Chat"]
<Smerdyakov>
You define a two-parameter type class capturing the subtype relationship, with one member, a cast function.
<Myoma>
You can't take the transitive closure of the subtype relation though
<Smerdyakov>
I thought you could, using functional dependencies.
<bluestorm_>
Myoma: are equality and subtyping really related anyway ?
<Myoma>
but the problem is if you put full (lambda) Prolog, in the type system there are other problems
<Smerdyakov>
Myoma, but GHC essentially has that with the right options turned on, I think.
<Myoma>
so I feel like typeclasses are a dead end, maybe I am wrong (because I don't see anything better around currently)
<Smerdyakov>
Again, most functional programmers don't care about subtyping coercions, in my experience. Do you have any other objection?
<Myoma>
Smerdyakov: I also think with a slightly better relational language in the type system you could do generic programming over sets of types
<Smerdyakov>
Completely general generic programming is well-understood in dependently-typed languages.
* Myoma
is yet to come up with something concrete to prototype though ...
<Myoma>
Smerdyakov: What about general purpose programming?
<Smerdyakov>
I argue against the existence of "general purpose programming" in well-designed engineering environments.
<Myoma>
hmm interesting
pattern has left #ocaml []
<Smerdyakov>
I think there is the world of hardcore infrastructure hacking, which belongs in a dependently-typed language yet to be designed; and all the rest, the vast bulk of software development in fact, which should be in very restrictive, high-level DSLs.
<Smerdyakov>
But Coq today is in pretty darned good shape for general purpose programming, especially with a layer like Ynot on top.
<Smerdyakov>
So I guess what I really mean is "all kinds of programming."
Linktim has joined #ocaml
<Smerdyakov>
Not literally "all," but "all kinds" in the sense of "many and diverse."
<Smerdyakov>
I'm sure most developers aren't ready for Coq, but that's a separate issue.
Associat0r has joined #ocaml
Associ8or has quit [Connection reset by peer]
Linktim_ has quit [Read error: 113 (No route to host)]
Linktim_ has joined #ocaml
Snark has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
Linktim has joined #ocaml
mishok13 has quit [Read error: 145 (Connection timed out)]
Axioplase_ is now known as Axioplase
besiria has quit [Remote closed the connection]
Snark has quit ["Ex-Chat"]
Snark has joined #ocaml
Linktim_ has quit [Read error: 110 (Connection timed out)]
r0bby has joined #ocaml
Snark has quit ["Ex-Chat"]
Weebls has joined #ocaml
Snark has joined #ocaml
Linktim_ has joined #ocaml
Kopophex has joined #ocaml
Linktim has quit [Read error: 110 (Connection timed out)]
<flux>
apparently ocamlcore planet still has harrop's non-articles