[erlang-questions] Erlang/YAWS vs Free Pascal/Xitami

Vlad Dumitrescu vladdu55@REDACTED
Mon Mar 31 08:54:47 CEST 2008


On Mon, Mar 31, 2008 at 4:24 AM, Richard A. O'Keefe <ok@REDACTED> wrote:
> On 28 Mar 2008, at 9:31 pm, Vlad Dumitrescu wrote:
>  > The trouble I ran into was when the function call isn't literal. It's
>  > easy to do
>  >    Fun = extend_from_labelled_to_with_edge,
>  >    Fun(G, F, L, T),
>         Fun = fun (G, F, L, T) ->
>            extend(G) with edge from(F) to(T) labelled(L),
>         end,
>         Fun(G, F, L, T)
>  Since in general the argument order you want for the Fun will *not*
>  be the order of the arguments in the original function, you will want
>  to do this *anyway* most of the time.

True, but verbose.

>  > Another small issue is that if I want to write
>  >  somefun(X), otherfun(Y)
>  > but forget or delete the comma, the error will be seen only at
>  > runtime.
>  If you call a function with no module prefix and there is no such
>  function defined in or imported into the current module, the compiler
>  should report an error.

This can happen for "somemodule:somefun(X), otherfun(Y)" too.

> It is already the case that getting the
>  parentheses wrong, /.../  produces mistakes like
>         somefun(X, otherfun(Y))
>  which will call otherfun/1 first instead of second and then call
>  somefun/2 instead of somefun/1, which might well exist.  So there isn't
>  really any new kind of problem here.

No, it's not a new problem. But it's more ways to do it wrong.

>  Only experimentation could determine just how error prone the proposed
>  notation is and whether its helpfulness in getting arguments in the
>  right order compensates.

Absolutely. That's why I thought I'd give it a try and implement it.
Compared with the other proposals of yours, this one is much easier

best regards,

....( )/ ( )...

More information about the erlang-questions mailing list