> > Is there a good write-up on parameterized module alternatives
> > anywhere?
> > - always include an .hrl and pass a record instance as arg 1 ?
> It depends on what exactly you are using them for.
> Personally, I would define a fun with two args, where the first
> argument
> is a method name and the second argument is a tuple with the
> arguments.
I like this idea, it's clean and elegant, but not without limitations :(
The problem starts when it comes to projects like ChicagoBoss
that we at IDEA love and intensively use every day.
CB uses pmods not only for simple_bridge-based web controllers,
but also for its sophisticated and well integrated concept of
data models being linked with Django templating engine in turn.
Although I fully understand reasons why pmods and their eventual
pseudo-OOP behaviour (like inheritance) are not so clear as they
are implemented today, but in other hand, many excellent projects
may disappear in final result...
I hope such a "total eclipse" is not going to happen, but our case
(over-using the extra unsupported and hackish features) we've just
adapted our technology to framework and totally forgot to standards,
what's in fact our own mistake.
Of course, once something is not well documented/specified/supported,
no one should use it seriously, so we accept the situation we ran into.
Another thing is that some functionality, especially the case of pmods,
is so popular, as everybody knows it because it is really useful,
that everybody also uses it. Pmods seems to be a "de facto" standard
then.
Shouldn't we pay attention since it's used so heavily on many places?
Please note that I am not in a position allowed to dictate nor
recommend anything. It's just a description of my point of view and
I'm pretty sure that no matter on the result of pmod "affair",
everybody will have to accept "new rules" finally (or move elsewhere).
What would be good is if a list of good uses of pmods could
be collected, and honorable workarounds suggested.
This could of course be done interactively on this list.
Present what you think is code that is not easily done well
without pmods, and let the members of this list debate
suitable rewrites. If good alternatives are hard to find, maybe that could inform some EEP for a more
'erlangish' extension that renders pmods truly obsolete?
BR,
Ulf W
On 10 okt 2012, at 00:54, Tomas Morstein <t...@idea.cz> wrote:
> The problem starts when it comes to projects like ChicagoBoss
> that we at IDEA love and intensively use every day.
> CB uses pmods not only for simple_bridge-based web controllers,
> but also for its sophisticated and well integrated concept of
> data models being linked with Django templating engine in turn.
> Although I fully understand reasons why pmods and their eventual
> pseudo-OOP behaviour (like inheritance) are not so clear as they
> are implemented today, but in other hand, many excellent projects
> may disappear in final result...
> I hope such a "total eclipse" is not going to happen, but our case
> (over-using the extra unsupported and hackish features) we've just
> adapted our technology to framework and totally forgot to standards,
> what's in fact our own mistake.
Of course it is doable without pmods. But it is doable with some kind of reinventing the wheel. Do we need to have non standard way to do the same thing?
> What would be good is if a list of good uses of pmods could
> be collected, and honorable workarounds suggested.
> This could of course be done interactively on this list.
> Present what you think is code that is not easily done well
> without pmods, and let the members of this list debate
> suitable rewrites. If good alternatives are hard to find, > maybe that could inform some EEP for a more
> 'erlangish' extension that renders pmods truly obsolete?
> BR,
> Ulf W
> On 10 okt 2012, at 00:54, Tomas Morstein <t...@idea.cz> wrote:
>>>> ...
>> The problem starts when it comes to projects like ChicagoBoss
>> that we at IDEA love and intensively use every day.
>> CB uses pmods not only for simple_bridge-based web controllers,
>> but also for its sophisticated and well integrated concept of
>> data models being linked with Django templating engine in turn.
>> Although I fully understand reasons why pmods and their eventual
>> pseudo-OOP behaviour (like inheritance) are not so clear as they
>> are implemented today, but in other hand, many excellent projects
>> may disappear in final result...
>> I hope such a "total eclipse" is not going to happen, but our case
>> (over-using the extra unsupported and hackish features) we've just
>> adapted our technology to framework and totally forgot to standards,
>> what's in fact our own mistake.
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
On Wed, Oct 10, 2012 at 2:10 AM, Ulf Wiger <u...@feuerlabs.com> wrote:
> What would be good is if a list of good uses of pmods could
> be collected, and honorable workarounds suggested.
> This could of course be done interactively on this list.
> Present what you think is code that is not easily done well
> without pmods, and let the members of this list debate
> suitable rewrites. If good alternatives are hard to find,
> maybe that could inform some EEP for a more
> 'erlangish' extension that renders pmods truly obsolete?
I will take the bait.
As mentioned Chicago Boss uses parameterized modules in a few places
-- in SimpleBridge (the connector to Mochiweb et al) and, more
importantly, in custom controller code and in BossDB[1]. Before diving
into technical details, I will note that if support for pmods is
removed in Erlang core, then essentially every user of CB will have to
rewrite all of their model code and database accesses, and make
significant modifications to their controller code. I don't have
statistics on the number of deployments, but we do have 284 members on
our mailing list, and the project is one of the ten most-watched
Erlang projects on GitHub. So even though pmods are "experimental", a
lot of developers are watching the fate of pmods very closely.
I designed BossDB around parameterized modules because pmods allow one
to develop with a familiar ORM pattern in Erlang. I wanted a
record-oriented API that was simple, succinct, and comprehensible.
With pmods I was able to succeed in these goals. For example, to
create a new record:
Person = person:new(id, "Joe", "Armstrong")
To save it:
case Person:save() of
{ok, SavedPerson} -> % do something ...
{error, ValidationErrors} -> % do something else ...
end
To access an attribute:
Person:first_name().
"Joe"
Person:last_name().
"Armstrong"
On the inside, one can access the "internal" parameters directly to
construct additional accessors:
-module(person, [Id, FirstName, LastName]).
full_name() -> FirstName ++ " " ++ LastName.
Or perform validation:
validation_tests() ->
[{fun() -> length(FirstName) > 0, "First name must be non-empty!"},
{fun() -> length(LastName) > 0, "Last name must be non-empty!"}].
In world without pmods, these APIs would be more difficult to read and
the custom code would be more difficult to write. For example, the
accessors would look like:
You'd then need to define ways of accessing the internal versions of
variables versus the accessed ones (which might be cleaned up for the
view, converted to a list, etc). Right now, with pmods, the
distinction is simple -- inside your module you can use Variable to
get the internal version, use THIS:variable() to get the
externally-visible version.
To experienced Erlang programmers, the pmod-free code above hardly
represent the worst treachery against simplicity. But here, I
personally do not find the pure-functional style of coding to be
preferable to the pmod way of doing things.
For the class of Erlang projects that I work on, the most important
thing is for code to be readable. I think it is the code readability
that has attracted other users to use Chicago Boss for their own
projects. I realize that the use of pmods comes at a cost (e.g. poor
dialyzer support), but to be honest, I really don't care. If I can
read the code and if it passes the test suite, I will ship it. I would
of course prefer that pmods be promoted to first-class citizenship so
that we could enjoy the fruits of static analysis, but given the
choice between pmods and the dialyzer for a database API, I will
choose continue to choose pmods.
I have focused the discussion here on BossDB, but there are other
times where a pmod is the most convenient way to define callback
behavior. You get a few variables "for free" in the parameter list, so
the callback writer does not have to accept the same list of variables
in every single function. For this reason the web controllers in
Chicago Boss are pmods with request information as one variable and
the current session ID as another.
I am sorry if this set of choices offends anyone's functional
sensibilities, but I think everyone should be able to code in a style
that is most productive for them. For me that style is Erlang plus
judicious use of parameterized modules. I am happy for you to put all
the warning signs that you want around the pmod documentation, and to
recount all the horrible pmod code that you've had to disentangle as
you're swapping war stories around the campfire, but I hope that
parameterized modules will exist in future versions of Erlang so that
people who find them the be a good solution for a particular class of
problems can continue to use them.
> On 10 okt 2012, at 00:54, Tomas Morstein <t...@idea.cz> wrote:
>>>> ...
>> The problem starts when it comes to projects like ChicagoBoss
>> that we at IDEA love and intensively use every day.
>> CB uses pmods not only for simple_bridge-based web controllers,
>> but also for its sophisticated and well integrated concept of
>> data models being linked with Django templating engine in turn.
>> Although I fully understand reasons why pmods and their eventual
>> pseudo-OOP behaviour (like inheritance) are not so clear as they
>> are implemented today, but in other hand, many excellent projects
>> may disappear in final result...
>> I hope such a "total eclipse" is not going to happen, but our case
>> (over-using the extra unsupported and hackish features) we've just
>> adapted our technology to framework and totally forgot to standards,
>> what's in fact our own mistake.
> _______________________________________________
> erlang-questions mailing list
> erlang-questi...@erlang.org
> http://erlang.org/mailman/listinfo/erlang-questions
On Thu, Oct 11, 2012 at 11:52 PM, Evan Miller <emmil...@gmail.com> wrote:
> I designed BossDB around parameterized modules because pmods allow one
> to develop with a familiar ORM pattern in Erlang. I wanted a
> record-oriented API that was simple, succinct, and comprehensible.
> With pmods I was able to succeed in these goals. For example, to
> create a new record:
> Person = person:new(id, "Joe", "Armstrong")
> To save it:
> case Person:save() of
> {ok, SavedPerson} -> % do something ...
> {error, ValidationErrors} -> % do something else ...
> end
> To access an attribute:
> Person:first_name().
> "Joe"
> Person:last_name().
> "Armstrong"
I believe that someone from OTP team mentioned that the parametrized
modules are to be deleted, but tuple modules will stay. Essentially
this will mean that instead of writing:
Person = person:new("Joe", "Armstrong").
Person:first_name().
"Joe"
case Person:save() of
{ok, SavedPerson} -> % do something ...
{error, ValidationErrors} -> % do something else ...
end.
So from point of view of readability there will be no change,
althought the amount of code in the model module (person.erl) will
slightly increase.
Ha, that's what I didn't know about!
With this feature, I can start to sleep without nightmares again :-)
> So from point of view of readability there will be no change,
> althought the amount of code in the model module (person.erl) will
> slightly increase.
What's not so big deal since both boss_db and iodb models
are preprocessed (partially generated) by model-compiler.
So only what we will have to do is to change model compiler.
What's more, I believe boss_db could remain backward compatible
because it shouldn't be so problematic to transform
-model (person, [FirstName, LastName])
to
-model (person).
-record (person, {first_name, last_name}).
during the preprocessing, before passing to the Erlang compiler
itself.
With our IODB model compiler, we already do something similar
but in another direction -- we define IODB data fields through
attributes that are in turn used to generate access functions.
Each module that is not wrote as parametrized is automatically
converted to pmod by preprocessor.
It is also automatically extended by another module with
abstract model logic, what's the real problem why I have
started this thread ;-)
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
From what I learned earlier this year, tuple modules have a bleak future as well:
===
[1] > But I was wondering if there's any word out about the fate of tuple
> modules? The ones like {erlang}:element(1). Are they expected to be
> kept around? (I certainly hope they are :)
No, we don't expect to keep them.
As pointed out by others, "tuple modules" is just an implementation
detail of parameterized modules (which is an experimental feature).
We have not reached a decision yet, but in the future we expect
we will do one of two things:
* Remove parameterized modules completely from the compiler
and run-time system.
OR
* Implement parameterized modules properly by creating a new
data type, both to allow better type checking by Dialyzer, and
to possibly improve performance.
On Friday, October 12, 2012 1:04:52 AM UTC-7, Gleb Peregud wrote:
> I believe that someone from OTP team mentioned that the parametrized > modules are to be deleted, but tuple modules will stay. Essentially > this will mean that instead of writing:
> Person = person:new("Joe", "Armstrong"). > Person:first_name(). > "Joe" > case Person:save() of > {ok, SavedPerson} -> % do something ... > {error, ValidationErrors} -> % do something else ... > end.
> So from point of view of readability there will be no change, > althought the amount of code in the model module (person.erl) will > slightly increase.
What is even more sad, I've been told that tuple modules will likely be killed in the name of performance.
Earlier this year I conducted an experiment and sent its proceedings to Björn and this mailing list, but I have never heard back from him.
Here it is again:
"I actually just did a totally unscientific test. I took the maint
branch, and ran 10,000,000 Mod:fn() calls where Mod was passed from
another function call and was just an atom. I ran it on maint, and on
my Mac Pro timer:tc clocked 446983 (that's 0.446 seconds).
After that, I brutally removed tuple call support from apply and
fixed_apply BIFs in beam_emu.c, making `if (is_not_atom(module))` go
straight to error label. I also removed `this` variable which was used
in those checks because there was no need for it anymore.
I re-ran the test, and timer:tc clocked 440680 and around.
So, the runtime cost difference was about 6000 microseconds, or 0.006
seconds, for 10 million calls. If I am not mistaking, this is a 1.35%
speedup on something as low cost as about 0.0446 microseconds per call
(or 0.0440 microseconds per call without support for tuple calls).
Is it this big of a difference to support the removal? What if we made
tuple calls a documented feature? I'd be glad to write an EEP to
support it."
On Friday, October 12, 2012 10:35:26 AM UTC-7, Yurii Rashkovskii wrote:
> From what I learned earlier this year, tuple modules have a bleak future > as well:
> ===
> [1] > But I was wondering if there's any word out about the fate of tuple
> > modules? The ones like {erlang}:element(1). Are they expected to be
> > kept around? (I certainly hope they are :)
> No, we don't expect to keep them.
> As pointed out by others, "tuple modules" is just an implementation
> detail of parameterized modules (which is an experimental feature).
> We have not reached a decision yet, but in the future we expect
> we will do one of two things:
> * Remove parameterized modules completely from the compiler
> and run-time system.
> OR
> * Implement parameterized modules properly by creating a new
> data type, both to allow better type checking by Dialyzer, and
> to possibly improve performance.
> /Björn
> ====
> On Friday, October 12, 2012 1:04:52 AM UTC-7, Gleb Peregud wrote:
>> I believe that someone from OTP team mentioned that the parametrized >> modules are to be deleted, but tuple modules will stay. Essentially >> this will mean that instead of writing:
>> Person = person:new("Joe", "Armstrong"). >> Person:first_name(). >> "Joe" >> case Person:save() of >> {ok, SavedPerson} -> % do something ... >> {error, ValidationErrors} -> % do something else ... >> end.
>> So from point of view of readability there will be no change, >> althought the amount of code in the model module (person.erl) will >> slightly increase.
OTOH, Björn Gustavsson himself said earlier (8 Oct):
> Are you sure? What I have understood from previous email
> messages on this list is that many projects use "tuple modules"
> (which is an implementation detail in parameterized modules)
> and not parameterized modules directly. See for instance:
> We are thinking about removing the compiler support for parameterized
> modules, but keeping the low-level mechanism in erlang:apply/3 and
> the inheritance hack in the error_handler module.
Just for fun, FWIW, I wrote a little parse transform that gives
roughly the same functionality as parameterized modules,
but without relying on the special syntax.
Note how it's in parse_trans/examples/, so it's mainly for fun.
It does seem to work, though.
BR,
Ulf W
On 12 Oct 2012, at 19:35, Yurii Rashkovskii wrote:
> From what I learned earlier this year, tuple modules have a bleak future as well:
> ===
> [1] > But I was wondering if there's any word out about the fate of tuple
> > modules? The ones like {erlang}:element(1). Are they expected to be
> > kept around? (I certainly hope they are :)
End of speculation, we have made a number of decisions for the upcoming
R16B ( end of February). We will describe this in more detail on this list
and on erlang.org
next week. Parameterized modules is part of this decision, and there is no
need to worry. The code using them today will continue to work.
OTOH, Björn Gustavsson himself said earlier (8 Oct):
Are you sure? What I have understood from previous email
messages on this list is that many projects use "tuple modules"
(which is an implementation detail in parameterized modules)
and not parameterized modules directly. See for instance:
We are thinking about removing the compiler support for parameterized
modules, but keeping the low-level mechanism in erlang:apply/3 and
the inheritance hack in the error_handler module.
Just for fun, FWIW, I wrote a little parse transform that gives
roughly the same functionality as parameterized modules,
but without relying on the special syntax.
> End of speculation, we have made a number of decisions for the upcoming
> R16B ( end of February). We will describe this in more detail on this
> list and on erlang.org <http://erlang.org>
> next week. Parameterized modules is part of this decision, and there is
> no need to worry. The code using them today will continue to work.
> OTOH, Björn Gustavsson himself said earlier (8 Oct):
>> Are you sure? What I have understood from previous email
>> messages on this list is that many projects use "tuple modules"
>> (which is an implementation detail in parameterized modules)
>> and not parameterized modules directly. See for instance:
>> We are thinking about removing the compiler support for parameterized
>> modules, but keeping the low-level mechanism in erlang:apply/3 and
>> the inheritance hack in the error_handler module.
> Just for fun, FWIW, I wrote a little parse transform that gives
> roughly the same functionality as parameterized modules,
> but without relying on the special syntax.
> Note how it's in parse_trans/examples/, so it's mainly for fun.
> It does seem to work, though.
> BR,
> Ulf W
> On 12 Oct 2012, at 19:35, Yurii Rashkovskii wrote:
>> From what I learned earlier this year, tuple modules have a bleak
>> future as well:
>> ===
>> [1] > But I was wondering if there's any word out about the fate of tuple
>> > modules? The ones like {erlang}:element(1). Are they expected to be
>> > kept around? (I certainly hope they are :)
On Friday, October 12, 2012 12:36:55 PM UTC-7, Kenneth Lundin wrote:
> End of speculation, we have made a number of decisions for the upcoming > R16B ( end of February). We will describe this in more detail on this list > and on erlang.org
> next week. Parameterized modules is part of this decision, and there is > no need to worry. The code using them today will continue to work.
> OTOH, Björn Gustavsson himself said earlier (8 Oct):
> Are you sure? What I have understood from previous email
> messages on this list is that many projects use "tuple modules"
> (which is an implementation detail in parameterized modules)
> and not parameterized modules directly. See for instance:
> We are thinking about removing the compiler support for parameterized
> modules, but keeping the low-level mechanism in erlang:apply/3 and
> the inheritance hack in the error_handler module.
> Just for fun, FWIW, I wrote a little parse transform that gives
> roughly the same functionality as parameterized modules,
> but without relying on the special syntax.
> Note how it's in parse_trans/examples/, so it's mainly for fun.
> It does seem to work, though.
> BR,
> Ulf W
> On 12 Oct 2012, at 19:35, Yurii Rashkovskii wrote:
> From what I learned earlier this year, tuple modules have a bleak future > as well:
> ===
> [1] > But I was wondering if there's any word out about the fate of tuple
> > modules? The ones like {erlang}:element(1). Are they expected to be
> > kept around? (I certainly hope they are :)
Given that the underlying mechanism stays, and only the syntactical
conveniences are under threat: to what extent can the current pmod handling
be replaced by / emulated with a parse_transform?
If it's possible to do it that way, that might provide the best of two
worlds: the existence of the pmod feature without having the maintenance
burden in the compiler.
Den 12/10/2012 10.04 skrev "Gleb Peregud" <glebe...@gmail.com>:
> On Thu, Oct 11, 2012 at 11:52 PM, Evan Miller <emmil...@gmail.com> wrote:
> > I designed BossDB around parameterized modules because pmods allow one
> > to develop with a familiar ORM pattern in Erlang. I wanted a
> > record-oriented API that was simple, succinct, and comprehensible.
> > With pmods I was able to succeed in these goals. For example, to
> > create a new record:
> > Person = person:new(id, "Joe", "Armstrong")
> > To save it:
> > case Person:save() of
> > {ok, SavedPerson} -> % do something ...
> > {error, ValidationErrors} -> % do something else ...
> > end
> > To access an attribute:
> > Person:first_name().
> > "Joe"
> > Person:last_name().
> > "Armstrong"
> I believe that someone from OTP team mentioned that the parametrized
> modules are to be deleted, but tuple modules will stay. Essentially
> this will mean that instead of writing:
> Person = person:new("Joe", "Armstrong").
> Person:first_name().
> "Joe"
> case Person:save() of
> {ok, SavedPerson} -> % do something ...
> {error, ValidationErrors} -> % do something else ...
> end.
> So from point of view of readability there will be no change,
> althought the amount of code in the model module (person.erl) will
> slightly increase.
On Sunday, October 14, 2012 2:55:43 PM UTC-7, Erik Søe Sørensen wrote:
> Given that the underlying mechanism stays, and only the syntactical > conveniences are under threat: to what extent can the current pmod handling > be replaced by / emulated with a parse_transform?
> If it's possible to do it that way, that might provide the best of two > worlds: the existence of the pmod feature without having the maintenance > burden in the compiler.
> Den 12/10/2012 10.04 skrev "Gleb Peregud" <gleb...@gmail.com <javascript:>
> >:
>> On Thu, Oct 11, 2012 at 11:52 PM, Evan Miller <emmi...@gmail.com<javascript:>> >> wrote:
>> > I designed BossDB around parameterized modules because pmods allow one
>> > to develop with a familiar ORM pattern in Erlang. I wanted a
>> > record-oriented API that was simple, succinct, and comprehensible.
>> > With pmods I was able to succeed in these goals. For example, to
>> > create a new record:
>> > Person = person:new(id, "Joe", "Armstrong")
>> > To save it:
>> > case Person:save() of
>> > {ok, SavedPerson} -> % do something ...
>> > {error, ValidationErrors} -> % do something else ...
>> > end
>> > To access an attribute:
>> > Person:first_name().
>> > "Joe"
>> > Person:last_name().
>> > "Armstrong"
>> I believe that someone from OTP team mentioned that the parametrized
>> modules are to be deleted, but tuple modules will stay. Essentially
>> this will mean that instead of writing:
>> Person = person:new("Joe", "Armstrong").
>> Person:first_name().
>> "Joe"
>> case Person:save() of
>> {ok, SavedPerson} -> % do something ...
>> {error, ValidationErrors} -> % do something else ...
>> end.
>> So from point of view of readability there will be no change,
>> althought the amount of code in the model module (person.erl) will
>> slightly increase.
> Given that the underlying mechanism stays, and only the syntactical
> conveniences are under threat: to what extent can the current pmod
> handling be replaced by / emulated with a parse_transform?
I think this is exactly what Ulf meant by the code presented on Github.
We also do some transforms in our database project, so we can do one
more new easily, but it has some limitations.
> If it's possible to do it that way, that might provide the best of
> two worlds: the existence of the pmod feature without having the
> maintenance burden in the compiler.
It's just a few minutes I was remsh-connected to a live system and did
some manual data updates of our data objects (based on pmods).
AFAIK, this wouldn't be possible with transforms, so transforms
are only partial solution, if we'll simply omit their other disadvantages.
I'd wait for what OTP team is going to publish within the upcoming week..
_______________________________________________
erlang-questions mailing list
erlang-questi...@erlang.org
http://erlang.org/mailman/listinfo/erlang-questions
> Given that the underlying mechanism stays, and only the syntactical conveniences are under threat: to what extent can the current pmod handling be replaced by / emulated with a parse_transform?
