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

Loop: a programming language for the JVM inspired by Haskell and Ruby

looplang.org

Post reply on HN
Print view View original

21–30 of 41 posts

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#21

Post by Tyr42 »

Peaker wrote: post #11
ac wrote: post #4

I think it's quite misleading to list Haskell in the title: the only common thing between Loop and Haskell that I've found is pattern matching, and that's not even exclusive to Haskell -- other languages have it. Besides, it's not clear from the intro that Loop's pattern matching is as powerful as Haskell's (especially with all the extensions). Finally, pattern matching is really a syntactic sugar over the case/switc…

Pattern-matching is not sugar over "case". Pattern-matching means that the branching primitive not only dispatches to different code based on an input tag, but also that it places different values of different types in scope according to the branch. Most languages only branch on booleans, without gaining any type information at all. This is actually a big problem and relates to the nullability problem, explained at:…

Well, he could be talking about

    reverse [] = []
    reverse (x:xs) = reverse xs ++ [x]
being sugar for

    reverse list = case list of
               []     -> []
               (x:xs) -> reverse xs ++ [x]
Since in that case, pattern matching on arguments is really just sugar for a case statement.

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#22

Post by ac »

Peaker wrote: post #11
ac wrote: post #4

I think it's quite misleading to list Haskell in the title: the only common thing between Loop and Haskell that I've found is pattern matching, and that's not even exclusive to Haskell -- other languages have it. Besides, it's not clear from the intro that Loop's pattern matching is as powerful as Haskell's (especially with all the extensions). Finally, pattern matching is really a syntactic sugar over the case/switc…

Pattern-matching is not sugar over "case". Pattern-matching means that the branching primitive not only dispatches to different code based on an input tag, but also that it places different values of different types in scope according to the branch. Most languages only branch on booleans, without gaining any type information at all. This is actually a big problem and relates to the nullability problem, explained at:…

As Tyr42 has so astutely observed, I have meant that pattern matches in function declarations, let-bindings and list comprehensions are desugared into the case expression. Also, it would be kind of pointless to compare C switch and Haskell case. Especially, in your example Haskell, probably, 'wins' because primarilt because a more powerful type system and algebraic data-types (and absence of pointers, hehe). That said, it's not like you can't emulate the pattern matching (with placing nested values/subtrees in scope): https://gist.github.com/2832755 (it's in JavaScript, because I felt like it -- but I'm pretty sure you can devise something similar in C). Of course, it's plain ugly and doesn't carry any nice static guarantees that the Haskell type-system will give you (like warning about incomplete patterns)... but, hey, it works. Anyway, the point of my comment was that pattern-matching is hardly a feature characterizing and exclusive to Haskell (ML/OCaml/F#, Coq, Scheme have it, probably other functional languages too). Although, it's still the one I enjoy every day :)

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#23

Post by Dn_Ab »

fusiongyro wrote: post #5

Syntax looks very clean, but probably more like CoffeeScript mixed with Ruby. "Inspired by Haskell" is going a bit far. You took pattern matching and `where` and none of the semantics. Object patterns are absolutely awesome. Every OOP/FP hybrid ought to have that. Especially if you're not going to support algebraic data types. That point is worth bringing up, though: are they missing because of the presents of object…

All the major OOP/FP I know support matching on objects. It is indeed a very powerful feature. See active patterns and extractors.

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#24

Post by Tyr42 »

ac wrote: post #18
chrisbroadfoot wrote: post #12

Being functional in nature, Loop doesn't have any of the baggage of the host platform (Java) I don't see much that's functional in this language, but this statement made me laugh. It looks like a lot of Java's baggage is still alive and well in this language, like exceptions (quite un-Haskell-like)

> like exceptions (quite un-Haskell-like) Haskell has exceptions [1]. [1] http://www.haskell.org/haskellwiki/Exception

It has them, but I don't see them being used very often. More commonly just a Maybe will do. And really, monadic exceptions aren't like java exceptions. I would call them un-Haskell-like.

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#25

Post by michaels0620 »

virmundi wrote: post #19

Perhaps this isn't the place for the question, but I'll ask anyway. Is there any JVM-based language that excludes any code from being compiled that is not directly implemented in that language? For example, any code that would deny the use of java.io or java.lang? The reason I ask is because Clojure and Scala both suffer from the ability to call legacy code. While some think this is a good idea, it makes the whole sc…

I haven't heard of one that does this. In fact an oft stated selling point of JVM based languages is the ability to call and interact with existing Java code and libraries.

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#26

Post by poofyleek »

eta_carinae wrote: post #13

The name is unfortunate, especially when the documentation sometimes omits to capitalize "Loop", which introduces even more confusion than there already is.

The name is unfortunate indeed. There were languages like LOOPS (Lisp Object Oriented Programming System) which evolved into CLOS. Common Lisp loop macro is a kind of special DSL of its own. While the oldest LOOP language may be from 1967 article by Meyer and Ritchie (DMR as in UNIX), a kind of mini language for computation of primitive recursive functions and dealing with computational complexity.

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#28

Post by perfunctory »

dardie wrote: post #16

Another cool language from the past, 'nice', had a similar issue that sentenced it to obscurity. A totally ungooglable name :-(

Do you really believe that was the reason? Is C very googlable? Or how about python or ruby?

Re: Loop: a programming language for the JVM inspired by Haskell and Ruby

#30

Post by Peaker »

ac wrote: post #22
Peaker wrote: post #11

Earlier quoted context omitted.

Pattern-matching is not sugar over "case". Pattern-matching means that the branching primitive not only dispatches to different code based on an input tag, but also that it places different values of different types in scope according to the branch. Most languages only branch on booleans, without gaining any type information at all. This is actually a big problem and relates to the nullability problem, explained at:…

As Tyr42 has so astutely observed, I have meant that pattern matches in function declarations, let-bindings and list comprehensions are desugared into the case expression. Also, it would be kind of pointless to compare C switch and Haskell case. Especially, in your example Haskell, probably, 'wins' because primarilt because a more powerful type system and algebraic data-types (and absence of pointers, hehe). That sai…

In a dynamically typed language, whether you do pattern matching or boolean-blind branching doesn't matter that much. You'll catch any error at runtime anyway.

In the presence of static typing, "emulating" pattern matching defeats the purpose, because the purpose of pattern matching is removing boolean blindness. With the "emulated" code you still get runtime-failing boolean-blind code.

By the way, pattern-matching is indeed very much related to sum types (part of "Algebraic data types"), which C lacks. To have pattern matching in a statically typed language, you would need to have sum types as well.

Post reply on HN