| Author |
Message |
|
| matthias at corelatus.se |
 Posted: Fri Mar 21, 2003 11:30 am |
 |
|
|
Guest
|
martin> While the ideas that are expressed in this thread are
martin> quite interesting and have much merit I think that they
martin> would serve to undermine erlangs greatest strength -
martin> simplicity.
vlad> What we are talking about here about extendig Erlang, is
vlad> not really about the language, but about OTP.
Changing the meaning of a function call is not about changing OTP. It
is changing the language. You can no longer be sure that the code
executed by a call to foo:bar() can be found in the module foo.
That is a big new uncertainty.
Matthias
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Vlad.Dumitrescu at erv.er |
| Posted: Fri Mar 21, 2003 12:17 pm |
|
|
|
Guest
|
Hi,
> vlad> What we are talking about here about extendig Erlang, is
> vlad> not really about the language, but about OTP.
>
> Changing the meaning of a function call is not about changing OTP. It
> is changing the language. You can no longer be sure that the code
> executed by a call to foo:bar() can be found in the module foo.
>
> That is a big new uncertainty.
Of course not all ideas are necessary right, it's more like a brainstorming. The idea of automatically dispatching to some other module any call to an undefined function is a little older (in the context) and for what I am concerned I am already past it.
I thought Martin's remark was about the latest topics, where I talked about extending behaviours.
regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| jay at duomark.com |
| Posted: Fri Mar 21, 2003 1:42 pm |
|
|
|
Guest
|
At 11:22 AM 3/21/03 +0100, Vlad Dumitrescu (EAW) wrote:
>Maybe a better analogy than "objects" is "components". Use behaviours
>(as processes or as modules) as components, building stones for more
>advanced components and finally whole systems. This didn't work so
>well for OO components, but this doesn't mean the basic idea is
>flawed.
I like the term "composites". It doesn't give any notion of
concreteness like objects or components, but it does convey
the same sense of "amalgam" that I was trying to describe.
I am trying hard to avoid being tainted by OO thinking because
I am struggling and think out loud about new ways of coding
because I have a new tool that has different features than my
old tools.
I am thinking in terms of combining processes. You could
override in the process that binds behaviours, but it is more
reusable if you override by creating a new process (which
might delegate functions either via module delegation or via
process delegation) so that both versions are always available
as you move forward.
jay
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Fri Mar 21, 2003 6:33 pm |
|
|
|
Guest
|
On Fri, 21 Mar 2003 12:31:32 +0100
Matthias Lang <matthias_at_corelatus.se> wrote:
>
> martin> While the ideas that are expressed in this thread are
> martin> quite interesting and have much merit I think that they
> martin> would serve to undermine erlangs greatest strength -
> martin> simplicity.
>
> vlad> What we are talking about here about extendig Erlang, is
> vlad> not really about the language, but about OTP.
>
> Changing the meaning of a function call is not about changing OTP. It
> is changing the language. You can no longer be sure that the code
> executed by a call to foo:bar() can be found in the module foo.
>
> That is a big new uncertainty.
>
> Matthias
Is it really so new?
-module(foo).
bar() -> baz:quuz().
i.e.:
1. you can't design a language which disallows spaghetti.
2. the more powerful a language feature, the easier it makes spaghetti.
3. when you introduce a new feature that makes spaghetti easier, you
should probably make a note of that lest it looks like you're encouraging
it.
Other than that... I do agree that Erlang is, if not simple, then
straightforward, and any proposed extension that doesn't meet a sort of
common straightforwardness criterion will likely not be adopted.
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Fri Mar 21, 2003 7:09 pm |
|
|
|
Guest
|
On Fri, 21 Mar 2003 11:22:01 +0100
"Vlad Dumitrescu (EAW)" <Vlad.Dumitrescu_at_erv.ericsson.se> wrote:
> Hello,
>
> > From: Jay Nelson [mailto:jay_at_duomark.com]
> >Chris and Vlad discussed:
> >> Extensions to gen_server to support "behavers" and pseudo
> >> inheritance call chains ...
(aside: just to clarify: "behaver" is not a new thing, it's a coined term
for "a module which implements a behaviour"... which Erlangers write every
day, but don't seem to have a non-specific word for - they tend to use
the name of the specific behaviour that they're implementing as in "I've
written a gen_server" rather than "I've written a behaver for
gen_server")
> [...]
> What I'd like to be able to do is create a process by specifying
> several interfaces/behaviours it will support, a GUI related example
> might be for a button: I need let's say 'drawable', 'clickable',
> 'mouse_over'. Just by naming them, I get the functionality,
-module(my_button).
-behaviour(drawable).
-behaviour(clickable).
-behaviour(mouse_over).
?
> and I can
> (if I want) to override some of the functionality to better suit the
> button's needs.
before_draw(Button) ->
% arbitrarily don't draw the button if it's on the right side
case x(Button) of
X when X > screen_width() / 2 ->
cancel;
_ ->
ok
end.
?
> Potential problem: how to ensure that these behaviours do not have
> overlapping interfaces? (i.e. message tags or callback names that are
> the same)
Prepend a tag?
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| spearce at spearce.org |
| Posted: Fri Mar 21, 2003 7:24 pm |
|
|
|
Guest
|
Chris, I think Matthias' concern was more related to overloading
the undefined_function behavior in error_handler, or some similiarly
abstract way of making a function call. Even my -inherit() and dispatch
function I proposed would fall here, as it makes the code signifcantly
harder to follow. At least now you can lookup module foo, locate the
definition of bar and see it calls baz:quuz(), and recurse. :)
One of the things I like about Erlang is just how simple it is. It
only takes me 5 minutes to locate the definition of almost any system
function, even if it is down deep in the emulator's native C code.
That's hard to do in most other current 'high-level' programming
languages. (I use the term 'high-level' loosely too.)
Lately I've been reading about just how flawed SQL databases are from
Codd's relational model introduced in '69. I'm starting to feel the
same way about object oriented programming in general, and I'm just
hoping that the same tendenacies that caused programmers to build,
adopt and eventually believe that SQL databases are perfect, true
relational systems doesn't cause Erlang to grow into a simliar
type of system.
On the other hand, I just wrote a server for which I use two gen_server
processes to implement a TCP server. (Like what was kicking around here
a week or two ago.) Only I wanted support of both gen_tcp and ssl,
and in both passive and active modes (I use {active, once}). Can we
say macros, include files, and just some weird magic to make it work?
Its not as bad as I'd feared (5 macros, 1 major source file, 2 module
files to set the 5 macros and include the major source file), but its
still not ideal.
Chris Pressey <cpressey_at_catseye.mb.ca> wrote:
> On Fri, 21 Mar 2003 12:31:32 +0100
> Matthias Lang <matthias_at_corelatus.se> wrote:
> > Changing the meaning of a function call is not about changing OTP. It
> > is changing the language. You can no longer be sure that the code
> > executed by a call to foo:bar() can be found in the module foo.
> >
> > That is a big new uncertainty.
> >
> > Matthias
>
> Is it really so new?
>
> -module(foo).
> bar() -> baz:quuz().
--
Shawn.
"I think trash is the most important manifestation of culture we have in my
lifetime."
- Johnny Legend
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vlad_dumitrescu at hotmai |
| Posted: Sat Mar 22, 2003 9:52 pm |
|
|
|
Guest
|
Hi all,
First, I got a link from Vladimir Sekissov (thanks a lot!) for
something very close to what I in mind (but not as well-thought as in
the paper, of course). I wouldn't stop at just GUIs, however.
http://citeseer.nj.nec.com/gansner93multithreaded.html
From: "Chris Pressey" <cpressey_at_catseye.mb.ca>
> > What I'd like to be able to do is create a process by specifying
> > several interfaces/behaviours it will support, a GUI related example
> > might be for a button: I need let's say 'drawable', 'clickable',
> > 'mouse_over'. Just by naming them, I get the functionality,
>
> -module(my_button).
> -behaviour(drawable).
> -behaviour(clickable).
> -behaviour(mouse_over).
Not really, this means we have a module where we will have to
implement callbacks for all these behaviours. If 80% of those are just
delegating the work away, then I think it's a waste of effort. Also
you can't dynamically add/remove behaviours.
Also to Shawn: I agree that being able to see from the code what a
call will result in is good, but it is possible (and done) today too
to have a server holding a list of callbacks that clients have
registered - you can't know in the code which ones will be present at
runtime. I don't think it's a fundamental difference... Or one could
send a Fun to be called in another process - if that fun was received
from somewhere else, then it can't be traced without scanning the
whole system. I couldn't see any warning in the Programming Rules
about this...
Otherwise, Chris' and other's comments are pertinent and I mostly
agree (where I don't, it really is a matter of taste). I will repeat
that I don't think this suggestion I made is The True Solution (tm),
just like I don't think Erlang is perfect and will never need any
improvements.
One way that will probably please most, is the one Jay proposed first,
to use many simple cooperating processes (and this is also done in the
paper mentioned before). A remaining question is how to easily connect
together these processes so that they work as they should. I am
thinking about it.
BTW, a not directly related question: let's consider a process that
receives input (messages) and just dispatches them to a number of
registered clients. Is this okay to do? It's not possible to trace
where the messages go from just inspecting the code, but I think it is
a very useful functionality.
best regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| jay at duomark.com |
| Posted: Sun Mar 23, 2003 6:56 pm |
|
|
|
Guest
|
martin j logan wrote:
>This whole notion feels distinctly un-erlang. Erlang is simple,
>straight forward and fairly consistent, that is what makes it great.
...
>While the ideas that are expressed in this thread are quite
>interesting and have much merit I think that they would serve
>to undermine erlangs greatest strength - simplicity.
Eric Newhuis wrote:
>I agree.
I am interested in hearing what makes you say that. I am
wrestling with ideas and thinking out loud, so any reactions
are extremely helpful in reformulating my opinions.
I have proposed no change to the language and no change
to the way an erlang process operates. Where my goals differ from
Chris' goals is that I am new to having cheap, easy processes
and would like to exploit them to their fullest (he may already
be beyond that by a couple orders of magnitude in the number
of processes and is thinking of other things). I believe that
writing a very simple process, with almost no error checking,
has great advantage. I would rather waste processes than
waste programming time and effort struggling with the mundane
aspects of a program. I want to spend my time thinking of the
system level integration, throughput, distribution and limits
rather than which functional decomposition is correct.
My discussion centered on the communication mechanisms
among processes, considering these alternatives:
1) a <--> b <--> c <--> d <--> user
2)
a <---->|
b <---->| <--> d <--> user
c <---->|
where each of a, b, c and d are processes. I was proposing
that #2 is a richer model, #1 can be used on the back end of
a, b, and c, that a, b, and c can be dynamically added and
removed from d (consider that d is a UI textbox process and
that c is the 'editable' set of behaviours -- if it is not present the
textbox is not editable).
Vlad wrote:
>Potential problem: how to ensure that these behaviours do not
>have overlapping interfaces? (i.e. message tags or callback
>names that are the same)
This is a good and fundamental question that is right on the mark.
What I am trying to propose is a method for code reuse that does
not bind up discrete, rigid, pre-architected objects into a monolithic
application. Each process is closer to an abstract datatype than an
object (but I still refrain from making that assumption).
In my earlier post on uses of processes I mentioned:
>3) Code reuse / abstraction / adapting interfaces.
Process d in #2 above abstracts the gen_server interface to the
user. It *also* abstracts the gen_server interface to the backend
processes. a,b,c and have no higher level knowledge, d contains
higher level knowledge and that is why I correlated it to a supervisor
rather than a gen_server; it acts like a gen_server but it is init'ed
and controlled like a supervisor with dynamic children.
If any of the backend process have overlapping interfaces, the
task of building an instance of d includes interjecting 'shim'
processes to eliminate ambiguity in message passing. The
author of a,b,c cannot anticipate the places where they may
be used; the author of d does not have access to modify the
internals of a,b,c because that will break other code that relies
on them. Instead he might introduce a new process 'e' which
transforms messages coming from b and c so that they are not
ambiguous to d. This approach encourages having a,b,c do exactly
what they are intended to do and nothing more or nothing less,
without requiring d to introduce message disambiguation code which
detracts from algorithms d is really concerned with implementing.
e becomes one of your extremely simple erlang processes that
are easy to test and easy to see when they are not implemented
correctly (the process fails and communications break down).
The integrator rummages through the process toolbox and at
runtime declares which tools are bound together in which way
to get the desired results.
jay
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Mon Mar 24, 2003 3:20 am |
|
|
|
Guest
|
On Sun, 23 Mar 2003 10:50:42 -0800
Jay Nelson <jay_at_duomark.com> wrote:
> I have proposed no change to the language and no change
> to the way an erlang process operates. Where my goals differ from
> Chris' goals is that I am new to having cheap, easy processes
> and would like to exploit them to their fullest (he may already
> be beyond that by a couple orders of magnitude in the number
> of processes and is thinking of other things).
Nah, I've just got a wicked conservative streak (literally, not
politically) verging on Luddism - and a bad case of NIH ;)
No matter how cheap processes are, I'd just never feel quite right
modelling things that strike me as "really static" with them.
At the same time, I'm a big proponent of orthogonality - parts should
interchangeable, with general rules which have only as many exceptions as
truly necessary.
Same goes for simplicity - things should be as simple as possible, but *no
simpler* (or you'll lose something valuable.)
I have been having some problems following most of this thread lately
because it does seem to be getting rather involved and in danger of being
bogged down in minutiae. But, I probably just need to think about it
more; gimme a couple more days...
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| wuji |
| Posted: Fri Aug 24, 2012 8:08 am |
|
|
|
User
Joined: 10 Aug 2012
Posts: 654
|
m watch over the patient and provide support. When families families [h2]cheap polo shirts[/h2] families aren't worried, they don't do so well."Deeply Religious Parents
Reluctant to Cease Medical CareSome Religious Beliefs May Lead to to cheap polo shirts to Sick Kids' Receiving 'Futile' Care: StudyBy LIZ NEPORENT, ABC
Medical UnitAug. 14, 2012— Arthur Caplan, the head of the the cheap designer *beep* the division of medical ethics at NYU Langone Medical Center,
a case of a man who had beaten his six-month-old six-month-old cheap authentic air jordans six-month-old child to death. It was a horror the mother
could not accept.A deeply religious woman, she pushed the doctors doctors cheap polo shirts doctors to do more, telling them that God would intervene
all |
|
|
| Back to top |
 
|
|
|
All times are GMT
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum
|
|
|
Digg It
Del.icio.us
Reddit
Facebook
Stumble Upon
Technorati
