Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Future of Standard ML (2013) [pdf]

cs.cmu.edu

Post reply on HN
Print view View original

71–80 of 82 posts

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

#71

Post by lkitching »

ZenoArrow wrote: post #69
lkitching wrote: post #67

Earlier quoted context omitted.

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…

By 'pass around', I mean pass around instances, not definitions. You could define your own Eq interface in F#

  type IEq =
    abstract member eq: 'a -> 'a -> bool
but you then need to explicitly pass instances of this interface around into every method that requires it e.g.

  let allEq (s: 'a seq) (eq: IEq) = ...
whereas the haskell version would receive the Eq instance for the input type implicitly.

Typeclass instances are globally unique for each type, which cannot be enforced with the interface solution. If you have an ordered map type, you can be sure the Ord instance used for insertion is the same that is used for retrieval. With the interface approach, clients cannot know which instance to use since there could be multiple implementations. The Haskell approach has its own problems, such as the proliferation of newtype wrappers to manage the dispatch mechanism.

Interfaces also hide the representation of one of their arguments (the receiver) whereas typeclasses are just a dictionary of functions.

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

#72

Post by eatonphil »

qbrass wrote: post #58
agentgt wrote: post #34

Earlier quoted context omitted.

I'm sort of sick of hearing that OCaml has crappy or crufty syntax. I like OCaml's syntax. There is just a sea of useless algol brackets in so many languages. I was sort of sad that Rust fell victim to the damn bracket. At times I don't even think Scala is that much more succinct than modern Java 8 (ala bracket indentation fun). I remember years ago (15 years.. jesus I'm old) discovering OCaml and I couldn't believe…

Was OCaml was your first ML language? It seems that most of the people who find OCaml crufty used Standard ML before OCaml.

For what it's worth, I think OCaml's syntax is one of its weakest points (not to mention syntax extensions...) and I have been writing OCaml 3 years longer than I've been writing Standard ML.

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

#73

Post by eatonphil »

qbrass wrote: post #60
eatonphil wrote: post #30

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.

Although I happened to learn OCaml first, I am actually arguing that learning SML is a better way to learn the concepts behind tremendously more complex and less user-friendly languages like OCaml and Haskell. I don't know if I'd say it's a shortcut, but it's pretty natural to learn by studying a simpler (perhaps historic) topic before studying a more modern and complex one.

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

#74

Post by auggierose »

pklausler wrote: post #53
pekk wrote: post #46

Earlier quoted context omitted.

What do you think the difference is between "performant" and "fast"?

"fast" is in my dictionary.

Thanks for pointing out that "performant" is not in any english dictionary! (http://weblogs.asp.net/jongalloway/performant-isn-t-a-word) Didn't know that.

Besides that, your "fast" code will not be as fast as it can be if you are only relying on purely functional code, at least on current architectures.

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

#75

Post by bboreham »

marktangotango wrote: post #39
bboreham wrote: post #35

Earlier quoted context omitted.

I always took it to be Milner Language. Prof Milner was my first CS lecturer, many years ago. Ironically the language for that course was Pascal.

That is amazing, how was he as a lecturer?

Well, that first course was very basic and open to all students, and I didn't know who he was. Just seemed like a typical lecturer way down the front of a big hall.

A couple of years later, he taught my class of ~20 his Calculus of Communicating Systems; I think it was the first time he tried it out on undergraduates. He was incredibly kind and patient; really interested to find out which parts of the explanation didn't work, and how he could get it across better.

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

#76

Post by agentgt »

eatonphil wrote: post #72
qbrass wrote: post #58

Earlier quoted context omitted.

Was OCaml was your first ML language? It seems that most of the people who find OCaml crufty used Standard ML before OCaml.

For what it's worth, I think OCaml's syntax is one of its weakest points (not to mention syntax extensions...) and I have been writing OCaml 3 years longer than I've been writing Standard ML.

Well yes I agree if you compare OCaml to Standard ML its syntax is not as good and I do prefer Standard ML over it. However I prefer OCaml over Java, Javascript, Scala (and the bazillion other brace block languages that are the same), and yes even Haskell.

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

#77

Post by agentgt »

qbrass wrote: post #58
agentgt wrote: post #34

Earlier quoted context omitted.

I'm sort of sick of hearing that OCaml has crappy or crufty syntax. I like OCaml's syntax. There is just a sea of useless algol brackets in so many languages. I was sort of sad that Rust fell victim to the damn bracket. At times I don't even think Scala is that much more succinct than modern Java 8 (ala bracket indentation fun). I remember years ago (15 years.. jesus I'm old) discovering OCaml and I couldn't believe…

Was OCaml was your first ML language? It seems that most of the people who find OCaml crufty used Standard ML before OCaml.

Guilty as charged.. I did learn OCaml first and from that official green HTML documentation which still appears to be green after 16 years :).

My complaint with OCaml was OCamlp and the tedium of creating modules and functors. While AdHoc poly (aka type classes) is not as flexible it is IMO easier to understand, generally less verbose and slightly more elegant than OCaml modules. I'm glad they added first class modules as I recall wanting something like that a long time ago.

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

#78

Post by ZenoArrow »

lkitching wrote: post #71
ZenoArrow wrote: post #69

Earlier quoted context omitted.

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…

By 'pass around', I mean pass around instances, not definitions. You could define your own Eq interface in F# type IEq = abstract member eq: 'a -> 'a -> bool but you then need to explicitly pass instances of this interface around into every method that requires it e.g. let allEq (s: 'a seq) (eq: IEq ) = ... whereas the haskell version would receive the Eq instance for the input type implicitly. Typeclass instances ar…

I'm not sure I understand all of what you've said, as I'm not familiar with Haskell, but there are at least some Haskell programmers have recognised the similarities between type classes and interfaces. Do you disagree with any of the following?

https://wiki.haskell.org/OOP_vs_type_classes#Type_classes_ar...

"Type classes are like interfaces/abstract classes, not classes itself

There is no inheritance and data fields (so type classes are more like interfaces than classes)....

For those more familiar with Java/C# rather than C++, type classes resemble interfaces more than the classes. In fact, the generics in those languages capture the notion of parametric polymorphism (but Haskell is a language that takes parametric polymorphism quite seriously, so you can expect a fair amount of type gymnastics when dealing with Haskell), so more precisely, type classes are like generic interfaces.

Why interface, and not class? Mostly because type classes do not implement the methods themselves, they just guarantee that the actual types that instantiate the type class will implement specific methods. So the types are like classes in Java/C#.

One added twist: type classes can decide to provide default implementation of some methods (using other methods). You would say, then they are sort of like abstract classes. Right. But at the same time, you cannot extend (inherit) multiple abstract classes, can you?

So a type class is sort of like a contract: "any type that instantiates this type class will have the following functions defined on them..." but with the added advantage that you have type parameters built-in, so:

  class Eq a where
    (==) :: a -> a -> Bool
    (/=) :: a -> a -> Bool
    -- let's just implement one function in terms of the other
    x /= y = not (x == y)
is, in a Java-like language:

  interface Eq {

    boolean equal(A that);
    boolean notEqual(A that) { 
       // default, can be overriden
       return !equal(that); 
    } 
  }
And the "instance TypeClass ParticularInstance where ..." definition means "ParticularInstance implements TypeClass { ... }", now, multiple parameter type classes, of course, cannot be interpreted this way."

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

#79

Post by bsummer4 »

auggierose wrote: post #74
pklausler wrote: post #53

Earlier quoted context omitted.

"fast" is in my dictionary.

Thanks for pointing out that "performant" is not in any english dictionary! ( http://weblogs.asp.net/jongalloway/performant-isn-t-a-word ) Didn't know that. Besides that, your "fast" code will not be as fast as it can be if you are only relying on purely functional code, at least on current architectures.

Do be fair, he said "impure language" and not "impure code".

"Looks like we need to let the scholars know - there are 18,300 uses of the non-word "performant" in scholarly papers" <- If that's not sarcasm, something is wrong. Performant is a word!

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

#80

Post by auggierose »

bsummer4 wrote: post #79
auggierose wrote: post #74

Earlier quoted context omitted.

Thanks for pointing out that "performant" is not in any english dictionary! ( http://weblogs.asp.net/jongalloway/performant-isn-t-a-word ) Didn't know that. Besides that, your "fast" code will not be as fast as it can be if you are only relying on purely functional code, at least on current architectures.

Do be fair, he said "impure language" and not "impure code". "Looks like we need to let the scholars know - there are 18,300 uses of the non-word "performant" in scholarly papers" <- If that's not sarcasm, something is wrong. Performant is a word!

It is a word, just not an English one it seems! It certainly is a German word. That might explain a lot ;-) It might also explain the many occurrences, as there are many Germans writing papers in English.
Post reply on HN