[erlang-questions] Improve $handle_undefined_function

[Kenneth Lundin]

Thank you for all input in this matter. I mean both regarding -extends and
$handle_undefined_function.

I think it is place for some clarifications which will have implications on
earlier statements in this thread.

On October 19:th a decision from the OTP Technical Board (a fora internal
to the
OTP development team at Ericsson) regarding parameterized types was
announced.

The announcement looked like this:
*Issue 4 - What to do with unsupported feature 'parameterized modules'.*

- The board acknowledges that a lot of software relies on this feature
although it's always been experimental. The current form of the
implementation is not acceptable and the parameterized modules as such has
never been accepted as a feature in the language. The feature is also not
compatible with for example module-fun's and is not fully integrated with
the rest of the tools in OTP.

To allow for source code compatibility, the board decides to only remove
the syntactic support for parameterized modules. This means:

* Apply with tuple modules will be retained, supported and properly
documented.

* Error handler functionality that today supports inheritance will be
slightly generalized, so that parameterized modules can contain stubs to
facilitate inheritance. The functionality in the error handler will be
documented.

* The parser will accept the syntax for implementation of parameterized
modules, but if the parameterized modules are not handled by a
parse_transform, an error message will be generated at a later stage (this
concerns the implementation of the modules themselves only).

* A parse_transform handling source code implementing a parameterized
module will be published in the public domain, free to use and include in
any package needing it. It will however not be part of OTP. As it uses
supported and documented functionality, it will however be expected to work
for forthcoming releases as well, or at least to be possible to adopt to
forthcoming releases.

As apply with tuple modules is retained, calls to parameterized modules
will remain as they look today. Only the implementation of the
parameterized modules themselves need to apply a parse transform to allow
for the "unsupported" syntax extensions. Calling a function in an instance
of a parameterized module from an evaluator (e.g. the shell) will also work
as before.



As I remember it we got mainly positive reactions regarding this decision
and now we have implemented it exactly as said and it will be released in
R16A (beta release on January 30:th) and R16B (product release on Feb
27:th).

In short the previously undocumented support for parameterized modules is
removed from the OTP distribution and is replaced with a parse transform
which we will provide as a separate project at Github. We do this to make
the transition smooth for projects having used the parameteized modules
feature. We will not continue to support or enhance that parse transform in
the future (it is up to the users interested in the feature to do that).

Some of the comments in this thread are related to how parmaterized modules
and
'-extends' in particular could be improved, changed etc. and it is
perfectly ok to do that, but it is not part of Erlang/OTP any more.

As a consequence of removing parameterized modules from OTP we have changed
the error_handler by removing a built in knowledge about parameterized
modules and by adding a more general and useful functionality, the
$handle_undefined_function feature.

This feature is useful in a number of situations where one was earlier
forced to modify the global error_handler:

- Can support the parse-transform for parameterized modules (the -extends
attribute)

- Can be used to safely (or more safely than before) implement various
"mocking" functionality for testing purposes

- Can be used to interface external generic RPC interfaces like the android
case.

It will be documented in the error_handler module together with a fat
warning that you should not use this in normal production code etc. The
error_handler module is hardly something that the average or novice
programmer will stumble into and immediately use features from.

So in summary we have done what we promised to do:

- taken parmeterized modules out of Erlang/OTP (offering a parse_transform
instead)

- removed knowledge about parameterized modules from error_handler and
added a more generic and safe way for extending the error_handler per
module instead.



/Regards Kenneth, Erlang/OTP Ericsson








On Wed, Jan 23, 2013 at 5:01 AM, Richard O'Keefe <ok@REDACTED> wrote:

>
> On 23/01/2013, at 7:30 AM, Evan Miller wrote:
> >
> > Most people on this list seem to care about "big-scale" issues like
> > reliability, predictability, processing kajillions of commercial
> > transactions, and so forth. I happen to care a lot more about
> > "small-scale" issues -- in particular, the programming experience of
> > one person just trying to get something to work for the first time and
> > having the code look nice.
>
> I care a heck of a lot about small scale usability issues,
> and that's precisely why I DISLIKE pmods -extends and so on.
> Because I have learned from painful experience that reliability
> and predictability ARE small scale usability issues.
>
> The fact that -extends as currently conceived destroys our
> ability to know what a module exports, well, words fail me.
> It's such a *TERRIBLE* thing to do to plain simple-minded
> programmers like me that it makes me want to smash things in
> anger.  I make mistakes *all the time*, and not being able to
> ask "have I actually defined everything that is either called
> or exported" any more, well, how does THAT help me?
>
> Let's face it, I can get pretty close to the effect of
> -extends WITHOUT it.  I happen to have a small Erlang file
> that lets me type
>    > export_from:module(foobar).
> in an Erlang shell and get an export list and a bunch of
> glue definitions that I can paste into a source file.
> It's careful to exclude module_info/[0,1], and it uses
> the io module rather clumsily.  And it's under 50 SLOC.
>
> Writing a parse transform that gets the info from a .beam file
> would be harder, but easier for a programmer to use.  I'd rather
> not do that, because simply saying "re-export EVERYTHING" is too
> dangerous.
>
>     -export_from(Module, Functors).
>
> which I think I first proposed back in about 1996, permits so
> much more checking, and makes life SO much nicer for the small-
> scale programmer, that the contrast is almost dizzying.
>
> > I think that's ultimately where innovation
> > comes from -- one person experimenting around, seeing if things work,
> > and not caring whether it's production-ready or fit to be seen by
> > anyone.
>
> Right.  And *not* from shoving half-baked ideas out the door
> too early.  Quintus did that once, and ever since Prolog programmers
> have been using an I/O approach that was significantly inefficient and
> clumsy compared with what we _could_ have had if the ***** who shoved
> it out the door had asked around the company if anyone had a better
> idea.  The botch even made it into the standard!  (Heck, it even got
> copied into Erlang...)
>
> > For example, Erlang is missing one feature found in every other
> > language that I've used that is missing from Erlang. It's the ability
> > to write:
> >
> >   Person.name
>
> That's why Joe Armstrong and I have both proposed essentially the same
> data structure (in my case, complete with details of how it can be
> implemented and actual measurements from a pilot implementation in a
> micro-VM) many years ago.
>
> However, I would point out that this feature requires EITHER
> a static type system (Pascal, C, C++, Oberon, Java, C#, &c)
> OR a run-time search to find where the field is.
>
> >  Every other language I can think of has something
> > like this,
>
> There are vastly more languages than you appear to be aware of.
> The trick is to make something like this
>  - work EFFICIENTLY
>  - WITHOUT a strong static type system.
>
> > person.name(). I wonder how many potential Erlang programmers moved on
> > to something else because they couldn't find this very simple language
> > construct while they were playing around with Erlang for the first
> > time.
>
> Only the hard-of-thinking who were unwilling to learn a new way to
> program.
> >
> > Thanks to Pmods and some code generation, I was able to come up with
> > what I felt was acceptable alternative in Erlang: Person:name().
>
> Did you ever measure how long that took?
> Compared with Person#person_name?
> Here's a hint:  if you are sick of having programs
> run too fast, I've some old machines I could sell you.
> There are easier ways to go slow than abusing the language.
>
> Erlang is *NOT* an object oriented language.
> That's deliberate:  the inventors of Erlang were well aware of OO
> and chose not to use it.
>
> If you try to use Erlang as if it were an object oriented language,
> you are wasting your time.  F# will do a _much_ better job of
> satisfying you, and it's a perfectly fine language available under
> Mono as well as .NET.
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20130123/8f6aee33/attachment.htm>