forget

[Vlad Dumitrescu]

Hi,

Please correct me if I am just confused. Language extensions are grat :-) 
but in this particular case, would they solve more than a small part of the 
problem? It was pointed out earlier that in practice, the successive calls 
tend to look something like:

{ok, A} = foo(Q),
{B, C} = bar(A),
{value, [D]} = baz(B, C),

which is difficult to encapsulate in a shortened variant. Unless, of course, 
a new set of programming rules are written and OTP is rewritten and 
everybody uses it.

C. Reinke wrote:
>Why not permit unbound variables in function calls, and only outlaw
>them in inter-thread communications? I looked at logic vs functional
>languages a while ago, and most of the examples where logic
>languages won where down to this late, but still single-assignment
>use of variables. And its a lot easier (almost trivial?) to
>implement within thread-boundaries.

Could you please explain in short why would this be a good idea? It is a 
long time since I used Prolog... Would these variables function as "out" 
parameters? Isn't it clearer to read and write code that returns all values 
as the result, not intermix them with the arguments? I know Prolog uses that 
for neat stuff, but it is a different world (or so I see it).

>     - non-nesting variable scope (fortunately not adopted for
>       the higher-order extensions)
>       so one cannot reuse the same variable name, as one usually
>       can with non-recursive lets.

I am not sure if this would be very useful, since there is no construct 
similar to "let". How would the nested scope be defined? Usually now one 
uses an auxiliary function - this may be seen as heavyweight, but what I 
find more of a problem than that is that with many aux funs one easily loses 
the local context.

>     - relatively heavy-weight syntax
>       making the use of higher-order functions less convenient
>       than in Haskell (MLs have the same problem). So instead
>       of defining their own higher-order control constructs
>       (which otherwise tends to be home ground for functional
>       languages), people are asking for language extensions
>       (the same happened with behaviours).

I am not very familiar with Haskell, but aren't it's capabilities for 
composing high-order funs (mostly) a result of currying and the syntax 
without parentheses? This might be introduced in Erlang, but would it still 
be Erlang afterwards? (*deep thought ;-)

best regards,
Vlad

_________________________________________________________________
MSN Foto är det enklaste sättet att dela eller skaffa papperskopior av dina 
foton: http://photos.msn.com/support/worldwide.aspx