erlang improvement - objective c (or smalltalk) syntax

Joe Armstrong erlang@REDACTED
Thu Jun 4 11:10:55 CEST 2009


I've been writing some objective-C and like the method calling syntax.
Objective-C (and smalltalk) code is very readable without lot's of comments

Could we do something similar in Erlang?
This was (I think)  discussed a long time ago but can't find the discussion.

Imagine a function like string:substring/3. A call to this looks like:

        string:substring(Str, I, J)

The problem with this is that it's difficult to remember the argument order
and you have to consult the documentation *to find out the order of
the arguments*
I *know* what the arguments are (a string, a start index and a length)
but I have to
consult the documentation to find the order.

Solution: write the call like this.

       string:substring( string:S start:I length:J)

This could be expanded into a canonical form:

       string:substring_start_string_length(S, I, J)

where the tags are sorted.

This would also make the definitions of functions *shorter*
and almost self-documenting

ie: today I might write something

         f123(FileName, Mode) ->
                Fin = FileName ++ ".erl",
                Fout = FileName ++ ".beam",
                compile(Fin, Fout, Mode).

whereas I could write

         f123(filename:F mode:M) ->
                Fin = F ++ ".erl",
                Fout = F++ ".beam",
                compile(Fin, Fout, M).

whose canonical expansion is:

     f123_filename_mode(F, M) ->
                Fin = F ++ ".erl",
                Fout = F++ ".beam",
                compile(Fin, Fout, M).

This change has many advantages:

            + forces use of meaningful tag names in arguments
            + don't have to remember argument order
            + variable names in the body of a function become shorter


If we were to make this change we would have to rewrite all the
standard libraries
but this would be a *good thing* - since this time we could get them right.

This is would also be a backwards compatible change (I think)

 /Joe


More information about the erlang-questions mailing list