1ML – unifying ML into one language • Hacker News Board

Re: 1ML – unifying ML into one language

#61

Post by mordocai » Thu, Apr 23, 2015, 2:41 PM UTC

fab13n wrote: post #59

Retra wrote: post #47

Earlier quoted context omitted.

Every time I think of unifying various language features like this, I end up imagining that I'd just reinvent LISP and look like a fool...

That's often true within dynamically typed languages, but statically typed languages definitely don't feel Lispy. Moreover, messing with static type systems involves much more maths than hacking.

It is perfectly possible to write/use a lisp that is statically typed and still feels like a lisp. AFAIK the closest thing to this currently is shen http://www.shenlanguage.org/.

None of the things that make a lisp a lisp prevent static typing. Some common constructs could be hard to figure out the types for, but they figured out the types of transducers so I doubt it is impossible.

Re: 1ML – unifying ML into one language

#62

Post by andolanra » Thu, Apr 23, 2015, 5:22 PM UTC

platz wrote: post #44

iskander wrote: post #43

Earlier quoted context omitted.

If you combine this with [modular implicits]( http://www.meetup.com/NYC-OCaml/events/222026251/ ), which are hopefully going to be added to OCaml soon, then you'll get something which is nearly as syntactically neat as type classes but more powerful.

More power in terms of flexibility, but the mechanism of implicits makes it less clear which instance is in scope for a given expression. With true typeclasses, there is no ambiguity which instance will be selected (there can only be one) This distinction is often lost when comparing true type classes with their emulation via implicts. Sometimes "more power" is not what you want i.e. this is more of a tradeoff.

The proposed OCaml implementation of modular implicits[1] considers ambiguity a compile-time error, so in that case you'd have to manually indicate which module you're passing in. (This is in contrast to Scala, in which there's an elaborate mechanism for resolving ambiguity in implicits which makes it hard to know which is being selected.)

So the OCaml implementation shouldn't make it any more difficult to discover which implicit is in use in a given context, because if an implicit is used, then it must necessarily be unique and there will be no ambiguity.

[1]: http://www.lpw25.net/ml2014.pdf

Re: 1ML – unifying ML into one language

#63

Post by platz » Thu, Apr 23, 2015, 6:49 PM UTC

andolanra wrote: post #62

platz wrote: post #44

Earlier quoted context omitted.

More power in terms of flexibility, but the mechanism of implicits makes it less clear which instance is in scope for a given expression. With true typeclasses, there is no ambiguity which instance will be selected (there can only be one) This distinction is often lost when comparing true type classes with their emulation via implicts. Sometimes "more power" is not what you want i.e. this is more of a tradeoff.

The proposed OCaml implementation of modular implicits[1] considers ambiguity a compile-time error, so in that case you'd have to manually indicate which module you're passing in. (This is in contrast to Scala, in which there's an elaborate mechanism for resolving ambiguity in implicits which makes it hard to know which is being selected.) So the OCaml implementation shouldn't make it any more difficult to discover w…

the section "6.5 Modular type classes" was very interesting. Although they did mention some restrictions as well.