[erlang-questions] help

Fawad Irfan <>
Tue Sep 11 06:08:31 CEST 2007


Hi

Do any archive of previous emails is maintained. I'm new to ErLang and have
lot of questions. I want to go through the already answered question  then
asking these again.

Thanks

Foad Sheikh

-----Original Message-----
From: 
[mailto:] On Behalf Of

Sent: Monday, September 10, 2007 2:00 PM
To: 
Subject: erlang-questions Digest, Vol 4, Issue 34

Send erlang-questions mailing list submissions to
	

To subscribe or unsubscribe via the World Wide Web, visit
	http://www.erlang.org/mailman/listinfo/erlang-questions
or, via email, send a message with subject or body 'help' to
	

You can reach the person managing the list at
	

When replying, please edit your Subject line so it is more specific than
"Re: Contents of erlang-questions digest..."


Today's Topics:

   1. Re: Intel Quad CPUs (ok)
   2. Re: Intel Quad CPUs (ok)
   3. Re: Performance Testing with C++, Java, Ruby and Erlang
      (Ulf Wiger (TN/EAB))
   4. Newbie training project proposal ( Tomasz B?achowicz )


----------------------------------------------------------------------

Message: 1
Date: Mon, 10 Sep 2007 13:14:05 +1200
From: ok <>
Subject: Re: [erlang-questions] Intel Quad CPUs
To: Erlang <>
Message-ID: <>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 8 Sep 2007, at 2:12 am, Tony Finch wrote:
> I'd suggest using initial caps for type names, and omit the () except 
> when the type parameter is non-trivial. (That is somewhat like the 
> Haskell type syntax.)

It would be more accurate to describe it as "as unlike the Haskell syntax as
possible".  Haskell uses the same conventions for type
(constructors/variables) as for data (constructors/variables), so to be
close to Haskell syntax, you have to use the same spelling for type
constructors as you do for constants, namely, LOWER case.  Also, in Haskell,
every type constructor is a function, so to be close to Haskell syntax, you
would have to use function notation for all Erlang type constructors.  And
behold, that's exactly what Erlang does!  The *existing* type syntax is
precisely what you get when you apply the *principles* behind Haskell type
syntax to a language with Erlang's lexical conventions.




------------------------------

Message: 2
Date: Mon, 10 Sep 2007 13:22:44 +1200
From: ok <>
Subject: Re: [erlang-questions] Intel Quad CPUs
To: erlang-questions <>
Message-ID: <>
Content-Type: text/plain; charset=US-ASCII; delsp=yes; format=flowed

On 8 Sep 2007, at 2:31 am, Richard Carlsson wrote:
>   - you couldn't just cut out a guard and paste it in somewhere,
>     because the scope wasn't the same - atom(X) and the other tests
>     were not defined outside guards

You *still* can't do that because the *semantics* is different.
Consider

	atom(X), integer(Y)

or, if you prefer to be long-winded,

	is_atom(X), is_integer(Y).

As a guard, this asserts the conjunction "X is an atom (and) Y is an
integer".  As an expression, it says "determine whether X is an atom or not
but forget the answer; now tell me whether Y is an integer".

With comma having different semantics in the two environments, it is
actually a very useful protection when a guard test uses a name that is not
available in expression.

	atom(X), integer(Y)

has the decency to raise an exception if you try to use it in an expression,
instead of quietly giving you the wrong answer.

>
>   - you couldn't access the type tests directly as a boolean value,
>     as in "Bool = atom(A)" - you'd have to write "Bool = (if atom
> (A) ->
>     true; true -> false end)", which is not exactly elegant

This was trivially fixable with a macro:

	?G(X) ===> if X => true ; true => false end

Note that the semantics of 'length', amongst others, is subtly different
between guard and expression contexts, so
	?G(length(X) < 10)
is *not* the same as
	length(X) < 10

>
>   - some names could have different meaning depending on whether they
>     were used as guard tests or as normal expressions - float(X) is
>     a boolean test for float-ness if it's a guard, but if it's a
>     normal expression then it refers to the int-to-float conversion
>     function

That is the only persuasive argument I've ever heard, and in light of the
other semantic differences, it would have been better to rename the
convert-to-float function to as_float/1.




------------------------------

Message: 3
Date: Mon, 10 Sep 2007 09:30:23 +0200
From: "Ulf Wiger (TN/EAB)" <>
Subject: Re: [erlang-questions] Performance Testing with C++, Java,
	Ruby and Erlang
To: shahzad bhatti <>
Cc: 
Message-ID: <>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Ulf Wiger (TN/EAB) wrote:
> 
> The set_node_value/1 function is called from within a lists:foreach(), 
> when you should rather use e.g. lists:foldl() with Nodes as an 
> accumulator. That would eliminate all the get() and put() operations, 
> as the updated Nodes variable is passed on to the next iteration.
> 
> set_node_value(Round, #config{proc_ids = Proc_ids, nodes = Nodes}) ->
>     lists:foldl(
>         fun(Id, Ns) ->
>             set_node_value(Round, Id, Nodes)
>         end, Nodes, ProcIds).

This is of course wrong, and a compiler warning would have indicated the
problem, had I bothered to actually compile the proposed changes. The call
to set_node_value/3 must be done using Ns rather than Nodes:

set_node_value(Round, #config{proc_ids = Proc_ids, nodes = Nodes}) ->
     lists:foldl(
         fun(Id, Ns) ->
             set_node_value(Round, Id, Ns)
         end, Nodes, ProcIds).

BR,
Ulf W


------------------------------

Message: 4
Date: Mon, 10 Sep 2007 10:18:44 +0100
From: " Tomasz B?achowicz " <>
Subject: [erlang-questions] Newbie training project proposal
To: 
Message-ID:
	<>
Content-Type: text/plain; charset=ISO-8859-1

Hi all,

I'm looking for wannabe/newbie erlang developers who'd like to learn that
language in practice. I'm going to create new open source project from
scratch that will aim to implement STOMP messaging protocol [1] in erlang.
I've been considering both client and server side implementation.

The STOMP protocol is a quite interesting proposal of simple text-oriented
messaging protocol. While coding we could probably explore such erlang areas
like socket programming, possibly gen_server framework, Mnesia, ETS, not to
mention basic concepts of the language.
I believe STOMP protocol is kind of ideal candidate for that exercise,
bacause it's simple enough (I mean not so complex) and contains some
non-trivial aspects e.g. transactions, full-duplex socket traffic, etc.

I personally believe that is could be good opportunity to learn erlang by
coding instead of only by reading books, articles and tutorials, etc. If you
are interested in participation, please contact me directly.

References:
[1] http://stomp.codehaus.org/Protocol

Take care,
Tom


------------------------------

_______________________________________________
erlang-questions mailing list

http://www.erlang.org/mailman/listinfo/erlang-questions

End of erlang-questions Digest, Vol 4, Issue 34
***********************************************


#####################################################################################
Note:
The content of this email together with any attachments, statements and opinions expressed herein contains information that is private and confidential, are intended for the named addressee/s only. If you are not the addressee of this email you may not copy, forward, disclose or otherwise use it or any part of it in any form whatsoever. If you have received this message in error, please notify  by email immediately and delete the message without making any copies.
#####################################################################################



More information about the erlang-questions mailing list