| Author |
Message |
|
| matthias at corelatus.se |
 Posted: Tue Apr 01, 2003 6:22 am |
 |
|
|
Guest
|
Hi,
Recently, there was some confusion on the list about the meaning of
"Defensive Programming" in the context of Erlang. For most
programmers, defensive programming is a good thing, yet in the Erlang
programming guidelines it is considered a bad thing. Therefore I've
renamed it to "micro-managed error handling" to make the author's
intent clearer. While doing that, I also tackled a number of similar
problems:
crash: again, in most languages crashing is bad whereas in Erlang it
confusingly enough becomes a good thing. The FAQ now refers
to such events as "inter-process exceptions (IPEs)"
single-assignment: is a very academic term for what most people
would call "const" variables. I have coined the replacement
term "auto-consting".
tail-recursion: very powerful feature. Ridiculously academic name.
Now called stack-unrolling.
process: thread. An process is very lightweight. The rest of the
world refers to lightweight processes as threads. So does the
Erlang FAQ from now on.
node: process. An Erlang node is always an OS process. So we may as
well call a spade a spade. "process" now means "erlang node".
behaviour: interface. In R9B-2, the directive '-public(gen_server).'
is a synonym for '-behaviour'. In R10, the -behaviour
directive will elicit a warning. By R11 an error.
list: array. Everyone knows what an array is.
Any further suggestions?
Matthias
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Tue Apr 01, 2003 6:53 am |
|
|
|
Guest
|
On Tue, 1 Apr 2003 08:22:09 +0200
Matthias Lang <matthias_at_corelatus.se> wrote:
> Hi,
>
> Recently, there was some confusion on the list about the meaning of
> "Defensive Programming" in the context of Erlang. For most
> programmers, defensive programming is a good thing, yet in the Erlang
> programming guidelines it is considered a bad thing. Therefore I've
> renamed it to "micro-managed error handling" to make the author's
> intent clearer.
That's probably a better way to put it.
Re-reading the programming guidelines - they do put "defensive" in
quotes. They also stress making code clearer by seperating the error
behaviour out. So you could even use the term "micro-managed, inline
error handling" to describe the bad stuff.
> While doing that, I also tackled a number of similar
> problems:
>
> crash: again, in most languages crashing is bad whereas in Erlang it
> confusingly enough becomes a good thing. The FAQ now refers
> to such events as "inter-process exceptions (IPEs)"
It's never a good thing. It's just that it's non-fatal here, for a
change. I'd say "non-fatal crash" and avoid the TLA.
> single-assignment: is a very academic term for what most people
> would call "const" variables. I have coined the replacement
> term "auto-consting".
>
> tail-recursion: very powerful feature. Ridiculously academic name.
> Now called stack-unrolling.
These two terms I had come across before I ever encountered Erlang. I
see no reason to change them; even if they are academic, they're an
accepted part of the parlance.
Google for "single assignment": ~15,000
Google for "auto consting": 0
Google for "tail recursion": ~15,000
Google for "stack unrolling": 22
> process: thread. An process is very lightweight. The rest of the
> world refers to lightweight processes as threads. So does the
> Erlang FAQ from now on.
>
> node: process. An Erlang node is always an OS process. So we may as
> well call a spade a spade. "process" now means "erlang node".
In the context of Erlang running under an operating system, OK.
In the context of Erlang running in an Erlang distribution, node is
still clearer.
> behaviour: interface. In R9B-2, the directive '-public(gen_server).'
> is a synonym for '-behaviour'. In R10, the -behaviour
> directive will elicit a warning. By R11 an error.
'interface' better describes how it actually acts (but what is the
reasoning behind '-public'? To me that says next to nothing.)
> list: array. Everyone knows what an array is.
And people don't know what [linked] lists are? :)
> Any further suggestions?
>
> Matthias
>
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| bjorn at erix.ericsson.se |
| Posted: Tue Apr 01, 2003 7:03 am |
|
|
|
Guest
|
Matthias Lang <matthias_at_corelatus.se> writes:
> Hi,
>
[...]
> behaviour: interface. In R9B-2, the directive '-public(gen_server).'
> is a synonym for '-behaviour'. In R10, the -behaviour
> directive will elicit a warning. By R11 an error.
>
> list: array. Everyone knows what an array is.
>
> Any further suggestions?
Actually, we think that Erlang being a functional language have
scared too many programmers, so we plan some radical changes.
The most significant change is that using the thread dictionary
(formerly known as the "process dictionary"), will no longer be
considered bad style.
To make the thread dictionary easier to use, we will add syntactic
sugar. Thus
var := Expr
is syntactic sugar for
put(var, Expr)
and in any expression
*var
is syntantic sugar for
get(var)
Although the ':=' is borrowed from Pascal rather than C, we still
think that C programmers will pick it up easily enough. Many C programmers
have used Turbo Pascal in the past.
put/2 and get/1 (or the syntatic sugar versions) will also be allowed
to be used in guards to extend the power of pattern matching.
We will of course also change the setelement/3 BIF to do a destructive
assignment. The syntactic sugar version will be
array_at_IndexExpr := Expr
The changes will be implemented in the R9D release, planned to be
released April 01, 2004.
/Bjorn
--
Bj |
|
|
| Back to top |
|
| mikael.karlsson at creado |
| Posted: Tue Apr 01, 2003 7:15 am |
|
|
|
Guest
|
Tue 01 april 2003 Matthias Lang wrote:
> Hi,
...
> process: thread. An process is very lightweight. The rest of the
> world refers to lightweight processes as threads. So does the
> Erlang FAQ from now on.
>
..
> Any further suggestions?
To me a thread is lightweight, but also share context/memory with other
threads. That is not the case for Erlang processes.
/Mikael
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| erlang at manderp.freeser |
| Posted: Tue Apr 01, 2003 7:16 am |
|
|
|
Guest
|
Oh dear, I only just got used to the existing terminology! (-:
Matthias Lang wrote:
> Hi,
>
> Recently, there was some confusion on the list about the meaning of
> "Defensive Programming" in the context of Erlang. For most
> programmers, defensive programming is a good thing, yet in the Erlang
> programming guidelines it is considered a bad thing. Therefore I've
> renamed it to "micro-managed error handling" to make the author's
> intent clearer. While doing that, I also tackled a number of similar
> problems:
>
> crash: again, in most languages crashing is bad whereas in Erlang it
> confusingly enough becomes a good thing. The FAQ now refers
> to such events as "inter-process exceptions (IPEs)"
... or just call them exceptions, IPE is just another TLA, and besides,
should it not be called "inter-thread exceptions" according to what follows?
> single-assignment: is a very academic term for what most people
> would call "const" variables. I have coined the replacement
> term "auto-consting".
... or just const, C++ programmers can relate to this concept.
Single-assignment may be an academic term, but it is an exact description.
> tail-recursion: very powerful feature. Ridiculously academic name.
> Now called stack-unrolling.
I agree, stack unrolling describes what is going on here. If only other
languages did this, it would make things a lot more legible. It's not
difficult to do or understand after all!
> process: thread. An process is very lightweight. The rest of the
> world refers to lightweight processes as threads. So does the
> Erlang FAQ from now on.
See above about "inter-process exceptions (tm)"
> node: process. An Erlang node is always an OS process. So we may as
> well call a spade a spade. "process" now means "erlang node".
Hmm... I feel the term "node" is less generic than "process" which is
used/abused everywhere, and reusing an existing term for a different
meaning can only be confusing.
> behaviour: interface. In R9B-2, the directive '-public(gen_server).'
> is a synonym for '-behaviour'. In R10, the -behaviour
> directive will elicit a warning. By R11 an error.
>
> list: array. Everyone knows what an array is.
Yes, but a list is not an array. For one, Erlang lists don't encourage
the use of indexes. And arrays don't lend themselves to [Head|Tail]
manipulation in any other language I know. I would personally stick to
"list".
> Any further suggestions?
>
> Matthias
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| enano at fi.udc.es |
| Posted: Tue Apr 01, 2003 8:20 am |
|
|
|
Guest
|
Ahm... is there a way to tell the erlang.org majordomo to postpone
that post until December 28 for us spanish users? :-)
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| jonathan at meanwhile.fre |
| Posted: Tue Apr 01, 2003 9:24 am |
|
|
|
Guest
|
> tail-recursion: very powerful feature. Ridiculously academic name.
> Now called stack-unrolling.
>
> process: thread. An process is very lightweight. The rest of the
> world refers to lightweight processes as threads. So does the
> Erlang FAQ from now on.
Doesn't the argument for using standard names apply just as much to
tail-recursion as to threads?
- Jonathan Coupe
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| tony at rogvall.com |
| Posted: Tue Apr 01, 2003 9:27 am |
|
|
|
Guest
|
Bjorn Gustavsson wrote:
> Matthias Lang <matthias_at_corelatus.se> writes:
>
>
> Actually, we think that Erlang being a functional language have
> scared too many programmers, so we plan some radical changes.
>
Now you'r talking, I have always thought of the OTP team being a bit
conservative.
> The most significant change is that using the thread dictionary
> (formerly known as the "process dictionary"), will no longer be
> considered bad style.
>
But why wait a year for this release here is a working patch!!!
to patch just do:
cd <otp-r9b-1-path>
patch -p1 < otp_src_R9B-1.diff
enjoy
I implemented a feature in erl_eval that can be used from command line
_ := expr will band the expr to the current process
and
*_ will receive the first message in the queue
Perhaps some one could fix so the compiler will generate the code as well.
You can see a small example in vexpr.erl. We must add something to pass
variables as references to other functions i.e.
foo() ->
X := 1,
bar(&X).
bar(Y) ->
Y := *Y + 1. %% will update the instance of X!!!
Regards
/Tony
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| vlad_dumitrescu at hotmai |
| Posted: Tue Apr 01, 2003 11:07 am |
|
|
|
Guest
|
From: "Bjorn Gustavsson" <bjorn_at_erix.ericsson.se>
> To make the thread dictionary easier to use, we will add syntactic
> sugar. Thus
> var := Expr
> is syntactic sugar for
> put(var, Expr)
> and in any expression
> *var
> is syntantic sugar for
> get(var)
Hi,
This is a most wonderful idea! What a world of possibilities suddenly opens!
I now realize that this is just what I had been expecting!
I hope this will be just one step on the way to making the language easily
accepted by all programmes in the world. The release after that (i.e the one
that will reach general audience April 1, 2005) should include some other
"most wanted" features:
- remove message passing, and use function calls instead
- introduce a new type of data, namely pointer, so that we can access C data
directly
- without messages, processes are quite useless, so skip them too
- make Erang hard-realtime, and remove garbage collection; replace it with
something like (I'm just improvising now) memory_alloc() and memory_free(),
or shorter malloc and free
- pattern matching is very awkward, I think it would be much cleaner to
define functions as for example foo(int x, string baz)
I could continue, but I have to catch my breath and put my thoughts in
order. Wow!
best regards,
Vlad
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| Marc.Vanwoerkom at FernUn |
| Posted: Tue Apr 01, 2003 11:24 am |
|
|
|
Guest
|
> renamed it to "micro-managed error handling" to make the author's
> intent clearer.
You got me hooked for some minutes 
Ah andI was already looking for such.
Regards,
Marc
PS Another one:
http://www.javaperformancetuning.com/news/interview028.shtml
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| etxuwig at etxb.ericsson. |
| Posted: Tue Apr 01, 2003 12:26 pm |
|
|
|
Guest
|
On 1 Apr 2003, Bjorn Gustavsson wrote:
>Actually, we think that Erlang being a functional language
>have scared too many programmers, so we plan some radical
>changes.
And about time too! I've suffered through 11 years of
traditional erlang programming waiting for this!
>The most significant change is that using the thread
>dictionary (formerly known as the "process dictionary"),
>will no longer be considered bad style.
Wonderful!
>To make the thread dictionary easier to use, we will add
>syntactic sugar. Thus
>
> var := Expr
>
>is syntactic sugar for
>
> put(var, Expr)
>
>and in any expression
>
> *var
>
>is syntantic sugar for
>
> get(var)
>
>Although the ':=' is borrowed from Pascal rather than C, we
>still think that C programmers will pick it up easily
>enough. Many C programmers have used Turbo Pascal in the
>past.
Ah, good old Turbo Pascal. The first programming tool I ever
owned...
Of course, since := and *var will be considered good style,
we could also spend some time optimizing the process (sorry
- thread) dictionary with the help of the compiler. The
compiler could recognize hard-coded process (darn - thread)
dictionary keys and represent them as real global variables.
This will allow use of the (uugh) thread dictionary without
any overhead, and we suddenly have true desctructive
assignment! (: (: (:
/Uffe
--
Ulf Wiger, Senior Specialist,
/ / / Architecture & Design of Carrier-Class Software
/ / / Strategic Product & System Management
/ / / Ericsson AB, Connectivity and Control Nodes
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| joe at sics.se |
| Posted: Tue Apr 01, 2003 1:10 pm |
|
|
|
Guest
|
On Tue, 1 Apr 2003, Ulf Wiger wrote:
> On 1 Apr 2003, Bjorn Gustavsson wrote:
>
> >Actually, we think that Erlang being a functional language
> >have scared too many programmers, so we plan some radical
> >changes.
>
> And about time too! I've suffered through 11 years of
> traditional erlang programming waiting for this!
...
Another improvement - which I've long awaited is to remove send and
receive (since they are redundant) - the enclosed code shows how to
send a message between two processes *without* using send and receive.
Here's a trace
1> c(send).
{ok,send}
12> send:demo(hello).
Sending :hello to <0.70.0>
<0.70.0>: received:hello
Observe that no send or receive is used only the more intuitively
understandable method of remote polling of the process dictionary with
process_info(Pid, dictionary) -
Unfortunately this code has a busy wait - so we'll have to ask Bj |
|
|
| Back to top |
|
| paf at dei.isep.ipp.pt |
| Posted: Tue Apr 01, 2003 1:54 pm |
|
|
|
Guest
|
>Hi,
....................................
>Any further suggestions?
>
>Matthias
>
How about:
Crash: expansive way of comunicating EWOC
Single-assignment: careful non-perturbating of other values assignment CNOVA
process: micro autonomous independent entity MAIE
 ;-)
On other topic, GUIs, a good thought provoking book is "The Humane
Interface" by Jef Raskin, http://www.jefraskin.com
Greetings
Paulo Ferreira
------------------------------------------------
Paulo Ferreira paf_at_dei.isep.ipp.pt
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| jamesh at Volition-inc.co |
| Posted: Tue Apr 01, 2003 2:54 pm |
|
|
|
Guest
|
Additionally, I'd like to replace the term "functional" with "useful."
After all, what's the point of a non-functional program? And just stating
that a program is functional is the same as saying that it works, which is
rather neutral. But if you said "useful programming," then managers will be
all over it.
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
| cpressey at catseye.mb.ca |
| Posted: Tue Apr 01, 2003 3:08 pm |
|
|
|
Guest
|
On Tue, 1 Apr 2003 08:22:09 +0200
Matthias Lang <matthias_at_corelatus.se> wrote:
> behaviour: interface. In R9B-2, the directive '-public(gen_server).'
> is a synonym for '-behaviour'. In R10, the -behaviour
> directive will elicit a warning. By R11 an error.
Ah, well now that I've SLEPT on it, now that it's early this morning
rather than late nast night in my timezone, this makes PERFECT sense and
I withdraw all my previous objections.
Might I also say that I'm quite pleased to hear of Ericsson's decision
to hire Vin Diesel and Avril Lavigne as spokespersons for Open Source
Erlang. At long last, this project will get the respect it deserves!
-Chris
Post generated using Mail2Forum (http://m2f.sourceforge.net) |
|
|
| Back to top |
|
|
|
All times are GMT
Page 1 of 4
Goto page 1, 2, 3, 4 Next
|
|
|
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
