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

41–50 of 82 posts

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

#41

Post by jfb »

cwyers wrote: post #11
virtualwhys wrote: post #6

Earlier quoted context omitted.

Coming from Scala I'd like to see successor ML become a reality. Whether it's 1ML, Ponyo, Ur (without the /Web), or another ML derivative that's not OCaml (petty, but the crufty syntax makes Scala seem elegant in this regard) isn't all that important. As it stands every year Rossberg publishes a paper on latest 1ML enhancements; Harper does the same wrt to PLT, and by proxy SML. Meanwhile, nothing's really happening…

I find it interesting that you list all of the ML derivatives except the popular one.

Don't be silly; nobody uses Windows.

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

#43

Post by pklausler »

auggierose wrote: post #40
pklausler wrote: post #29

I revere ML and loved using it back in the day, but I code now in Haskell and am even happier. I like never having to figure out what parts of a program or library are referentially transparent. Why would I ever want to use an impure language again?

Maybe because you need to write some performant code?

I write fast code instead.

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

#44

Post by pekk »

pmontra wrote: post #28
rvense wrote: post #19

Earlier quoted context omitted.

I wrote some Scala just today: val list = a +: l :+ b And I knew I had to put in a comment because that stuff always makes my eyes cross over when I come back to it.

I don't know Scala and I have no idea of what +: :+ means, which at first is not a good sign (think about onboarding.) Then I remembered that many mainstream languages have the a ? b : c construct which maybe was equally puzzling when it was introduced by CPL in 1963.

The fact that C-style ternary is hard to pick up doesn't really excuse this kind of thing in new languages.

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

#45

Post by talideon »

rvense wrote: post #19
jxy wrote: post #16

Earlier quoted context omitted.

> operators (not named functions) are to programming > languages as icon-only buttons are to web pages; > they are completely unusable. I see ( ) ; . you are using already. Latin letters are gibberish to people who don't use it.

I wrote some Scala just today: val list = a +: l :+ b And I knew I had to put in a comment because that stuff always makes my eyes cross over when I come back to it.

Don't know Scala, but I'd assume that `+:` is prepend to list and `:+` is append to list.

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

#47

Post by rvense »

pmontra wrote: post #28
rvense wrote: post #19

Earlier quoted context omitted.

I wrote some Scala just today: val list = a +: l :+ b And I knew I had to put in a comment because that stuff always makes my eyes cross over when I come back to it.

I don't know Scala and I have no idea of what +: :+ means, which at first is not a good sign (think about onboarding.) Then I remembered that many mainstream languages have the a ? b : c construct which maybe was equally puzzling when it was introduced by CPL in 1963.

They're operators that cons an element on to a list. They're both defined on the List class, but differ in associativity because they start/end in a colon.

"a +: l" calls the +: method on l with a as its argument and returns a list with a added to the start, "l :+ b" calls the :+ method on l with b as its argument and returns a list with b added to the end. "a +: l :+ b" (parsed as "(a +: l) :+ b") therefore returns a copy of l with a added to the start and b added to the end.

This is user definable, you can make operators whichever way you like (and start them with : if you want them to be right associative).

It's very flexible and you do sort of get used to libraries using it, but I'm not entirely sure that getting used to something always means it's good.

(TBH though, I use the ternary operator constantly and think nothing of it.)

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

#48

Post by rvense »

talideon wrote: post #45
rvense wrote: post #19

Earlier quoted context omitted.

I wrote some Scala just today: val list = a +: l :+ b And I knew I had to put in a comment because that stuff always makes my eyes cross over when I come back to it.

Don't know Scala, but I'd assume that `+:` is prepend to list and `:+` is append to list.

You'd be correct.

But they're just method calls, both defined on the class of l. It is a little weird.

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

#49

Post by jfb »

rvense wrote: post #48
talideon wrote: post #45

Earlier quoted context omitted.

Don't know Scala, but I'd assume that `+:` is prepend to list and `:+` is append to list.

You'd be correct. But they're just method calls, both defined on the class of l. It is a little weird.

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.

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

#50

Post by rvense »

jfb wrote: post #49
rvense wrote: post #48

Earlier quoted context omitted.

You'd be correct. But they're just method calls, both defined on the class of l. It is a little weird.

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
Post reply on HN