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

[Richard A. O'Keefe]

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),

Doctor:		What's the problem?
Patient:	It hurts when I do <this>.
Doctor:		Then don't do <that>.

	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.

For imports and exports, we need to generalise
	<function name> ::= <atom> '/' <integer>
to	<function name> ::= <atom> '/' <integer>
			 |  <atom>['('[{'_'|<var>}*',']')']+
so that one could
	-export([decoded time stamp(_) with daylight saving,
		 decoded time stamp(_) sans daylight saving,
		 date from year(Y) month(M) day(D)
	        ]).
and the like.

> 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.  It is already the case that getting the
parentheses wrong, e.g., accidentally leaving out the first parenthesis
and then just adding enough parentheses at the end to close everything,
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.

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

At the moment, Erlang offers two unsatisfactory alternatives with  
respect
to imported functions:

	- if you use -import, you have made it explicit that you intend to
	  use such and such a function, which is a good thing, but you
	  don't need to use a module prefix in the call, which I like, but
	  some people think is a bad thing.
	- if you don't use -import, you have to use a module prefix, which
	  some people think is a good thing, but absolutely anything goes
	  whether you meant it or not, which is clearly a bad thing.

What's needed is something like

	-import_qualified(<module>, [<function name>*',']).

which does all the good things and none of the bad things.
With that notion of importing, more errors could be caught at compile  
time.