Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

This language was inspired by Haskell, however it is unfortunately more verbose. Consider:

    fun mp [a] [b] (f : a -> b) : list a -> list b =
        let
            fun loop (ls : list a) =
                case ls of
                    [] => []
                  | x :: ls' => f x :: loop ls'
        in
            loop
        end
Which in Haskell would be:

    map :: (a->b) -> [a] -> [b]
    map _ [] = []
    map f x:xs = (f x):(map f xs)
Or this notation for lists:

    2 :: 3 :: 4 :: []
Cf Haskell:

    [2,3,4]


It looks more like ML than haskell. But the explicit return of a function and explicit case aren't necessary in ML either, so I'm not sure why they are used here. A quick scan of the reference manual finds mention of currying, but I don't see anything about pattern matching without case statements, so maybe the language doesn't have that.


The map example with toplevel pattern matching is really just sugar for the expanded case statements which isn't that far from the Ur equivalent.

  map :: forall a b. (a -> b) -> [a] -> [b]
  map =
    \ (@ a) (@ b) (ds :: a -> b) (ds1 :: [a]) ->
      case ds1 of _ {
        [] -> [];
        : x xs ->
          (ds,x,xs) : ((ds,x) ds x) ((ds,xs) map ds xs)
      }


> The map example with toplevel pattern matching is really just sugar for the expanded case statements which isn't that far from the Ur equivalent

And both the Ur and the Haskell are really just sugar for a load of machine code. The reason I prefer the more compact Haskell version is that it allows me to express what I mean more precisely; other things being equal, a more compact notation will be higher-level and thus closer to how humans think.


Note that the Haskell list notation is just syntactic sugar. [2,3,4] gets translated directly into

    2:3:4:[]


Sure, it's syntactic sugar, but there's no "just" about it -- being able to express ideas more concisely helps readability.


I think List plays a much more integral role in Haskell than it would in a strict language like this. In Haskell, list is irreplaceable because it can correspond to a value and a thunk for the rest of a result stream, so it's a very special data structure because of the relationship to the language's laziness.

In a strict language though, the list is just a list - nothing special, and users may want to replace it with library variants with different performance tradeoffs (this even happens in Haskell of course for some problem areas). Since this is the case, a uniform treatment may be preferred, where the type name is just like any other type name, construction is just as any other type's construction, and the type is in fact just supplied by a library not the compiler. I don't know if this was the developers' thinking (I'm not involved), but uniformity has its advantages.

Also, I don't think it's really clear that [] is easier to read, especially when it's surrounded by other syntax like parens and braces - it doesn't stand out much, which can be good or bad depending on personal preferrences and the surroundings. Rust recently moved from [] -> Vec for vectors and I think it's easier to read that way, personally.


It's because the more advanced features that it has over Haskell in type-level computation make its type inference undecidable. http://impredicative.com/ur/tutorial/tlc.html




Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: