[erlang-questions] Erlang again!

Jesper Louis Andersen jesper.louis.andersen@REDACTED
Fri Jul 23 13:35:04 CEST 2010


On Thu, Jul 22, 2010 at 7:08 PM, Masklinn <masklinn@REDACTED> wrote:

> On the other hand, the Erlang toolbox isn't very discoverable/searchable so you have to read it all (several time if needed).

It is interesting you put forth that argument. I generally find the
Erlang documentation is on par with Haskells ditto. In certain areas
Erlangs documentation is far better: we have users guides strewn all
over the official site:

http://erlang.org/doc/

There are no users guide for the various Haskell libraries and the URL
is worse to boot:

http://haskell.org/ghc/docs/6.12.1/html/libraries/base-4.2.0.0/

Furthermore, the URL contain the version string in several places, so
it becomes obsolete every 3 months or so. It also wreaks havoc on
Googles search index to have all versions freely available: Older
pages tend to win up to a certain point unless you mitigate them with
a <link rel canonical> construction in the HTML.

Erlangs weakness, which you identified, is that you need to know which
module to search for in the standard documentation. But as soon as you
know the specific module, it becomes easy. I tend to use the command
line and write either of:

  erl -man MODULE
  man 3erl MODULE

because I am an old unix-geek and like to have man-pages for my
documentation. As a reference, man-pages are unbeatable. Yet, as you
indicate, as a discovery-tool, they are not that good. To nail the
coffin, We have an excellent web UI tool by Dale Harvey:

http://erldocs.com/

> That's a big advantage of haskell and its strong typing: hoogle[0] lets you search functions by type. In this case you can search for [a] -> [b] -> [c] (a function taking a list of 'a's, a list of 'b's and returning a list of 'c's) and the first result is zipWith[1].

(Detail aside: The typing terminology is not set in stone. When you
write "strong typing" I am going to assume you mean that a program can
be determined well-typed at compile time by a static semantics on the
abstract syntax tree of the program. Other people, myself included,
call this property "static typing" and we reserve the "strong typing"
to mean: There are no unchecked run-time type errors. So the program
will never segfault. end-of-aside)

Right now, you are right. There is no hoogle tool for Erlang.
Theoretically, I think you are wrong and here is why: Kostis Sagonas
has recently added -spec() contracts to the Erlang system which allows
you to gain some of the advantages of static typing while still
retaining the dynamic properties of Erlang. In principle, it should be
possible to write a hoogle-like system for Erlang on top of these
-spec() contracts and gain exactly the same kind of documentation
lookup.

Also, simply having the type specification for a given function is not
always enough. Let me draw up a simple example: Haskells iteratee
library by John W. Lato.

http://hackage.haskell.org/packages/archive/iteratee/0.3.5/doc/html/Data-Iteratee-Base.html

There is a Monad Reader article on how to use the library, and it is
definitely needed. It is not going to be easy to dissect the type
specification of the iteratee library without knowing anything about a
general "users guide" overview of what they do. The problem is not
limited to Haskell, but is present in other statically typed systems
as well. You can probably find good examples in the Coq system - it
would be the first place to look for my as it has all the cool
ingredients in its type system. Included a "full employment theorem
for type specialsts due to total incomprehension of a type" :-)




-- 
J.


More information about the erlang-questions mailing list