New module syntax and semantics?
|
View:
New views
17 Messages
—
Rating Filter:
Alert me
|
 |
New module syntax and semantics?
by Tom Ayerst-2
::
Rate this Message:
Is was looking at the mochiweb code and I saw some oddities.
firstly the module statement: -module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]). In the use of mochiweb I can see things like Req:get(method). This looks more like an object method call, is this new? I cannot see an docs about it. Thanks for any info. Tom Ayerst In the example Req ={mochiweb_request,#Port<0.142>,'GET', "/", {1,1}, {9, {"host", {'Host',"127.0.0.1:8888"}, {"accept", {'Accept', "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"}, nil, {"accept-language", {'Accept-Language', "en-gb,en;q=0.5"}, {"accept-encoding", {'Accept-Encoding', "gzip,deflate"}, {"accept-charset", {'Accept-Charset', "ISO-8859-1,utf-8;q=0.7,*;q=0.7"}, nil,nil}, nil}, {"connection", {'Connection',"keep-alive"}, {"cache-control", {'Cache-Control',"max-age=0"}, nil,nil}, nil}}}, {"user-agent", {'User-Agent', "Mozilla/5.0 (Windows; U; Windows NT 6.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0"}, {"keep-alive", {'Keep-Alive',"300"}, nil,nil}, nil}}}} _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Pablo Polvorin
::
Rate this Message:
seems to be using parameterized modules
http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf 2008/6/29, Tom Ayerst <tom.ayerst@...>: > Is was looking at the mochiweb code and I saw some oddities. > > firstly the module statement: > -module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]). > > In the use of mochiweb I can see things like Req:get(method). > > This looks more like an object method call, is this new? I cannot see an > docs about it. > > Thanks for any info. > > Tom Ayerst > > In the example Req ={mochiweb_request,#Port<0.142>,'GET', > "/", > {1,1}, > {9, > {"host", > {'Host',"127.0.0.1:8888"}, > {"accept", > {'Accept', > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"}, > nil, > {"accept-language", > {'Accept-Language', > "en-gb,en;q=0.5"}, > {"accept-encoding", > {'Accept-Encoding', > "gzip,deflate"}, > {"accept-charset", > {'Accept-Charset', > > "ISO-8859-1,utf-8;q=0.7,*;q=0.7"}, > nil,nil}, > nil}, > {"connection", > {'Connection',"keep-alive"}, > {"cache-control", > > {'Cache-Control',"max-age=0"}, > nil,nil}, > nil}}}, > {"user-agent", > {'User-Agent', > "Mozilla/5.0 (Windows; U; > Windows NT 6.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0"}, > {"keep-alive", > {'Keep-Alive',"300"}, > nil,nil}, > nil}}}} > -- -- pablo http://ppolv.wordpress.com ---- _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Christian S-2
::
Rate this Message:
The feature is called "Parameterized Modules", and it is still unofficial.
See Richard Carlsson's paper on it. google can find it. There was also a follow-up paper presenting OOP-in-Erlang last year at the EUC. PS: Is the unofficialness of this feature going official, or does the vague code-upgrade properties and the hidden-state rewarding programming making it not as well received? _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Ulf Wiger
::
Rate this Message:
That's an example of parameterized modules, which is an experimental
and unsupported feature in Erlang. http://www.planeterlang.org/story.php?title=The_black_art_of_Erlangs_parameterized_modules http://www.erlang.se/workshop/2003/paper/p29-carlsson.pdf BR, Ulf W 2008/6/29 Tom Ayerst <tom.ayerst@...>: > Is was looking at the mochiweb code and I saw some oddities. > > firstly the module statement: > -module(mochiweb_request, [Socket, Method, RawPath, Version, Headers]). > > In the use of mochiweb I can see things like Req:get(method). > > This looks more like an object method call, is this new? I cannot see an > docs about it. > > Thanks for any info. > > Tom Ayerst > > In the example Req ={mochiweb_request,#Port<0.142>,'GET', > "/", > {1,1}, > {9, > {"host", > {'Host',"127.0.0.1:8888"}, > {"accept", > {'Accept', > > "text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8"}, > nil, > {"accept-language", > {'Accept-Language', > "en-gb,en;q=0.5"}, > {"accept-encoding", > {'Accept-Encoding', > "gzip,deflate"}, > {"accept-charset", > {'Accept-Charset', > > "ISO-8859-1,utf-8;q=0.7,*;q=0.7"}, > nil,nil}, > nil}, > {"connection", > {'Connection',"keep-alive"}, > {"cache-control", > > {'Cache-Control',"max-age=0"}, > nil,nil}, > nil}}}, > {"user-agent", > {'User-Agent', > "Mozilla/5.0 (Windows; U; > Windows NT 6.0; en-GB; rv:1.9) Gecko/2008052906 Firefox/3.0"}, > {"keep-alive", > {'Keep-Alive',"300"}, > nil,nil}, > nil}}}} > > _______________________________________________ > erlang-questions mailing list > erlang-questions@... > http://www.erlang.org/mailman/listinfo/erlang-questions > erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Juan Jose Comellas-4
::
Rate this Message:
An does anybody know what would it take to make this feature official/supported? It is really useful in some cases.
On Sun, Jun 29, 2008 at 6:34 PM, Ulf Wiger <ulf@...> wrote: That's an example of parameterized modules, which is an experimental _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Christian S-2
::
Rate this Message:
2008/7/1 Juan Jose Comellas <juanjo@...>:
> An does anybody know what would it take to make this feature > official/supported? It is really useful in some cases. Can you provide examples of how it is useful? _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Juan Jose Comellas-4
::
Rate this Message:
The good thing about this feature is that it provides a way to have an "encapsulated" record replacement.
I have a library that I have built that acts as a client to FreeSWITCH (an open source telephony switch). I'm connected to FS over a socket where I get telephony events in an HTTP-like text protocol. These events have lots of fields (sometimes over 50) so it's necessary to keep their information in records. The problem is that some of these events share some fields. To avoid code duplication I use one function to parse common fields and another one to parse event-specifc data. To make this work I keep the channel data in a record and in a field of this record I keep another record with the event-specific data. For example, whenever a channel is answered or hung up I get an event. As these two events are related to a channel, they share some fields, which I keep in an fs_channel_event record. This record has a field called 'extra' where I keep another record with the fields that are not common. These are a simplified version of the records: % Generic channel event. -record(fs_channel_event, { name, provider, timestamp, channel_id, channel_state, answer_state, call_direction, %% Field where we keep a fs_channel_answer_event or a %% fs_channel_hangup_event. extra }). % Channel answer event. -record(fs_channel_answer_event, { read_codec_name, read_codec_rate, write_codec_name, write_codec_rate }). % Channel hangup event. -record(fs_channel_hangup_event, { hangup_cause }). The code that receives the events is unnecessary cumbersome because it needs to work with a record within a record. If this was encapsulated within a parameterized module, it would become much cleaner. On Tue, Jul 1, 2008 at 11:59 AM, Christian S <chsu79@...> wrote: 2008/7/1 Juan Jose Comellas <juanjo@...>: _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Christian S-2
::
Rate this Message:
2008/7/1 Juan Jose Comellas <juanjo@...>:
> The good thing about this feature is that it provides a way to have an > "encapsulated" record replacement. > The code that receives the events is unnecessary cumbersome because it needs > to work with a record within a record. If this was encapsulated within a > parameterized module, it would become much cleaner. Nested records are not nice, no. For the record: make_stuff() -> #fs_channel_event{extra=#fs_channel_answer_event{write_codec_name=rot13}}. set_stuff(Ex) -> Ex2 = Ex#fs_channel_event{extra=(Ex#fs_channel_event.extra)#fs_channel_answer_event{read_codec_name=leetspeak}}. So the verbose syntax to do the above is what you want to avoid. Did you consider using an approach like the following instead? AnswerEvent = {#fs_channel_event{}, #fs_answer_event{}} HangupEvent = {#fs_channel_event{}, #fs_hangup_event{}} It's easy to deconstruct a tuple in pattern matching. You dont get the nesting above. make_stuff() -> {#fs_channel_event{}, #fs_channel_answer_event{write_codec_name=rot13}}. set_stuff({A, B}) -> {A, B#fs_channel_answer_event{read_codec_name=leetspeak}}. _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Richard A. O'Keefe
::
Rate this Message:
On 2 Jul 2008, at 8:59 am, Juan Jose Comellas wrote: -record(fs_channel_event, {..lots..,extra}). -record(fs_channel_answer_event, {..several..}). -record(fs_channel_hangup_event, {..several..}). > The code that receives the events is unnecessary cumbersome because > it needs to work with a record within a record. If this was > encapsulated within a parameterized module, it would become much > cleaner. I don't quite see how it would, unless, no, you _couldn't_ be thinking of making a module instance for each channel? It's certainly not clear that so heavy a sledgehammer is needed for this nut. Can you provide an example of the 'unnecessarily cumbersome code' so we can see if it can be clarified another way? _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Gleb Peregud
::
Rate this Message:
On Wed, Jul 2, 2008 at 3:11 AM, Richard A. O'Keefe <ok@...> wrote:
> > On 2 Jul 2008, at 8:59 am, Juan Jose Comellas wrote: > > -record(fs_channel_event, {..lots..,extra}). > -record(fs_channel_answer_event, {..several..}). > -record(fs_channel_hangup_event, {..several..}). > >> The code that receives the events is unnecessary cumbersome because >> it needs to work with a record within a record. If this was >> encapsulated within a parameterized module, it would become much >> cleaner. > > I don't quite see how it would, unless, no, you _couldn't_ > be thinking of making a module instance for each channel? > > It's certainly not clear that so heavy a sledgehammer is > needed for this nut. Can you provide an example of the > 'unnecessarily cumbersome code' so we can see if it can > be clarified another way? Is it so heavyweight? Aren't parametrized modules instances just a tuples of type {Mod, Param1, Param2, ...}? Or is calling of functions from such module too expensive? > > > _______________________________________________ > erlang-questions mailing list > erlang-questions@... > http://www.erlang.org/mailman/listinfo/erlang-questions > -- Gleb Peregud http://gleber.pl/ Every minute is to be grasped. Time waits for nobody. -- Inscription on a Zen Gong _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Richard Carlsson-2
::
Rate this Message:
Gleb Peregud wrote:
> On Wed, Jul 2, 2008 at 3:11 AM, Richard A. O'Keefe <ok@...> wrote: >> It's certainly not clear that so heavy a sledgehammer is >> needed for this nut. Can you provide an example of the >> 'unnecessarily cumbersome code' so we can see if it can >> be clarified another way? > > Is it so heavyweight? Aren't parametrized modules instances just a > tuples of type {Mod, Param1, Param2, ...}? Or is calling of functions > from such module too expensive? The representation currently uses tuples, but should be regarded as unknown. If this is made a documented feature, a new opaque 'module' datatype will be added. (This is analogous to how funs were added, several years ago.) The heaviness of the solution in this case is not the calls via a module instance (which are pretty efficient, much like funs), but the need to write a separate module and instantiate it, just to make it easier to work with nested records. You may still be right that it actually makes a nicer solution, but we've seen to little actual code examples to be able to tell if this is really the case or if it could be done better even without abstract modules. /Richard C _______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
erlang = the future?
by not norwegian swede
::
Rate this Message:
_______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Juan Jose Comellas-4
::
Rate this Message:
Yes, that's also an option and in fact I am already doing it, because the event message also has all the information corresponding to a channel, and I keep this information as a separate tuple. The main benefit I see with parameterized modules is that I would be able to expose a generic interface for channel events and freely change the underlying representation without having to modify the modules that use them. It's not a huge benefit, but I would certainly use this feature if I had some certainty that it could suddenly disappear from the next version of Erlang.
On Tue, Jul 1, 2008 at 9:06 PM, Christian S <chsu79@...> wrote:
_______________________________________________ erlang-questions mailing list erlang-questions@... http://www.erlang.org/mailman/listinfo/erlang-questions |
||
|
|
Re: New module syntax and semantics?
by Juan Jose Comellas-4
::
Rate this Message:
In this case I would not necessarily create a module per type of event, but even if I did, I don't see it as a problem. Each event has several functions associated to them that that are part of the event interface. This functionality, coupled with behaviours could even provide something like the concept of an abstract class. I would probably do what Mochiweb does for the accessors of an HTTP request (src/mochiweb_request.erl int the mochiweb package). The mochiweb_request:get/1 function looks like this: get(socket) -> Socket; get(method) -> Method; get(raw_path) -> RawPath; get(version) -> Version; get(headers) -> Headers; get(peer) -> case inet:peername(Socket) of {ok, {Addr={10, _, _, _}, _Port}} -> case get_header_value("x-forwarded-for") of undefined -> inet_parse:ntoa(Addr); Hosts -> string:strip(lists:last(string:tokens(Hosts, ","))) end; {ok, {{127, 0, 0, 1}, _Port}} -> case get_header_value("x-forwarded-for") of undefined -> |
