Re: if vs. when vs. and: style question

[Emanuel Berg]

Rusi <rustompmody@gmail.com> writes:

> Pattern-matching in modern FPLs would be more
> appropriate
>
> foo [] = bla foo (x:xs) = ble
>
> Can always be translated into
>
> foo l = if null l then bla else ble
>
> The reverse is of course not always possible But
> when pattern matching works its preferable to
> 'all-powerful' if-then-else
>
> Notice also that pattern matching is a mix of 3
> features that are usually separate -- 1. if 2.
> let 3. car/cdr ie selectors Separately those 3 are
> strictly more powerful than pattern matching And
> thats what makes pattern matching preferable (when
> it applies)

Aha - even more of the old functional programming
hysteria! Haskell, pattern matching... - are you sure
you are in the right newsgroup?

There is absolutely no rule that says "weak"
constructs are preferable, and especially not when
they are weak because they incorporate data that is
otherwise (in the "strong" version) readily available
to edit *as data* - i.e., exactly what it is.

Compare:

    (defun insert-hello ()
      (interactive)
      (insert-char ?h)
      (insert-char ?e)
      (insert-char ?l)
      (insert-char ?l)
      (insert-char ?o) )

    (insert-hello)

vs.

    (insert "hello")

Instead, the way to think is that the code should talk
both ways: it should tell the machine to do the
correct computation, all the while while showing and
indicating purpose to the person who writes and/or
reads the code!

For example, remember this example:

    (1+ data)

vs.

    (+ 1 data)

The "weak" vs. "strong" is the wrong way to think
about it.

In a discrete context, for example when iterating
a data structure or doing recursion, the `1+'
is preferable.

When just adding two data items, of which one happens
to be 1, the (+ 1 data) is better.

Perhaps that '1' will soon change. Big part of the
Lisp appeal is that it is so easy to change (tweak)
everything as you go along, in the light of experience
(which is often very recent), and then it goes on.

Or perhaps the '1' appears again in some other place
in the code, and when it does, the coder stops to
think, and it is concluded that it is the same data
item as the first one (ha) - i.e., both should be
replaced by an binding or variable...

-- 
underground experts united
http://user.it.uu.se/~embe8573