erlang sucks

[Alpár Jüttner-2]

> Maybe it is due to the fact that most of them know C/C++/Java/Python.
> Maybe Erlang syntax is not so intuitive and easy as one could expect
> from a modern and powerful languages.  
> Maybe because the standard library is not so rich and not so
> consistent as expected from a mature language.

I cannot agree with it. I grew up in the C/C++ world and also had known
Python before I met Erlang, still I find it very intuitive. I'm also
_very_ impressed by the simplicity and the expressive power. (I'm not a
student though...)

I think, the major obstacle for newcomers is not the syntax, but the
immutable data structures, the impossibility of variable rebinding, and
the miss of loop constructs like 'for' and 'while'. For someone familiar
(only) with procedural languages, it is hard to believe that a language
can be efficient without these features.

Regards,
Alpar



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

[David Holz]

From: ok@...
> Concerning 'if', may I remind readers that the 'cond' proposal (not
> mine)
> has been around for quite a while, and except for using 'cond' rather
> than 'if' as the keyword, completely answers the claimed need for an if
> with user-defined functions callable in the guards.

Claimed need?  Predicate functions are absolutely necessary in handling dispatch decisions for any sort of system whose message vocabulary is upgraded over time, in my experience.  Having to put the explicit matching specification any place where a message or data structure is handled (even for simple dispatch pass-through which doesn't do anything with the contents) instead of deferring to a predicate is a horrible violation of DRY, and requires error-prone code hunting if it ever changes shape.  Also, the ability to handle an entire category of messages via predicate, as opposed to matching each individual shape in its own clause, is substantial.

Of course, one work-around to the lack of functions in guards is to prepend all functions you'd use before the case/receive and bind their results in variables.  That works, but again trashes your code organization, especially when your main receive or case dispatch gets to be fairly large; is again a violation of DRY putting all the gory message details into something that doesn't use them; and is horribly sub-optimal since everything is called all the time instead of only enough to get the result that's needed.

> What happens if those user defined functions exchange messages with the
> rest of the world is not something I want to think about...

If you're so worried about being coddled by the language, then we really need a notion similar to C++ "constness".  Track and propagate which functions are pure functional, and toss compile-time, module-load time, or runtime errors if you choose to do so.  I'd much rather have user-defined guard functions and have it upon myself to use them properly, than to throw out the baby with the bathwater just because it could possibly be misused.

Yeah, I'm a little irate about the guard issue, simply because it seems it's clung to purely because of stick-in-the-mud attitude.  Yes, I know that guard BIFs compile into BEAM directly and have their own optimization strategy, but function calls are still BEAM code you can generate.  I don't care if it's a bit slower.  We use code generation from spec DSLs for all event types and now full protocol specifications, so the ability to defer "is this a Hello message?" decisions to external generated functions is a basic requirement.  Right now, we have to try to hack it into ?IS_HELLO style macros which expand to only guard BIFs where it can fit and mess with .hrl files.  If you say that that's a decent solution, I might have more irate words to dispense. ;)

_________________________________________________________________
Shed those extra pounds with MSN and The Biggest Loser!
http://biggestloser.msn.com/
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard Kelsall]

Gah, indeed it does work, more egg on face :) I went through several
versions to get to that point, I must have tried substituting ?LINE
into a previous version and failed somehow. Thank you.

Richard.


Hynek Vychodil wrote:

> May be I missed some, but it works for me in R11B-5
>
> -module(temp).
> -export([test/0]).
> -define(log(Message, Var), log_message(?MODULE, ?LINE, Message, ??Var,
> Var)).
>
>
>
> log_message(Module, Line, Message, VarName, Var) ->
>      io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message,
>                VarName, Var]).
>
> test() ->
>     X = {a,b},
>     ?log("Unexpected post", X). % here is line 20
>
> %end
>
> $ erl -smp
> Erlang (BEAM) emulator version 5.5.5 [source] [smp:1] [async-threads:0]
> [hipe] [kernel-poll:false]
>
> Eshell V5.5.5  (abort with ^G)
> 1> c(temp).
> {ok,temp}
> 2> temp:test().
> log: {temp, 20} Unexpected post X = {a,b}
> ok
> 3>
>
>
> On Wed, Mar 12, 2008 at 4:08 PM, Richard Kelsall
> <r.kelsall@... <mailto:r.kelsall@...>> wrote:
>
>     Nohl Attila Rajmund wrote:
>      > Yes, erlang has excellent trace facilities, it shows me that the
>     'rfmm'
>      > function was called - unfortunately it doesn't show that which of
>     the 10
>      > rfmm functions was called.
>
>     Breaking a small subject off the main thread. I haven't written much
>     Erlang yet so maybe I'm just missing something, but I get the impression
>     Erlang won't tell me the line number when something goes wrong. I feel
>     it would be useful to know this and very in keeping with the Erlang
>     approach of making bugs nice and visible. So my vote while we're all
>     requesting changes to Erlang :) is for more line number visibility.
>
>     On a related subject I've played around with the LINE macro to tag
>     my own logging/error messages with line numbers and the best I could
>     produce was something like this :
>
>       -define(log(Line, Message, Var), log_message(?MODULE, Line, Message,
>               ??Var, Var)).  % LINE macro always gives '1' if I put it here.
>
>       log_message(Module, Line, Message, VarName, Var) ->
>          io:format("log: {~p, ~p} ~s ~s = ~p~n", [Module, Line, Message,
>                    VarName, Var]).
>
>     and then in my code I can do things like
>
>         ?log(?LINE, "Unexpected post", Other),
>
>     This works fine, but it would be nice to just write
>
>         ?log("Unexpected post", Other),
>
>     and get the line number somehow. Can this be done?
>
>
>     Richard.
>
>
> --
> --Hynek (Pichi) Vychodil

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

[KatolaZ]

On Thu, Mar 13, 2008 at 11:41:10AM +0000, Alp?r J?ttner wrote:

> > Maybe it is due to the fact that most of them know C/C++/Java/Python.
> > Maybe Erlang syntax is not so intuitive and easy as one could expect
> > from a modern and powerful languages.  
> > Maybe because the standard library is not so rich and not so
> > consistent as expected from a mature language.
>
> I cannot agree with it. I grew up in the C/C++ world and also had known
> Python before I met Erlang, still I find it very intuitive. I'm also
> _very_ impressed by the simplicity and the expressive power. (I'm not a
> student though...)

If we should talk about expressiveness, I think that haskell mostly wins
among functional languages. But haskell syntax (just to keep this example)
is far more intuitive and clear (and orthogonal) than Erlang's.

>
> I think, the major obstacle for newcomers is not the syntax, but the
> immutable data structures, the impossibility of variable rebinding, and
> the miss of loop constructs like 'for' and 'while'. For someone familiar
> (only) with procedural languages, it is hard to believe that a language
> can be efficient without these features.
>

Those features are not erlang-centric: also Ocaml and haskell would
require a little of an effort for a C programmer. BTW, the little
experience I have in writing Erlang code says that if I had written
it in haskell it would have benn far more readable and nice.

In a couple of words, we don't have just to choose among Erlang OR
imperative programming (C/Java/Python & Co.): we've a lot of choices
in the field of funtional languages, and a couple of them have some
nicer syntax and features compared to Erlang.

HND

KatolaZ

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Rick Pettit]

On Thu, Mar 13, 2008 at 11:41:10AM +0000, Alp?r J?ttner wrote:

> > Maybe it is due to the fact that most of them know C/C++/Java/Python.
> > Maybe Erlang syntax is not so intuitive and easy as one could expect
> > from a modern and powerful languages.  
> > Maybe because the standard library is not so rich and not so
> > consistent as expected from a mature language.
>
> I cannot agree with it. I grew up in the C/C++ world and also had known
> Python before I met Erlang, still I find it very intuitive. I'm also
> _very_ impressed by the simplicity and the expressive power. (I'm not a
> student though...)
>
> I think, the major obstacle for newcomers is not the syntax, but the
> immutable data structures, the impossibility of variable rebinding, and

These "features" make it much easier to write buggy code (and much harder to
find such buggy code). The developers you speak of need to take off their
blinders if they ever hope to see the light.

> the miss of loop constructs like 'for' and 'while'.

Erlang has plenty of loop constructs--how else could you write a server
loop? And with the use of tail-recursion this need not be inefficient.

There's also lists:foldl/3, lists:foreach/2, list comprehensions, etc. I
much, much prefer the look of these constructs over the equivalent
for or while loops--regardless, the same can be accomplished with both.

> For someone familiar
> (only) with procedural languages, it is hard to believe that a language
> can be efficient without these features.

For someone more familiar with functional languages, it is hard to believe
applications can be written correctly (let alone efficiently) _with_ those
features.

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

[Alpár Jüttner-2]

> If we should talk about expressiveness, I think that haskell mostly wins
> among functional languages. But haskell syntax (just to keep this example)
> is far more intuitive and clear (and orthogonal) than Erlang's.

I didn't try to compare Erlang to any other functional language. You
said that it is seems hard-to-learn for students and concluded that it
must be because of its bad syntax. What I answered is that basically
nothing is wrong with the syntax of Erlang (it is simple, intuitive and
easy-to-learn). It might be better, but the real difficulty of its
learning for a student that it is functional.

> Those features are not erlang-centric: also Ocaml and haskell would
> require a little of an effort for a C programmer.

I didn't want to say the opposite.

> In a couple of words, we don't have just to choose among Erlang OR
> imperative programming (C/Java/Python & Co.): we've a lot of choices
> in the field of funtional languages, and a couple of them have some
> nicer syntax and features compared to Erlang.

What is your experience, do your students tend to really prefer Haskell
to Erlang?

Best regards,
Alpar


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

[Ulf Wiger (TN/EAB)]

KatolaZ skrev:
> In a couple of words, we don't have just to choose among Erlang OR
> imperative programming (C/Java/Python & Co.): we've a lot of choices
> in the field of funtional languages, and a couple of them have some
> nicer syntax and features compared to Erlang.

I agree that Haskell's syntax is very nice, once you've gotten
used to it. The main problem for a beginner, is that it has
so little of the usual cruft, that it's difficult to tell
what's going on. (:

I think it's a bit unfortunate that there isn't more sharing
between Haskell, ML/OCaml and Erlang. Every once in a while,
there has been some talk about developing interop libraries
for going back and forth between the different languages.
Personally, I think it's a cop-out to say that all three
support interfacing to C. It still leaves a lot of work for
the programmer wanting to make use of some good library
written in one of the other languages.

There is the ErlOCaml Google group, which actually has some
code in it:

http://code.google.com/p/erlocaml/

Then there are the various pet projects offering alternative
syntax on top of the Erlang VM.

These are the various projects I know of:

- lersp  which interprets "an approximation of scheme"
   (http://jungerl.cvs.sourceforge.net/jungerl/jungerl/lib/lersp/),

- Erlang/Gambit interface (interfacing Erlang from Scheme)
http://theschemeway.blogspot.com/2007/07/schemeerlang-interoperability-sequel.html
   (especially aiming at accessing Mnesia from Scheme, it seems)

- LFE - Lisp for Erlang, obviously

- HaskErl - Haskell to Erlang Core Compiler
   http://blog.tornkvist.org/blog.yaws?id=1190846785574003
   (There is also a Perl extension to Haskell, called Haskerl,
    predating the above by about 15 years...)

- ETOS - Erlang to Scheme compiler
   http://www.iro.umontreal.ca/~larosem/papers/etos.ps.gz

- Stoe - Scheme to Erlang compiler
 
https://webmail.iro.umontreal.ca/pipermail/gambit-list/2007-June/001466.html

- My own hack to allow different syntaxes in the Erlang shell:
   http://ulf.wiger.net/weblog/2007/11/21/extending-the-erlang-shell-part-2/
   (it would be better if there existed a Core Erlang evaluator)


Judging by past attempts, I'd say that interop solutions have a far
better chance of gathering an audience than an X-to-Y compiler.
But whatever stimulates sharing of ideas across communities is
most likely a Good Thing.

BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Alpár Jüttner-2]

For the heaven's sake, I have never said it is a disadvantage of Erlang
that is functional !!!! I only said that it might cause some
difficulties for a beginner (a student), because most of them are
already familiar with a procedural language, and they want to write
program in Erlang in the same way as they did in C/C++/Java/Python.

Is my English so bad?

Regars,
Alpar



On Thu, 2008-03-13 at 11:11 -0500, Rick Pettit wrote:

> On Thu, Mar 13, 2008 at 11:41:10AM +0000, Alp?r J?ttner wrote:
> > > Maybe it is due to the fact that most of them know C/C++/Java/Python.
> > > Maybe Erlang syntax is not so intuitive and easy as one could expect
> > > from a modern and powerful languages.  
> > > Maybe because the standard library is not so rich and not so
> > > consistent as expected from a mature language.
> >
> > I cannot agree with it. I grew up in the C/C++ world and also had known
> > Python before I met Erlang, still I find it very intuitive. I'm also
> > _very_ impressed by the simplicity and the expressive power. (I'm not a
> > student though...)
> >
> > I think, the major obstacle for newcomers is not the syntax, but the
> > immutable data structures, the impossibility of variable rebinding, and
>
> These "features" make it much easier to write buggy code (and much harder to
> find such buggy code). The developers you speak of need to take off their
> blinders if they ever hope to see the light.
>
> > the miss of loop constructs like 'for' and 'while'.
>
> Erlang has plenty of loop constructs--how else could you write a server
> loop? And with the use of tail-recursion this need not be inefficient.
>
> There's also lists:foldl/3, lists:foreach/2, list comprehensions, etc. I
> much, much prefer the look of these constructs over the equivalent
> for or while loops--regardless, the same can be accomplished with both.
>
> > For someone familiar
> > (only) with procedural languages, it is hard to believe that a language
> > can be efficient without these features.
>
> For someone more familiar with functional languages, it is hard to believe
> applications can be written correctly (let alone efficiently) _with_ those
> features.
>
> -Rick

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

[Kevin Scaldeferri]

On Mar 13, 2008, at 9:13 AM, Alpár Jüttner wrote:

>
>
>> In a couple of words, we don't have just to choose among Erlang OR
>> imperative programming (C/Java/Python & Co.): we've a lot of choices
>> in the field of funtional languages, and a couple of them have some
>> nicer syntax and features compared to Erlang.
>
> What is your experience, do your students tend to really prefer  
> Haskell
> to Erlang?

Personally, I feel like for the type of tasks that most students /  
academics do, Haskell is nicer.  For the sort of thing that most  
professional programmers do, Erlang is nicer.  I can live with some  
modest extra verbosity in exchange for solving some really hard  
practical problems.


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

[Vance Shipley]

Learning Erlang often also means learning functional programming.
I believe it helps a good deal to understand that while you are
doing it.  If I had known the basics of what "functional" meant
I wouldn't have had such a hard time wrapping my head around
single assignment and the like (oh so many years ago).

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

[KatolaZ]

On Thu, Mar 13, 2008 at 09:59:27AM -0700, Kevin Scaldeferri wrote:
>
> Personally, I feel like for the type of tasks that most students /  
> academics do, Haskell is nicer.  For the sort of thing that most  
> professional programmers do, Erlang is nicer.  I can live with some  
> modest extra verbosity in exchange for solving some really hard  
> practical problems.
>

To be honest, I don't think that the matter is "the type of tasks that
most students / academics do" :-) I think that Erlang has some nice
stuff that haskell still misses (like native support for reliability
management, for instance); but anybody who knows a bit of haskell
cannot deny that its syntax is much more clear and expressive, and
this does not have anything to do with the fact that you are an
experienced firm programmer or an undergraduate student: it is just a
matter of fact :-)

I usually hear Erlang programmers complaining about Lisp parentheses,
but if you look into an Erlang module which does something meaningful,
you would find tons of parentheses, and of 4 different types: "()",
"[]", "{}", "<<>>".

What I mean is that we need to use a little of criticism also when we
talk about our favourite language, and in this sense I really
appreciated that blogpost which started this kind of flame: if we read
it from a "neutral" point of view, we'll find that most of what ketz
have written is TRUE, expecially if we use another FPL like haskell
for the comparison.

Finally, I agree with Ulf when he says that Erlang, Haskell,
lisp/scheme and ML/OCaml communities should work together much more
than how they are actually doing: all of them could benefit from such
kind of collaboration. Maybe Erlang would have been a better language
today from many perspectives, if our community had got ideas and
solutions from haskell/OCaml/scheme experiences.

My2Cents

Enzo

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Raoul Duke]

>  stuff that haskell still misses (like native support for reliability
>  management, for instance); but anybody who knows a bit of haskell

http://www.macs.hw.ac.uk/~dsg/gdh/papers/FaultToleranceProposal_sfp00_draft.ps

is a little bit in that direction, i guess. presumably not exactly
industrially proven yet, vs. Erlang's hallowed history :)
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Rick Pettit]

On Thu, Mar 13, 2008 at 04:57:43PM +0000, Alp?r J?ttner wrote:
> For the heaven's sake, I have never said it is a disadvantage of Erlang
> that is functional !!!! I only said that it might cause some
> difficulties for a beginner (a student), because most of them are
> already familiar with a procedural language, and they want to write
> program in Erlang in the same way as they did in C/C++/Java/Python.
>
> Is my English so bad?

Not at all, and I apologize if I offended you.

The bottom line, though, is erlang is not a procedural language. Therefore,
people that can't switch to a functional/concurrent programming paradigm are
naturally going to have a hard time, and maybe even dislike the language.

Tossing something that looks like a for or while loop at them to help them
learn the language doesn't make sense--it doesn't help them switch to the
new paradigm. Where iteration used to be a "good fit", now recursion is
employed, etc.

Likewise, variables are single assignment. Dict and other modules can be
used to try and cheat and get multiple assignment (or worse, global variables),
but that's terrible style and so it also won't help them out in the long run
(probably won't help in the short run, either).

I used to be one of these poor souls, but I switched over to erlang so long
ago and haven't look back since--I'm not sure I recall exactly how I got
here :-)

I do think there's hope for newcomers, though, considering I did get here and
without a lot of resources now available to newcomers:

  1) Joe's new book

  2) better docs

  3) sites like erlware, trap exit, etc which give great examples, include
     tutorials geared towards the beginner, etc

  4) this mailing list (which was around way back when I was learning, but
     with so many more subscribers today than 5+ years ago it's that much
     quicker/easier to get answers--and there's years of archives to dig
     through as well)

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

[t ty]

5) the irc channel on irc.freenode.net

t

On Thu, Mar 13, 2008 at 4:12 PM, Rick Pettit <rpettit@...> wrote:
[snip]

>
>   1) Joe's new book
>
>   2) better docs
>
>   3) sites like erlware, trap exit, etc which give great examples, include
>      tutorials geared towards the beginner, etc
>
>   4) this mailing list (which was around way back when I was learning, but
>      with so many more subscribers today than 5+ years ago it's that much
>      quicker/easier to get answers--and there's years of archives to dig
>      through as well)
>
>
>
>  -Rick
>  _______________________________________________
>  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

[Massimo Cesaro]

On Thu, Mar 13, 2008 at 8:21 PM, KatolaZ <me@...> wrote:

On Thu, Mar 13, 2008 at 09:59:27AM -0700, Kevin Scaldeferri wrote:
>
> Personally, I feel like for the type of tasks that most students /
> academics do, Haskell is nicer.  For the sort of thing that most
> professional programmers do, Erlang is nicer.  I can live with some
> modest extra verbosity in exchange for solving some really hard
> practical problems.
>

To be honest, I don't think that the matter is "the type of tasks that
most students / academics do" :-) I think that Erlang has some nice
stuff that haskell still misses (like native support for reliability

My personal experience is closer to Kevin's point of view. For our company, Erlang is actually an engineering tool, and a really effective one.
As far as I know, Erlang design was driven by Ericsson requirements, ie a telecom industry development tool with peculiar features. I believe that this goal was achieved brilliantly, both in terms of  completeness and  effectiveness. I remeber I was quite impressed with Ulf paper on the increase of productivity among programmers using Erlang for the AXD development, and was even more impressed to verify his claims as completely true.
Sure, we had to completely change our reference paradigms, switching from object oriented C++ modeling to the functional Erlang approach; but once we began to think in Erlang, we saw that the solution of most of the problems we struggled in the last 15 years were distilled in  Erlang and OTP (just like Steve Vinovski  describe in the interview cited by Ulf).

As an engineering tool, we appreciate Erlang because it allows us to solve very complex TLC problems with a fraction of the effort required by any other development tool we know; in this respect, for us Erlang is a domain specific language that happens to solve also a broader range of problems.
As engineers in a specific problem domain, we are looking for getting the job done in the best way, paying attention to the code manufacturing and maintenance costs; it is a different approach from the computer scientist or from the student.
 

What I mean is that we need to use a little of criticism also when we
talk about our favourite language, and in this sense I really
appreciated that blogpost which started this kind of flame: if we read
it from a "neutral" point of view, we'll find that most of what ketz
have written is TRUE, expecially if we use another FPL like haskell
for the comparison.

Reading Damien Katz blog I understand that he used a pragmatic approach to develop CouchDB. In this respect, Erlang and OTP proved invaluable tools to achieve his goals and he'll use them again for this application. It seems that his criticism are related to his idea of using Erlang outside the problem domain Erlang was designed for, but then we are talking about a different language.
I'm happy that the open source model of Erlang is in the firm hands of Ericsson: this is the best guarantee that Erlang will always be an engineering tools to solve engineering problems.

Massimo

Finally, I agree with Ulf when he says that Erlang, Haskell,
lisp/scheme and ML/OCaml communities should work together much more
than how they are actually doing: all of them could benefit from such
kind of collaboration. Maybe Erlang would have been a better language
today from many perspectives, if our community had got ideas and
solutions from haskell/OCaml/scheme experiences.

My2Cents

Enzo

--
[ Enzo Nicosia aka KatolaZ --- GLUG Catania -- Freaknet Medialab ]
[ me [at] katolaz.homeunix.net -- http://katolaz.homeunix.net -- ]
[ GNU/Linux User:#325780/ICQ UIN: #258332181/GPG key ID 0B5F062F ]
[ Fingerprint: 8E59 D6AA 445E FDB4 A153 3D5A 5F20 B3AE 0B5F 062F ]
_______________________________________________

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

[Robert Virding]

On 13/03/2008, David Holz <david_holz@...> wrote:

Yeah, I'm a little irate about the guard issue, simply because it seems it's clung to purely because of stick-in-the-mud attitude.  Yes, I know that guard BIFs compile into BEAM directly and have their own optimization strategy, but function calls are still BEAM code you can generate.  I don't care if it's a bit slower.  We use code generation from spec DSLs for all event types and now full protocol specifications, so the ability to defer "is this a Hello message?" decisions to external generated functions is a basic requirement.  Right now, we have to try to hack it into ?IS_HELLO style macros which expand to only guard BIFs where it can fit and mess with .hrl files.  If you say that that's a decent solution, I might have more irate words to dispense. ;)

I don't definitely don't think that the main problem with user defined guards is efficiency or anything like that. It is not difficult to make a user function used in a guard as fast as the same function outside a guard.

The main problem is semantic! What does it mean when you call a general function inside a guard. The example which Richard gives is a good one. Assume I am in a receive and in the guard of testing one message I call a function which also receives messages. What happens to the message queue? Does the guard receive "see" the original message? Will the original receive "see" any messages removed by the guard receive? What happens if the guard receive takes the message the top receive is processing? Etc... Do I have logical message queue handling where each receive sees the complete queue it had when it was called? This problem is similar to the handling of the Prolog database which now are logical, but that does lead to some strange effects.

This is not just a matter of choosing any solution and running with it as you have to be able to explain it to people so it is understandable, consistent and USABLE.

One suggestion which has been made is to "turn off" using any unsafe BIF calls and have them cause the function to exit. But that would mean that user functions would behave differently if they are used normally or within a guard. Which could be difficult if you are calling functions from someone else's libraries.

The trouble with adding a feature like this, or any feature for that matter, is that you have to be able to handle all cases, and I mean *ALL* cases, not just the reasonable ones which you had in mind when planning the feature. And give meaning to all cases as well.

"It is impossible to make something foolproof because fools are so ingenuous."

Forgot about 'cond'. We should add that and allow any user code in the tests. We can either catch errors in tests and treat them as false or just let them generate a normal error. The latter I think.

Robert

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

[Raoul Duke]

> Assume I am in a receive and in the guard of testing one message I call a
> function which also receives messages. What happens to the message queue?

this has nothing to do with the reality of Erlang :-) but presumably
in a sufficiently powerful type system you could constrain the guards
to be safe?
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions

[Richard O'Keefe]

I wrote that
>> the 'cond' proposal ...  completely answers the claimed need for an  
>> if
>> with user-defined functions callable in the guards.
>
On 14 Mar 2008, at 1:30 am, David Holz wrote:
> Claimed need?

Yes.  CLAIMED need.

Remember, while guards resemble Erlang expressions, they are  
fundamentally
different.  Indeed, it is a real shame that new BIFs have been  
introduced
that can be used in both guards and expressions; it would have been  
better
to make the two sets of BIFs disjoint.  It is also a real shame that  
there
are alternatives to "," and ";" in guards borrowed from the expression
world.  Again, the two should have been kept clearly distinct.

The differences really boil down to this:
     guards are for INDEXING.
Just as a compiler is free to do unification in any order and to share
submatches across any number of clauses, so a compiler is free to do  
guard
code in any order, to share guard tests across any number of  
alternatives,
and to arbitrarily interleave matching and guard testing.  For example,
I would hope a compiler to translate
        p(X, "big hairy pattern") when integer(X), X > 0 -> ...
by testing the type and value of X before matching "big hairy pattern".

In order to freely reorder and share guard computations, the code must  
be
known to be free of side effects, including input/output and message  
passing.
To handle "exception = guard failure", it really pays to have  
operations that
could raise exceptions where the index compiler can see them, not  
hidden in
functions that do who knows what.

Haskell has it easier here, of course, because any side effects of a  
function
must be revealed in its type.

Suppose we ha
        cond E1 -> S1
            ; E2 -> S2
           ; En -> Sn
        end
This can be handled pretty closely by
        case E1 of true -> S1;
        case E2 of true -> S2;
        ...
        case En of true -> Sn
        end ... end end
All that's really needed here is an equivalent of Algol 68's "ouse",
which was to 'case' as 'elif' was to 'if'.  So add it!

        case E1 of true -> S1
        ouse E2 of true -> S2
        ...
        ouse En of true -> Sn
        end

"ouse" is pretty horrible (almost the only Algol 68 keyword I disliked;
what have cases got to do with the river Ouse?).  Doubtless some better
keyword could be found.  'orca', perhaps?  (Joke.)

> Predicate functions are absolutely necessary in handling dispatch  
> decisions for any sort of system whose message vocabulary is  
> upgraded over time, in my experience.

Just today I found that something I thought for *sure* was a Boolean
function actually needed to distinguish three cases.  I have to agree
that *classification* functions are necessary; it is far from obvious
that they have to be Boolean.  Again, in Haskell I often find that
something I originally thought of as returning a Boolean should return
a Maybe or Either instead.

Above I explained why changing 'if' to be 'cond' would be a bad idea.
We really do have good uses for something that acts the way 'if' does  
now.
I have also mentioned the 'cond' proposal.
But I have now explained why 'cond' should normally be avoided even if  
we
had it: it forces you to use Boolean results, which may seriously limit
your imagination.

Any time you have
        cond p1(X) -> f(X, g1(X))
            ; p2(X) -> h(X, g2(X))
        ...
you should probably be using
        case classify(X)
          of {p1,G1} -> f(X, G1)
           ; {p2,G2) -> h(X, G2)
        ...
just as it is better to do
        case X
          of [H|T] ->
          ...
than
        if is_cons(X) -> ... head(X) .. tail(X) ...



> Having to put the explicit matching specification any place where a  
> message or data structure is handled (even for simple dispatch pass-
> through which doesn't do anything with the contents) instead of  
> deferring to a predicate is a horrible violation of DRY,

I don't know what the acronym "DRY" stands for.
To the extent that I follow what you are saying here, I agree that you
shouldn't do that, but I deny that the absence of xif/cond makes you  
do it.

The suggestion about something similar to C++ "constness" (really,  
something
similar to what other declaration languages call "purity") is  
something I
thought about back in 1988, and was actually writing up a proposal for  
when
funs were introduced into the language and made it much more difficult.
C++ does it in the type system, and Erlang doesn't normally use a type  
system,
because of the difficulties combining that with hot loading.

If you are generating Erlang code from a DSL, then why not just fix your
code generator?

As a matter of fact, the 'abstract patterns' proposal I put forward oh  
so many
years ago would presumably solve your problem pretty much the way you  
want to
solve it, because abstract patterns are sufficiently constrained that  
they
CAN be safely used in guards.

        f(Msg = #hello{}) -> ...

is necessarily safe, whereas

        f(Msg) when strange_module:is_hello(Msg) ->

would not be.

I'm not sure whether to be gratified at how abstract patterns keep  
solving
problems, or saddened...



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

[Mats Cronqvist-3]

Richard A. O'Keefe wrote:
>
> I don't know what the acronym "DRY" stands for.
Don't Repeat Yourself. Popularized by the Pragmatic Programmers.

[mats_cronqvist.vcf]

---

begin:vcard
fn:Mats Cronqvist
n:Cronqvist;Mats
org:Kreditor Europe AB
email;internet:mats.cronqvist@...
title:Senior Developer
x-mozilla-html:FALSE
version:2.1
end:vcard

---

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

[Ulf Wiger (TN/EAB)]

Raoul Duke skrev:
>> Assume I am in a receive and in the guard of testing one message I call a
>> function which also receives messages. What happens to the message queue?
>
> this has nothing to do with the reality of Erlang :-) but presumably
> in a sufficiently powerful type system you could constrain the guards
> to be safe?

Given the state of type checking in Erlang nowadays, this might indeed
be ripe for some research and prototyping.

BR,
Ulf W
_______________________________________________
erlang-questions mailing list
erlang-questions@...
http://www.erlang.org/mailman/listinfo/erlang-questions