[erlang-questions] Simple Erlang Recommendation (last returned value)

[Richard A. O'Keefe]

On 29 Jul 2008, at 3:32 am, Berlin Brown wrote:
>
> I think this is the best solution for what I am doing.
>
> lists:foldl(
>   fun(X, Last_value) -> queue:add(X, Last_value) end,
>   queue:new(),
>   [joe, mike]).

Why is this better than using queue:from_list/1?

>
> There are a couple of things that I wanted to make clear.  I did NOT
> want to change the mutability aspect of Erlang, as many have
> suggested, it goes to the core of Erlang and functional programming.
> And ideally what I suggested was more from "stack/functional" based
> languages like Factor or Forth not so much imperative languages like
> Java/C++.

I don't know anything about Factor, but Forth ***IS*** an imperative
language.  Just because one of the things it goes around smashing is
a stack doesn't make it any less based on smashing things.

If you liked Forth, you may like Pop.
See http://www.cs.bham.ac.uk/research/projects/poplog/freepoplog.html
In one box:
   - Pop11, a dialect of the AI programming language Pop-2
   - Common Lisp
   - Standard ML
   - a somewhat nonstandard but still useful Prolog
   - VED, a programmable editor
   - books, teaching materials, library packages, ...
The point of interest about Pop is that it is an explicitly stack-
based language.

When I was a student at Edinburgh, I adapted a Listerine slogan:
	I hate Pop:  twice every day.
>

> I as assuming there was a call stack or some internal mechanism in
> Erlang that keeps track of the result of the last expression and maybe
> there is a way to "dup"licate that expression or something similar.

As has already been pointed out, in order to use such a feature you
would have to KNOW which was the last expression, which means you
would have to KNOW the order in which the arguments of a function
call are evaluated.

Part of the point of *pure* functional languages is that you have
no reason to care what the order is, so the compiler has complete
freedom to evaluate things in any order it finds convenient.  Now
Erlang is not a pure functional language by any means, but the
queue operations are in the pure part of the language.

It has also been pointed out that if you do

	NewQ = queue:new()

then this _can_ be understood as pushing something on the stack
AND THEN POPPING IT OFF.  The Pop equivalent would be
	queue$new() -> NewQ;


> Essentially, I was wishing there was a similar erlang function to do
> something which might save keystrokes.
>
> Q1 = queue(dog, NewQ),
> Q2 = queue(dog, Q1),
> Q3 = queue(dog, Q2)
> ...
>
> Q1 = queue(dog, NewQ),
> queue(dog, erlang:dup()),
> queue(dog, erlang:dup())
> ...
> where dup = return result from last expression.

As noted above and in earlier messages, by the time you get
to the first erlang:dup():
  1. Q1 is *not* on the stack any more,
  2. the "last expression" is 'dog'.

In this case, you have queue:from_list/1 which takes a list
of items and returns a queue with the same items in the same
order.

     queue:from_list([first,second,third,fourth])

is clearer than ANY hack.

> And I don't totally understand how erlang expressions are evaluated so
> it may not make sense at all in Erlang.

The value of a constant is that constant.
The value of a variable is the term bound to that variable.
The value of a function call is determined by
   - evaluating the arguments
   - finding a matching clause using pattern matching and guards
   - evaluating the corresponding body
and so it goes.

There might be an expression stack (there was in the JAM VM for Erlang)
or there might not be (the current BEAM VM is register based).
Aside from questions of performance, we have no reason to care.

>  For example, with Erlang's
> pattern matching, internally expressions may not be evaluated in such
> a routine by routine fashion as they may be in imperative languages.

Pattern matching doesn't do anything at all to expression evaluation.
As in ML, pattern matching is just a generalisation of 'case'.