[erlang-questions] Funargs: Ruby-like blocks for Erlang

Richard O'Keefe ok@REDACTED
Fri Jul 22 04:54:51 CEST 2011

On 22/07/2011, at 12:17 PM, Tony Arcieri wrote:

> On Thu, Jul 21, 2011 at 3:48 PM, Richard O'Keefe <ok@REDACTED> wrote:
> And YEEK!  The argument list here
> looks like nothing else in Erlang whatever!
> Surely surely surely Erlang should look like Erlang!
>    lists:map([1,2,3,4,5]) do (N) -> N*2 end
> And to address your point a little more here, no I don't think "|" isn't Erlangy anymore than I feel it isn't Ruby-like. The "|" ... "|" syntax in Ruby looks like nothing else in Ruby whatsoever, but it's still aesthetically pleasing. Certainly much more so than "(" ... ")" "->" ... "end"

The "|" ... "|" notation really does NOT mesh very well with pattern
matching, something Ruby is, um, deficient in.  Overloading punctuation
marks with too many meanings is not a good idea in any language.

> Nor do I feel the stabby

Why do you call the right arrow "stabby"?  To me that 
> is necessary here any more than I feel the "def" token is needed when defining an anonymous function in Ruby. The "do" token alone signifies you're defining an anonymous function and matches to the corresponding "end" token.

Just *precisely* as the "fun" token alone signifies that you are defining an anonymous
function and matches the corresponding "end" token in Prolog.

*Some* token is needed to separate the arguments from the body.
Since the arrow is used for that everywhere else in Erlang,
it would be inconsistent not to use it here.

> =This is where the margin turns negative.
> What has mapping to do with "DO"?
> The do is what the mapping does.

No.  "do" is a VERB.  Mapping is about computing *values*.
Mapping is not about side effects.  "DO" is about as imperative
a keyword as you could expect to find; it really does not belong
in a mostly functional language.  If you want to talk about
aesthetics, "do" has got to go.

Smalltalk gets this right:

	container do: aBlock		DOES something for each element.
	container collect: aBlock	COLLECTS a value for each element (it's map).
	container select: aBlock	SELECTS elements (it's filter)
	container count: aBlock		COUNTS matching elements
	container sortedBy: aBlock	SORTS container BY a comparison block

Ruby seized on one special case, "do:", emptied it of all meaning,
and shifted the burden of saying what result to compute elsewhere.
Not an improvement.

> The "do" keyword is completely intuitive to me in that what follows is a function which does something. I suppose the only cognitive dissonance here is that functional programmers go out of their way to not think of their programs as actually doing something, which may make sense in a lazy language like Haskell where your program may indeed never actually do anything, but if you feel that way about a language with strict evaluation like Erlang you're just kidding yourself.

What has strict evaluation to do with it?
It's perfectly possible to have a pure functional language
(that is, no mutable data structures and no side effects anywhere
in the semantics) that is strict.  It is also possible to have a
lazy language that *does* have side effects, see S for an example.
Purity and laziness are logically and practically independent.

To imply *EVERY* time that a function works by side effects is no kindness.

More information about the erlang-questions mailing list