Live data from Hacker News

Learn from Haskell - Functional, Reusable JavaScript

seanhess.github.com

31–40 of 50 posts

Re: Learn from Haskell - Functional, Reusable JavaScript

#31
post #6
post #4

One bit of trouble I have with functional style programming is something like the following example: if I have an array of people with firstName and lastName properties, how would I go about returning the person with the longest full name without adding any properties directly to the objects? It is a simple map then reduce to return the maximum length, a fairly trivial modification thereof to return the full name, bu…

The map is unnecessary. Just reduce: (* assuming: val total_len : string -> int *) List.reduce seq ~f:(fun a b -> if (total_len a) > (total_len b) then a else b) It's not necessary in this case, but fold is often a lot more useful than reduce . At least the way I think of it, the type of reduce is 'a list -> ('a -> 'a -> 'a) -> 'a , whereas the type of fold is 'a list -> init:'b -> ('b -> 'a -> 'b) -> 'b . The upside…

    Yes, this does require you to compute string length multiple times...but keep in mind that getting string length is very cheap in languages with good strings. (That is, basically everything except C's null-terminated strings.)
Since this is a discussion about Haskell, too, I feel obliged to say that computing the length of a String type in Haskell is an O(n) operation, because String is really just

    type String = [Char]
i.e. a linked list of Char values.

Typically, if you want performance out of strings in Haskell, you'll use the Text or ByteString types BUT the length operation of Data.Text is still O(n). Only ByteString offers

    length :: ByteString -> Int
Which is O(1).

Re: Learn from Haskell - Functional, Reusable JavaScript

#33
The currying function shown can be made more flexible:

   var _slice = Array.prototype.slice;

   var curry = function() {
     var args = _slice.call(arguments);
     return function() {
       var args2 = _slice.call(arguments);
       return args[0].apply(this, args.slice(1).concat(args2));
     };
   };
As can the composition func:

   var compose = function(f, g) {
     return function() {
       var args =_slice.call(arguments);
       return f(g.apply(this, args));
     };
   };

Re: Learn from Haskell - Functional, Reusable JavaScript

#34
post #14

Earlier quoted context omitted.

'In Haskell, everything is a function' is absolutely wrong. People who don't know much about Haskell often say this. There's a post by Conal Elliott about this incorrect meme: http://conal.net/blog/posts/everything-is-a-function-in-hask... It's simply not true. In fact, because Haskell is statically typed, it's very easy to tell what's a function and what's not: If its type doesn't have an -> in it, it's not a functi…

... I know that 3 is not literally function in the Haskell type system but it's an easy way to explain it to people less familiar with the language (not that I assume freyrs3 is one of those). Also, while it might be true that "people who don't know much about Haskell" often say that everything is a function, it's also the case that people who do know a lot about the language find the notion to be pedagogically usefu…

Also, the definition of an infinite list of ones

    ones = 1 : ones
is a non-function value, but is recursively applied to itself. Might help illustrate why this is a useful notion in Haskell.

Re: Learn from Haskell - Functional, Reusable JavaScript

#35

I'm been experimenting with UHC's js backend. One of the things that struck me was that in Haskell if I have a function like: forever :: Monad m => m a -> m a I can use it for either asynchronous or synchronous javascript, e.g forever :: IO a -> IO a forever :: ContT r IO a -> ContT r IO a The same function can take a synchronous js function or an async js function and run it in an infinite loop. For this reason, I t…

Small nitpick, the type of forever is actually:

  forever :: Monad m => m a -> m b
Since it never returns a value, the resulting monadic action can be polymorphic in its return type.

Re: Learn from Haskell - Functional, Reusable JavaScript

#36

What bothers me in this with pure JS is the verbosity of "function (arg1,arg2) {return ...;}"

coffescript's sugar is pretty nice (haskell inspired)? function (a,b) {return a+b} becomes (a,b) -> a+b Hopefully in harmony we will see a shorter function syntax for environments where CS isn't an option

Re: Learn from Haskell - Functional, Reusable JavaScript

#37
post #36

What bothers me in this with pure JS is the verbosity of "function (arg1,arg2) {return ...;}"

coffescript's sugar is pretty nice (haskell inspired)? function (a,b) {return a+b} becomes (a,b) -> a+b Hopefully in harmony we will see a shorter function syntax for environments where CS isn't an option

Not having to write `function` everywhere is pretty much the reason I started using CoffeeScript.

Re: Learn from Haskell - Functional, Reusable JavaScript

#39
post #37
post #36

Earlier quoted context omitted.

coffescript's sugar is pretty nice (haskell inspired)? function (a,b) {return a+b} becomes (a,b) -> a+b Hopefully in harmony we will see a shorter function syntax for environments where CS isn't an option

Not having to write `function` everywhere is pretty much the reason I started using CoffeeScript.

Why not just save snippets? I do this in emacs (yasnippet) all the time instead of constantly rewriting the same stub.

Not knocking coffescript here, just saying that "I don't want to write a specific word" is a pretty terrible reason to pick any language over another.

Post reply on HN