[erlang-questions] lists:reverse/1 as a built-in function

[Robert Virding]

I agree with 1 & 3 but I am a bit dubious about 2. It means you have 
added an extra default level for system functions and it is not really 
consistent. Although it would probably not break much code.

I personally wonder if you are going to change how BIFs are handled and 
go the whole hog and make it completely consistent with normal 
functions: either they are local or imported. That's it. At least you 
always KNOW what it means. Although it would break code. :-)

Actually Jonas Barklund and I had a very reasonable solution:

1. ALL functions without module are either local or imported.
2. All BIFs are pre-imported automatically for you
3. There is an unimport declaration. (works for all imports)

So if you wanted use BIFs as local functions then you would unimport 
them from 'erlang'. Very consistent and explicit about what is going on, 
and backwards compatible.

We also had another idea which I really liked: split the predefined 
module 'erlang' into a number of predefined modules like process, atom, 
number, .... And some left in erlang. These modules would be like todays 
erlang in that they would be part of the language and specially treated. 
I hink the result would be easier to handle that the wopping great 
erlang of today. Alas some worried about backwards incompatibility if 
people had there own modules with the same names.

Robert

Richard A. O'Keefe wrote:
> Just because something is a core part of the language doesn't mean I
> always want it.  I believe that 
> (1) Infix and prefix operator syntax should simply be an alternative
>     way of writing an ordinary function call, so that X+1 and '+'(X,1)
>     should be exactly the same thing.
> (2) There should be three mutually exclusive ways to make a function
>     available for calling without a prefix:
>     (a) define it in the module
>     (b) explicitly import it from some module
>     (c) obtain it from erlang: if neither (a) nor (b) applies.
>     This means that adding new functions to erlang: cannot break working
>     code because working code would have to do (a) or (b).
> (3) Imitating Java and especially imitating Java's inside-out packages
>     is a Bad Thing.
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>