Live data from Hacker News

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

looplang.org

1–10 of 41 posts

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

#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/switch construct present in many, many languages. Although, I liked the type-patterns.

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

#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 objects? I'm concerned about the interaction between pattern matching, duck typing and Java's static typechecker. Based on a quick glance, it's hard to see what that interaction is going to be like. At the very least, it does raise the question: what makes the pattern matching on lists and other built-in types special? In Haskell, for example, there's nothing magic about the cons operator and lists; it's just regular pattern matching on algebraic types.

I suspect your magic Nothing type is also necessary to make object pattern matching powerful, and I have some concerns about this kind of null safety. I wonder if programs are going to wind up turning into "gray goo" of Nothing, and what the debug scenario is for that case.

Exception handling looks a bit odd to me. Maybe it all works out in the end, but it looks like you're going to wind up with code like this:

    foo(x) except handler
      where
        handler(e) => 
          IOException : e.stuff
          ...
I think this is going to wind up being a bit gassy for local exception handling, where in Java you would see something like this, that avoids the intermediate name:

    try {
      foo(x);
    }
    catch (IOException e) {
      e.stuff
    }
    ...
Is it going to look better with closures?

    foo(x) except @(e) -> {
      IOException : e.stuff
      ...
    }
It's probably fine, but I dunno, most languages use more syntax in this area.

Overall, this is fairly impressive. It looks a bit like the greatest hits of Ruby and ML. The JVM has been host to a surprising number of interesting languages lately, and this is clearly one of the better recent offerings. Definitely worth a deeper look.

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

#6
Haven't had the chance to download and look through it but an example caught my eye.

Was anyone else confused that this,

# filter list => [ 'ipod', 'ipad', 'iphone' ]

('i' + p) for p in ['mac', 'pod', 'pad', 'phone'] if p.startsWith('p')

applies a filter against the list, rather than limit what gets prefixed with an 'i'?

I'm assuming then there's some code to keep the mapping and the entire list as well. Something like this?

('i' + p) if p.startsWith('p') for p in ['mac', 'pod', 'pad', 'phone']

It just seemed surprising to me that an if statement can cause a change in the list length.

Edit: Ah this seems to be how filtering works in python

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

#7
post #6

Haven't had the chance to download and look through it but an example caught my eye. Was anyone else confused that this, # filter list => [ 'ipod', 'ipad', 'iphone' ] ('i' + p) for p in ['mac', 'pod', 'pad', 'phone'] if p.startsWith('p') applies a filter against the list, rather than limit what gets prefixed with an 'i'? I'm assuming then there's some code to keep the mapping and the entire list as well. Something li…

The list comprehension rules seem to be lifted straight from Python, where the "foo for bar" part always comes first.
Post reply on HN