Live data from Hacker News

The Future of Standard ML (2013) [pdf]

cs.cmu.edu

61–70 of 82 posts

Re: The Future of Standard ML (2013) [pdf]

#61
post #60

Earlier quoted context omitted.

I have ~4 years experience writing OCaml, and ~1 year experience writing Standard ML. I also once did contracting for a Play app in Scala for 3 months. A month ago, I started looking into Haskell for the first time for another side project and was immediately able to pick it up due to how similar it is to OCaml and Standard ML. In particular, the type syntax and function declarations are similar; understanding monads…

If you already know SML or OCaml, you'll pick up Haskell easier, but if you don't know them and want to learn Haskell, you're not taking a shortcut by learning SML or OCaml first.

Its whatever works for every person, but I'll throw in my own experiences and say, that by taking a detour into Ocaml I was actually greatly aided in understanding Haskell. And that having spent a great deal of time with a number of Lisps. I had grabbed a copy of RWH, dug into it, been a little defeated at first, took a studious detour through RWOcaml and have returned to Haskell with a clearer view. Again, to each their own, my own experience was actually the opposite of your statement.

Re: The Future of Standard ML (2013) [pdf]

#62

Earlier quoted context omitted.

Holy cow, poly/ml looks outstanding, threads, sockets, signals, a ffi, a lot of things I've been missing in SML all these years. Is there support for unicode in the string library? How's the generated code performance wise? I will definitely keep an eye on this project.

Poly/ML produces excellent code. It's probably the second most performant SML implementation after MLton.

Does it produce native executables that are easy to distribute?

Re: The Future of Standard ML (2013) [pdf]

#63
post #50
post #49

Earlier quoted context omitted.

I can see the argument for terseness in source, particularly in domains where the terseness in code reflects well-understood shorthand in the actual problem space. But stuff like that makes me itch, to be honest.

The alternative would be something like l.prepend(a).append(b) Horrible. Ghastly. Can't see anybody tolerating a language that looked like that.. /s

Don't know Scala but why wouldn't it be

a.append(l).append(b)

?

Re: The Future of Standard ML (2013) [pdf]

#64
post #15

Earlier quoted context omitted.

No. I mean, I know Tiobe isn't great, but the only ML-derivative I see on the top 50 is F#. ML and OCaml crack the top 100.

F# doesn't even have modules. Not really in the SML spirit—it's like if you combined Classic/LCF ML from the 1970s with C#.

In the context of ML, what are modules and why are they useful?

Re: The Future of Standard ML (2013) [pdf]

#65
post #8
post #5

Earlier quoted context omitted.

Same as compsci students at TU Munich, if Prof. Rybalchenko does the intro to functional programming course. I really enjoyed it and found it much better suited for students than other languages, especially with the book by Gert Smolka.

Do you have a link to "that book?"

https://www.amazon.de/Programmierung-eine-Einführung-Informa...

Re: The Future of Standard ML (2013) [pdf]

#66
post #23
post #22

Earlier quoted context omitted.

The only objection to OCaml is "the crufty syntax," which I think F# has taken steps to improve upon.

But F# didn't bring along the beautiful module system from the MLs, nor does it have type classes. Polymorphism there is basically just the OO + generics variety found in C#. That can rub some people (like me) the wrong way.

F# does have type classes, they're just called interfaces.

https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...

Re: The Future of Standard ML (2013) [pdf]

#67
post #23

Earlier quoted context omitted.

But F# didn't bring along the beautiful module system from the MLs, nor does it have type classes. Polymorphism there is basically just the OO + generics variety found in C#. That can rub some people (like me) the wrong way.

F# does have type classes, they're just called interfaces. https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...

Type classes are quite different from interfaces. How would you encode the Eq typeclass in F#? .Net has the IEqualityComparer interface but you need to manually pass that around (unlike Eq instances) and you also lose the global uniqueness property.

Re: The Future of Standard ML (2013) [pdf]

#68
post #63
post #50

Earlier quoted context omitted.

The alternative would be something like l.prepend(a).append(b) Horrible. Ghastly. Can't see anybody tolerating a language that looked like that.. /s

Don't know Scala but why wouldn't it be a.append(l).append(b) ?

That would only work if a was itself a list..

Re: The Future of Standard ML (2013) [pdf]

#69

Earlier quoted context omitted.

F# does have type classes, they're just called interfaces. https://msdn.microsoft.com/en-us/visualfsharpdocs/conceptual...

Type classes are quite different from interfaces. How would you encode the Eq typeclass in F#? .Net has the IEqualityComparer interface but you need to manually pass that around (unlike Eq instances) and you also lose the global uniqueness property.

You don't have to rely on the built in interfaces provided by .NET, you can create your own. Just like in Haskell in F# you can use pattern matching against types to define which of the equality operators to use.

Also, I'm not sure what you mean by "manually pass that around". When you define a class in Haskell that inherits from a typeclass you reference that typeclass in the header of the new class. You follow the same approach in F# with interfaces.

Re: The Future of Standard ML (2013) [pdf]

#70

Earlier quoted context omitted.

Poly/ML produces excellent code. It's probably the second most performant SML implementation after MLton.

Does it produce native executables that are easy to distribute?

On platforms for which it can produce native code, yes. The compiler will produce typical object files which can then be linked with the usual linker. For other platforms it uses a byte compiler.
Post reply on HN