[erlang-questions] process dictionary, anyone?

[unknown]

Each self-respecting Erlang hacker should bash the
process dictionary now and again. I've made it a sport to
claim that it is no worse than ets.

Considering SMP Erlang, isn't it even significantly better?
I haven't experimented with the process dictionary on
SMP machines, but it is process local, and can only be
written to by the process, so it should require much less
locking than ets, right?

A drawback with the process dictionary, compared to
ets, is that it has no support for match operations (other
than get() and get_keys()). When inspecting it from another
process (which is good for debugging purposes), it only
allows you to retrieve the entire dictionary.

Both these drawbacks could be easily corrected - at least
the second one.

BR,
Ulf W
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070423/a0c8f7e0/attachment.html>

[unknown]

I think the process dictionary is unfairly maligned. Having
per-process globals is a _good_ thing. It can make code simpler and
more maintainable in specific situations. Now I'd just like some
syntactic sugar to make them easier to use and to give the illusion of
having dead simple hash table / dictionary support in Erlang :)

James

[unknown]

Trouble is that it breaks the functional part of the language. Now that
is only really done in process dictionary, processes/message, ports and
ets. Though both ets and ports can be considered as processes/messages
and can be implemented as such though a bit less efficiently.

So globals variables in the process dictionary is not really a Good
Thing. Using them as settable constants would be perhaps ok. How about
having them as variables and only be set-once?

Robert

Post by unknown
I think the process dictionary is unfairly maligned. Having
per-process globals is a _good_ thing. It can make code simpler and
more maintainable in specific situations. Now I'd just like some
syntactic sugar to make them easier to use and to give the illusion of
having dead simple hash table / dictionary support in Erlang :)
James
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions

[unknown]

Module scoped single assignment per-process variables doesn't sound
like a terrible idea... but I have no idea what I'd use them for :) I
think most uses of the process dictionary are probably not single
assignment.

-bob

Post by unknown
Trouble is that it breaks the functional part of the language. Now that
is only really done in process dictionary, processes/message, ports and
ets. Though both ets and ports can be considered as processes/messages
and can be implemented as such though a bit less efficiently.
So globals variables in the process dictionary is not really a Good
Thing. Using them as settable constants would be perhaps ok. How about
having them as variables and only be set-once?
Robert

Post by unknown
I think the process dictionary is unfairly maligned. Having
per-process globals is a _good_ thing. It can make code simpler and
more maintainable in specific situations. Now I'd just like some
syntactic sugar to make them easier to use and to give the illusion of
having dead simple hash table / dictionary support in Erlang :)
James
_______________________________________________
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

[unknown]

In my (admittedly brief) experience - process dictionaries tend to be
used as a method of making processes more like "objects" (in the OO
sense of the word). The process dictionary is used to store state, with
messages being the way one calls the objects "member functions". All
things considered, this "could" be done using the standard functional
methods but is probably done this way for efficiency (I, at least,
assume process dictionaries are faster than standard Erlang implemented
dictionaries).

I have been seriously considering using them for this purpose in my own
code, but have not yet weighed up the pros & cons (efficiency vs "pure
functional").

Regards,
B.J.Tolputt

Post by unknown
Module scoped single assignment per-process variables doesn't sound
like a terrible idea... but I have no idea what I'd use them for :) I
think most uses of the process dictionary are probably not single
assignment.
-bob

Post by unknown
Trouble is that it breaks the functional part of the language. Now that
is only really done in process dictionary, processes/message, ports and
ets. Though both ets and ports can be considered as processes/messages
and can be implemented as such though a bit less efficiently.
So globals variables in the process dictionary is not really a Good
Thing. Using them as settable constants would be perhaps ok. How about
having them as variables and only be set-once?
Robert

Post by unknown
I think the process dictionary is unfairly maligned. Having
per-process globals is a _good_ thing. It can make code simpler and
more maintainable in specific situations. Now I'd just like some
syntactic sugar to make them easier to use and to give the illusion of
having dead simple hash table / dictionary support in Erlang :)
James
_______________________________________________
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

_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
Trouble is that it breaks the functional part of the language. Now that
is only really done in process dictionary, processes/message, ports and
ets.

so erlang is functional, except for the process dictionary, messages, ports
and ets? then perhaps it's time to stop pretending it's functional?

mats

[unknown]

Post by unknown
so erlang is functional, except for the process dictionary, messages, ports
and ets? then perhaps it's time to stop pretending it's functional?

Nobody pretends that Erlang classes as a purely declarative
language, and arguing that it doesn't class as functional
would have you question Scheme and O'Caml, which share
that classification. I'd say that Erlang 'is functional' the
Java or Ruby 'are imperative', but that people write Erlang
in a concurrency oriented style.

And if everyone stops pretending, how will anyone explain data
structures like 'queue', straight out of Purely Functional Data
Structures? :-)

Cheers,
Julian

[unknown]

To a first approximation, the process dictionary can be regarded as
a functional feature. Replace
X = f(Y, Z)
by
{X,NewDict} = f(Y, Z, OldDict)
systematically. The main thing is that (unlike SML and CAML, for
example, which have genuinely mutable data structures), keys and
values in the process dictionary are not themselves mutable.

(Techniques for mapping imperative style to declarative style can
be found in The Craft of Prolog, cribbed from a paper about how to
verify Fortran code using the Boyer-Moore (Lisp) theorem prover.)

[unknown]

Post by unknown
so erlang is functional, except for the process dictionary, messages, ports
and ets? then perhaps it's time to stop pretending it's functional?

Be hip and modern and call it "multi-paradigm" :)

[unknown]

Strange viewpoint!

Ets and ports easily map onto processes/messages so except for the
process dictionary there is really only one non-functional feature today
and that is just processes/messages. And the process dictionary. So
who's pretending? And why purposefully try to defeat the benefits that a
functional language has? We might as well then just add erlang like
processes to Java and be done with.

That being said I have actually found a place where the process
dictionary is useful and has no direct replacement. That is in yecc! As
it is today there is no state which is passed around with the RHSs of
the rules so it difficult to do much except just build a parse tree. If
instead you want to do something there it is difficult without the
process dictionary to pass around a state.

Of course you always have the option of first building the parse tree
and then traversing again to do what has to be done. But that seems so
*negative*. :-) Fix a new version of yecc which passes a state around.
Leex has the smae problem.

Robert

Post by unknown

Post by unknown
Trouble is that it breaks the functional part of the language. Now that
is only really done in process dictionary, processes/message, ports and
ets.

so erlang is functional, except for the process dictionary, messages, ports
and ets? then perhaps it's time to stop pretending it's functional?
mats
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions

[unknown]

You can represent any non-functional construct with message passing. A
side-effect is a side-effect... Erlang is clearly a hybrid language,
but it has a very useful subset that is purely functional. Much of
what I've read in the standard library is written in that purely
functional subset, and the syntax and features of the language/VM seem
like they're designed to encourage and support mostly that subset.

Using the process dictionary is a great little hack that saves you
from refactoring a bunch of code to include an extra state variable...

-bob

Post by unknown
Strange viewpoint!
Ets and ports easily map onto processes/messages so except for the
process dictionary there is really only one non-functional feature today
and that is just processes/messages. And the process dictionary. So
who's pretending? And why purposefully try to defeat the benefits that a
functional language has? We might as well then just add erlang like
processes to Java and be done with.
That being said I have actually found a place where the process
dictionary is useful and has no direct replacement. That is in yecc! As
it is today there is no state which is passed around with the RHSs of
the rules so it difficult to do much except just build a parse tree. If
instead you want to do something there it is difficult without the
process dictionary to pass around a state.
Of course you always have the option of first building the parse tree
and then traversing again to do what has to be done. But that seems so
*negative*. :-) Fix a new version of yecc which passes a state around.
Leex has the smae problem.
Robert

Post by unknown

Post by unknown
Trouble is that it breaks the functional part of the language. Now that
is only really done in process dictionary, processes/message, ports and
ets.

so erlang is functional, except for the process dictionary, messages, ports
and ets? then perhaps it's time to stop pretending it's functional?
mats
_______________________________________________
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

[unknown]

Hi !

I think most of us has used put/get at some point.
It will ALWAYS hit you back. You will spend hours trying to locate
the place
where things went wrong. I do use put/get and I think you will too.
But it's NOT a great little hack it's a disease.

Happy hacking

/Tony

Post by unknown
You can represent any non-functional construct with message passing. A
side-effect is a side-effect... Erlang is clearly a hybrid language,
but it has a very useful subset that is purely functional. Much of
what I've read in the standard library is written in that purely
functional subset, and the syntax and features of the language/VM seem
like they're designed to encourage and support mostly that subset.
Using the process dictionary is a great little hack that saves you
from refactoring a bunch of code to include an extra state variable...
-bob

[unknown]

Post by unknown
Hi !
I think most of us has used put/get at some point.
It will ALWAYS hit you back. You will spend hours trying to locate
the place
where things went wrong. I do use put/get and I think you will too.
But it's NOT a great little hack it's a disease.

Well spoken Tony!

To all Erlang newbee's: stay away from the process dicts!
In fact, try to stay away from any destructive operation.

After 15 years of Erlang hacking I almost never use the proc.dict
(perhaps once every third year or so...:-)

Cheers, Tobbe

Post by unknown
Happy hacking
/Tony

Post by unknown
You can represent any non-functional construct with message passing. A
side-effect is a side-effect... Erlang is clearly a hybrid language,
but it has a very useful subset that is purely functional. Much of
what I've read in the standard library is written in that purely
functional subset, and the syntax and features of the language/VM seem
like they're designed to encourage and support mostly that subset.
Using the process dictionary is a great little hack that saves you
from refactoring a bunch of code to include an extra state variable...
-bob

[unknown]

Post by unknown
Hi !
I think most of us has used put/get at some point.
It will ALWAYS hit you back. You will spend hours trying to

locate the

Post by unknown
place where things went wrong. I do use put/get and I think

you will

Post by unknown
too.
But it's NOT a great little hack it's a disease.

Well spoken Tony!
To all Erlang newbee's: stay away from the process dicts!
In fact, try to stay away from any destructive operation.
After 15 years of Erlang hacking I almost never use the
proc.dict (perhaps once every third year or so...:-)

I agree that it's easy to abuse the process dictionary,
but I can't see that using ets is any better. So the
advice should be to avoid certain programming patterns.

Most importantly, don't sprinkle side-effects all over
your code, but try keep as much of your code as
possible side-effect free.


Comparing the process dictionary an ets, there are
pros and cons with each:

- process dictionary is a linear hash table, like
ets sets (but not exactly the same implementation)

- there's no copying when accessing the process
dictionary, but then again, there is GC. With ets,
it's the other way around. (We have code where the
process heap is sized so that all garbage of
short-lived processes fits on the heap. This means
no copying - no GC).

- ets tables can be made to survive a process crash
(by making some other process the owner). This can
be a good thing, but forces you to use public ets
tables (bad thing). I believe most ets tables in
use are public, which in a sense makes them worse
than the process dictionaries.

- On a few occasions, it is actually useful to let
several processes write to the same ets table,
but in most cases where it's contemplated, it's
a very bad idea.

- The contents of the process dictionary is included
in crash reports, while the contents of ets tables
are automatically wiped out when the owner dies -
bad for debugging, unless you make another process
the owner, and make the table public, so you can
write to it (which means everyone else can write
to it too - bad)

- Of course, storing huge amounts of data in the
proc dict is bad because (a) it's GC:d, and
(b) all the data is dumped into the SASL crash
reports, which are (by default) pretty-printed
to the tty - potential diaster.

- ets has much better search and fold facilities
(the process dictionary has practically none).

- Allowing many processes to write from an ets
table _can_ be very useful. This could be done
with the process dictionary as well, but at
the moment, the only option available is to
read the entire dictionary at once (through
process_info(P, dictionary). This involves
a copy, btw, just like with ets.

In short, I'd say that the process dictionary is
no worse than any other kind of side-effect, but
has some fairly unique advantages as well.

BR,
Ulf W

-----Original Message-----
From: erlang-questions-bounces
[mailto:erlang-questions-bounces] On Behalf Of
Torbjorn Tornkvist
Sent: den 30 april 2007 10:12
To: erlang-questions
Subject: Re: [erlang-questions] process dictionary, anyone?

Post by unknown
Hi !
I think most of us has used put/get at some point.
It will ALWAYS hit you back. You will spend hours trying to

locate the

Post by unknown
place where things went wrong. I do use put/get and I think

you will

Post by unknown
too.
But it's NOT a great little hack it's a disease.

Well spoken Tony!
To all Erlang newbee's: stay away from the process dicts!
In fact, try to stay away from any destructive operation.
After 15 years of Erlang hacking I almost never use the
proc.dict (perhaps once every third year or so...:-)
Cheers, Tobbe

Post by unknown
Happy hacking
/Tony

Post by unknown
You can represent any non-functional construct with

message passing.

Post by unknown

Post by unknown
A side-effect is a side-effect... Erlang is clearly a hybrid
language, but it has a very useful subset that is purely

functional.

Post by unknown

Post by unknown
Much of what I've read in the standard library is written in that
purely functional subset, and the syntax and features of the
language/VM seem like they're designed to encourage and

support mostly that subset.

Post by unknown

Post by unknown
Using the process dictionary is a great little hack that saves you
from refactoring a bunch of code to include an extra state

variable...

Post by unknown

Post by unknown
-bob

_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
I agree that it's easy to abuse the process dictionary,
but I can't see that using ets is any better. So the
advice should be to avoid certain programming patterns.
Most importantly, don't sprinkle side-effects all over
your code, but try keep as much of your code as
possible side-effect free.
Comparing the process dictionary an ets, there are

Snip lots of good differences.

Post by unknown
In short, I'd say that the process dictionary is
no worse than any other kind of side-effect, but
has some fairly unique advantages as well.

I'd say you missed one very important difference, which is that the
process dictionary is "just there" waiting to be (ab)used, whereas an
ets table must be explicitly created before use. My guess is that
this difference leads to the typically very different uses people put
the two mechanisms to.

To use an ets table you must have a convenient place to create it,
which typically means the init function of a gen_server, which leads
to typical use - extra state for a process, no worse than updating
the State record, but with fast access for large data sets.

The process dictionary OTOH can be used much more conveniently in
what would be otherwise pure library code, relying on the existence
of the process dictionary in whatever random process calls it. This
would be the "handy hack for not re-factoring" mode which is almost
always bad.

Another important difference is that ets tables are limited in
quantity. Using ets in "handy hack" mode can easily take down the
node - one new ets table for each time the function is called.

BR,
Sean

Post by unknown
BR,
Ulf W

-----Original Message-----
From: erlang-questions-bounces
[mailto:erlang-questions-bounces] On Behalf Of
Torbjorn Tornkvist
Sent: den 30 april 2007 10:12
To: erlang-questions
Subject: Re: [erlang-questions] process dictionary, anyone?

Post by unknown
Hi !
I think most of us has used put/get at some point.
It will ALWAYS hit you back. You will spend hours trying to

locate the

Post by unknown
place where things went wrong. I do use put/get and I think

you will

Post by unknown
too.
But it's NOT a great little hack it's a disease.

Well spoken Tony!
To all Erlang newbee's: stay away from the process dicts!
In fact, try to stay away from any destructive operation.
After 15 years of Erlang hacking I almost never use the
proc.dict (perhaps once every third year or so...:-)
Cheers, Tobbe

Post by unknown
Happy hacking
/Tony

Post by unknown
You can represent any non-functional construct with

message passing.

Post by unknown

Post by unknown
A side-effect is a side-effect... Erlang is clearly a hybrid
language, but it has a very useful subset that is purely

functional.

Post by unknown

Post by unknown
Much of what I've read in the standard library is written in that
purely functional subset, and the syntax and features of the
language/VM seem like they're designed to encourage and

support mostly that subset.

Post by unknown

Post by unknown
Using the process dictionary is a great little hack that saves you
from refactoring a bunch of code to include an extra state

variable...

Post by unknown

Post by unknown
-bob

_______________________________________________
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

[unknown]

This has become an ideological debate adding very little (if at all) value.
Like it or not, process dictionary is part of ERLANG environment, and IMHO,
it is better if it stay that way.
I do not use process dictionary extensively(*), but I'm glad to have an
option to do so.
If you think differently, you also have an option -- not to use it.
Talking about four legs being good and two even better, does not help
anyone.

V.

(*) Sometime it is handy to have it as a private storage, however, one
should not use process dictionary without planning. IMHO, that's the time
when its usage will lend you in trouble.

[unknown]

Post by unknown
Ets and ports easily map onto processes/messages so except
for the process dictionary there is really only one
non-functional feature today and that is just
processes/messages. And the process dictionary.

What is it about the process dictionary that cannot
be mapped onto processes/messages?

Eshell V5.5.3.1 (abort with ^G)
1> c(pdict).
{ok,pdict}
2> pdict:init().
<0.45.0>
3> put(a,1).
undefined
4> put(a,2).
1
5> put(b,3).
undefined
6> get().
[{b,3},{a,2}]
7> put(c,3).
undefined
8> get_keys(3).
[c,b]
9> pdict:put(a,1).
undefined
10> pdict:put(a,2).
1
11> pdict:put(b,3).
undefined
12> pdict:put(c,3).
undefined
13> pdict:get_keys(3).
[c,b]
14> erase(a).
2
15> pdict:erase(a).
2
16> get().
[{c,3},{b,3}]
17> pdict:get().
[{c,3},{b,3}]

Not claiming that this is a particularly good
implementation of the process dictionary, but it
does illustrate compatible behaviour.

It's in fact *easier* to model the process dictionary
with processes and messages than it is to model ets
(partly because the ets interface is broader, but also
due to named tables, reentrant matching, tab2file(),
access flags, etc.)

Ets is dirtier and encourages unsafe get/put programming
to a far greater extent than the process dictionary.


BR,
Ulf W
-------------- next part --------------
A non-text attachment was scrubbed...
Name: pdict.erl
Type: application/octet-stream
Size: 2007 bytes
Desc: pdict.erl
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20070430/fbba1b79/attachment.obj>

[unknown]

Post by unknown

Post by unknown

Post by unknown
Trouble is that it breaks the functional part of the language. Now
that is only really done in process dictionary, processes/message,
ports and ets.

so erlang is functional, except for the process dictionary,
messages, ports and ets? then perhaps it's time to stop pretending
it's functional?

Strange viewpoint!

what i find strange is the viewpoint that no features should be added unless
they are functional. with that line of reasoning message passing should never
have been added either, which would somewhat limit the usefulness of the language.

Post by unknown
We might as well then just add erlang like processes to Java and be done with.

i'm convinced that soon enough a java-like language (javascript?) will
incorporate erlang-style processes/message passing. and then erlang will, i
fear, indeed be done.
C.f. http://steve-yegge.blogspot.com/2007/02/next-big-language.html

mats

[unknown]

Post by unknown

Post by unknown
We might as well then just add erlang like processes to Java and be done with.

i'm convinced that soon enough a java-like language (javascript?) will
incorporate erlang-style processes/message passing. and then erlang will, i
fear, indeed be done.
C.f. http://steve-yegge.blogspot.com/2007/02/next-big-language.html

Scala almost does - their actors library is actually modeled after
Erlang's processes. The "only" missing part is a runtime to actually
give the same characteristics as the beam runtime. [the quotes are
meaning that I am aware that it would be a huge undertaking; but given
the increasing incentives to deliver such a beast, I'd say it may not
be too far away in the future]

I wonder what would be easier: to port the Erlang runtime to the JVM,
or to write a compiler for a Java-like language targeting the beam
runtime?

regards,
Vlad

[unknown]

Post by unknown
Trouble is that it breaks the functional part of the
language. Now that is only really done in process
dictionary, processes/message, ports and ets. Though
both ets and ports can be considered as processes/messages
and can be implemented as such though a bit less efficiently.

And the process dictionary could be implemented with processes
and messages too, although a bit less efficiently.

Post by unknown
So globals variables in the process dictionary is not
really a Good Thing. Using them as settable constants
would be perhaps ok. How about having them as variables
and only be set-once?

The most common users of the process dictionary in OTP are
proc_lib and mnesia. Proc_lib inserts observable properties
in the process dictionary, and these are never changed.
They are used mainly for debugging and error reporting.

Mnesia inserts a transaction identifier in the process
dictionary, and this Tid lives for the duration of the
transaction. It has dynamic parts, and is modified/
extended if nested transactions are started.


Addressing these two needs will probably get you
pretty far.

Personally, I'm intrigued by the proc_lib aspect.
I've spent some time thinking about how one would
go about debugging systems with several hundred
thousand, or millions of, processes. Clearly,
introspection functions that begin with calling
processes() are not going to be that useful - nor
functions that pretty-print all meta data for all
processes in the system. I'm leaning towards having
a central process dictionary index, where selected
entries in the process dictionary could be indexed.
This could then be used to find processes sharing
a common trait.

BR,
Ulf W

[unknown]

Post by unknown
The most common users of the process dictionary in OTP are
proc_lib and mnesia. Proc_lib inserts observable properties
in the process dictionary, and these are never changed.
They are used mainly for debugging and error reporting.

Also, the 'random' module inserts random_seed in the caller's
process dictionary.

Quoting myself from three days ago, elsewhere:

These classified-as-functional languages also have mutable
state: Haskell -- protected by scary names; Mercury --
protected by a notion of purity, semipurity, and impurity;
Erlang -- protected by sometimes irrational aversion.

Where 'sometimes irrational' linked to an earlier thread on
this list:

http://news.gmane.org/find-root.php?message_id=%3c461E348F.3090608%40cs.ntua.gr%3e

Cheers,
Julian

[unknown]

Post by unknown
Also, the 'random' module inserts random_seed in the caller's
process dictionary.

.. and has anyone else noticed how fun it is that by default each
process's random-seed is initialized from a constant?

Just a couple of months ago I spawned a dozen processes each behaving
"randomly" and was quite amused when they all did exactly the same
thing :-)

[unknown]

I noticed that too, and indeed it was very fun for me too :)

I ended up switching over to using the random engine in the crypto module
instead. Is that what you did?

jon

Post by unknown

Post by unknown
Also, the 'random' module inserts random_seed in the caller's
process dictionary.

.. and has anyone else noticed how fun it is that by default each
process's random-seed is initialized from a constant?
Just a couple of months ago I spawned a dozen processes each behaving
"randomly" and was quite amused when they all did exactly the same
thing :-)
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
I noticed that too, and indeed it was very fun for me too :)
I ended up switching over to using the random engine in the crypto module
instead. Is that what you did?

I used random:seed(now()).

[unknown]

I don't want to say it but RTFM. It's documented as well as how you
initialise the seed. The algorithm used is quite good but not at all
suitable for cryptography.

Robert

Post by unknown
I noticed that too, and indeed it was very fun for me too :)
I ended up switching over to using the random engine in the crypto module
instead. Is that what you did?
jon

Post by unknown

Post by unknown
Also, the 'random' module inserts random_seed in the caller's
process dictionary.

.. and has anyone else noticed how fun it is that by default each
process's random-seed is initialized from a constant?
Just a couple of months ago I spawned a dozen processes each behaving
"randomly" and was quite amused when they all did exactly the same
thing :-)
_______________________________________________
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

[unknown]

Post by unknown
I don't want to say it but RTFM. It's documented as well as how you
initialise the seed. The algorithm used is quite good but not at all
suitable for cryptography.

Since you did say it :-) I checked TFM and it's not helpful.

Most people calling random:uniform/1 will want a randomish number,
like e.g. 'head -c 1 /dev/random' on Linux. This should be easy.

TFM doesn't explain how to do this. If you read carefully you see that
you need to provide your own seed but there's no hint how to get one.

Here is the way I've learned to get a "random enough that the
programmer can't guess the answer" number:

{A,B,C} = now(),
random:seed(A,B,C),
random:uniform(N)

but that's from grep'ing around to see how Tony and Klacke do it.

Possibly the referenced article in the 1982 Journal of Applied
Statistics has an excellent explanation of how to produce your own
seed and virtue of the constant provided by seed0(), but seriously!

[unknown]

Post by unknown
...
Here is the way I've learned to get a "random enough that the
{A,B,C} = now(),
random:seed(A,B,C),

The potential problems with this are obvious... aren't they?

--T

Post by unknown
random:uniform(N)
but that's from grep'ing around to see how Tony and Klacke do it.

...

[unknown]

--- Mats Cronqvist <mats.cronqvist>

Post by unknown

Post by unknown
Trouble is that it breaks the functional part of

the language. Now that

Post by unknown
is only really done in process dictionary,

processes/message, ports and

Post by unknown
ets.

so erlang is functional, except for the process
dictionary, messages, ports
and ets? then perhaps it's time to stop pretending
it's functional?

Erlang also uses message passing, except for ets, dets
and mnesia. So let's just stop this sick pretense,
shall we? Erlang is really an imperative,
shared-memory language.

Best,
Thomas

PS. And I for one welcome our new object-oriented
masters.

PPS. Maybe it wouldn't have been banned if we had
thought of this in the first place? Dang.

__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

[unknown]

Post by unknown

Post by unknown
Trouble is that it breaks the functional part of

the language. Now that

Post by unknown
is only really done in process dictionary,

processes/message, ports and

Post by unknown
ets.

so erlang is functional, except for the process dictionary, messages, ports
and ets? then perhaps it's time to stop pretending it's functional?

Erlang also uses message passing, except for ets, dets and mnesia. So let's
just stop this sick pretense, shall we? Erlang is really an imperative,
shared-memory language.

my point was that for lots of people, the key features of erlang are the
non-functional bits.

using the argument that something is bad because it "breaks the functional
part of the language" is bogus. it's the (clever) broken-ness that makes it good
to begin with. obviously, this does not mean that the opposite (everything that
breaks the functional part is good) is true.

PS. And I for one welcome our new object-oriented masters.

right on! time to cut your hair and get a real job writing "public static
final void"
200 times a day.

PPS. Maybe it wouldn't have been banned if we had thought of this in the
first place? Dang.

getting banned by ericsson should be considered a stamp of approval...
but sadly you're probably correct. i think the lack of OO, along with the
prolog-y syntax, were key factors in the ban (not that anyone would admit it).

mats

[unknown]

Post by unknown

Post by unknown
PPS. Maybe it wouldn't have been banned if we had
thought of this in the first place? Dang.

getting banned by ericsson should be considered
a stamp of approval...

I don't know about that, but there's nothing like
a few mortal challenges now and then to force you
to step up and really give it your best. (:
I would wager that the ban was actually good for Erlang.

It is certainly so that since Erlang hasn't been
mainstream, and at times has been rather fiercely
opposed, there has never been much room for anything
but excellence.

BR,
Ulf W

[unknown]

Post by unknown

Post by unknown
I don't want to say it but RTFM. It's documented as well as how you
initialise the seed. The algorithm used is quite good but not at all
suitable for cryptography.

Since you did say it :-) I checked TFM and it's not helpful.

Helpful or not, it does describe everything that people claimed to be
ignorant of so far in this thread.

Post by unknown
Most people calling random:uniform/1 will want a randomish number,

Did you take a survey?:-) In fact it's a standard and desirable property
of most "random" functions to produce the same number sequence whenever
you call them without seeding first (or with a specific seed) - cf e.g.
random(3) in a C library near you. A function that doesn't do this is
either a toy or geared specifically towards cryptography, which is of
course only one of many possible uses.

And as a programmer you should know that despite evidence to the
contrary, software can never produce random results, you need hardware
for that:-) - all software RNGs are pseudo-ditto, producing a "very
long" (but finite) cycle of "apparently random" (but entirely
predictable when the internal state is known) numbers. You just get to
choose the starting point, i.e. the seed. So the trick of getting "true"
randomness lies in appropriately using some appropriate hardware to get
a "good" seed.

As requirements on this varies wildly, it's not something the RNG should
do under the cover - in some cases you absolutely want the same sequence
every time (e.g. when debugging your statistical analysis tool), in
other cases you may be perfectly happy with the mostly crappy choice of
using erlang:now/0, in yet others you need something at least as good as
/dev/random (seeding is what it's for - though on Linux you'd better use
/dev/urandom unless you're prepared to have your program block
indefinitely), but the existence of this is OS-specific, etc etc.

Post by unknown
Possibly the referenced article in the 1982 Journal of Applied
Statistics has an excellent explanation of how to produce your own
seed and virtue of the constant provided by seed0(), but seriously!

A good (IMHO) and pretty compact writeup of the general issues can be
found in the FreeBSD random(4) man page:

http://www.freebsd.org/cgi/man.cgi?query=random&sektion=4#RANDOMNESS

--Per Hedeland

[unknown]

Post by unknown

Post by unknown
Most people calling random:uniform/1 will want a randomish number,

Did you take a survey?:-)

I have grepped our 700KLOC source tree for calls to the random module.

I see 75 calls to random:uniform/1:

- None are obviously depending on repeatability. Maybe they do, but I
doubt it. If I were writing a simulation that depended on
repeatability I would explicitly call random:seed0() to make that
intention explicit.

- I see three calls to random:uniform/0. They are all in process
'init' functions so none actually has any effect (the process gets
the default constant seed with or without the call). I tend to think
these are all bugs and the intention was to seed from something
unpredictable but I can't prove it.

- Several that are not seeded are obviously in error (mostly code
written by me, but that's where the real intention is clearest)

- 25 are seeded by now() in code written by well-respected Erlang
programmers who are friends of yours and have backgrounds in
developing security products :-)

- None are seeded by anything other than now()

In fact it's timely that I checked this. We have just patched Yaws to
stop reusing request-handler processes and it looks like this will
cause some calls to random:uniform in appmod code to do the wrong thing.

Perhaps the random module interface can be justified in terms of unix
arcana but I counter-cite the better interfaces of Perl, Python, and
even Java that all try to auto-seed the random number generator as
best they can (urandom, current time, etc) unless you ask otherwise.

Why optimize the interface for statisticians writing simulations when
it's loonies writing telecom code late at night who actually use it? :-)

[unknown]

Post by unknown
- I see three calls to random:uniform/0. They are all in process

^^^^^^^^^ seed/0

[unknown]

Post by unknown
i'm convinced that soon enough a java-like language (javascript?) will
incorporate erlang-style processes/message passing. and then erlang will, i
fear, indeed be done.
C.f. http://steve-yegge.blogspot.com/2007/02/next-big-language.html
I wonder what would be easier: to port the Erlang runtime to the JVM,
or to write a compiler for a Java-like language targeting the beam
runtime?

that's only if design and notation don't matter, and they do.
to start with, is any form of concurrency compatible with an object-oriented language?

or again: Erlang is a little gem; Java is a dung heap. why hide the one inside the other?
i just don't get it. it's not even as though (as with C, say) you'd thereby be getting
access to a great set of run-time libraries.

[unknown]

Post by unknown
to start with, is any form of concurrency compatible with an object-oriented language?

Have a look at E, which is a distributed message-passing OO language.
http://www.erights.org/#2levels

Tony.

[unknown]

Hi,

Post by unknown

Post by unknown
I wonder what would be easier: to port the Erlang runtime to the JVM,
or to write a compiler for a Java-like language targeting the beam
runtime?

that's only if design and notation don't matter, and they do.
to start with, is any form of concurrency compatible with an object-oriented language?

I don't see any incompatibility here. Of course, I assume we're not
talking about today's OO languages, but ones that take steps towards
the concurrency oriented paradigm. I mean, everything is evolving.

in other words, I think the "object as process" metaphor holds very nicely.

Post by unknown
or again: Erlang is a little gem; Java is a dung heap. why hide the one inside the other?
i just don't get it. it's not even as though (as with C, say) you'd thereby be getting
access to a great set of run-time libraries.

Java is just an example. It seems like a probable candidate just by
the sheer mass of users and libraries (of which BTW I assume most will
be reusable on the improved platform).

IMHO, the not so distant future will give us "erlang processes" at the
OS level and later on at the hardware level. I have trouble imagining
that there will only be a single programming language in use and I
think it is a safe bet that one of them will be a C extension.

My natural curiosity is pushing me into exploring alternative ways to
do things. Some are dead-ends, but some will lead forward. How else to
progress?

best regards,
Vlad

[unknown]

Post by unknown
Java is just an example. It seems like a probable candidate just by
the sheer mass of users and libraries (of which BTW I assume most will
be reusable on the improved platform).

Given the number of Java libraries that aren't threadsafe and the
magnitude of the paradigm shift required to get the benefits of Erlang
in any language, I don't think that's going to be the case.

--J

[unknown]

Post by unknown

Post by unknown
Java is just an example. It seems like a probable candidate just by
the sheer mass of users and libraries (of which BTW I assume most will
be reusable on the improved platform).

Given the number of Java libraries that aren't threadsafe and the
magnitude of the paradigm shift required to get the benefits of Erlang
in any language, I don't think that's going to be the case.

The latter is a valid argument, although IMHO the paradigm shift will
have to happen anyway, sooner or later. Whether it's going to be
towards Erlang's paradigm or some other, that's another issue.

The former I can't agree with -- the beauty of the "object as process
with no shared data and communication by message passing" model is
that thread safety as we know it is mostly irrelevant.

best regards,
Vlad

[unknown]

Post by unknown
Hi,
...
IMHO, the not so distant future will give us "erlang processes" at the
OS level and later on at the hardware level.

Truly "back to the future": The Inmos Transputer did this in the 1980s.

--T

[unknown]

There is nothing new under the sun.

Robert

Post by unknown

Post by unknown
Hi,
...
IMHO, the not so distant future will give us "erlang processes" at the
OS level and later on at the hardware level.

Truly "back to the future": The Inmos Transputer did this in the 1980s.
--T
_______________________________________________
erlang-questions mailing list
erlang-questions
http://www.erlang.org/mailman/listinfo/erlang-questions

[unknown]

Post by unknown
There is nothing new under the sun.

there was a first time for everything :-)


bengt