Re: Does ANSI Common Lisp have pattern matching?

Jon Harrop <jon@xxxxxxxxxxxxxxxxx> writes:

Kent M Pitman wrote:
Be careful here. In static languages, pattern matching encourages and
exploits abstraction, while in Lisp and other dynamic languages, it can
bypass intentional type and dispatch on representational type, which is
not always what is wanted.

Can you elaborate on this? Do you mean that pattern matching encourages you
to be less dynamic?

No, I wouldn't say that. But you must at least understand whether you
are dispatching on declared type or representational type. Lisp,
which does not use so-called "strong typing", doesn't know the
declared type of the data it receives; it knows the dynamically
accessible representational type. That's different and sometime may
have different effects.

If you're just dealing with data structures as pure shapes, it's fine.
But people have been known to create overlapping shapes. And if you
assume your pattern matcher will naturally sort that out, you're asking
for trouble. I'm not saying you have to not be a deep thinker to want
pattern matcher, but pattern matchers will attract those who are not
deep thinkers because they seem to involve less direct programming.

Assume these are three independent abstractions:

(defun make-simple-frob () 'frob)

(defun make-foo (x) (list 'foo x))

(defun make-frob (x) (list 'frob (list 'foo x)))

Now assume I do:

(pattern-case v
((frob (foo $x)) ...action...))

in some language where (frob $x) is the pattern with frob being a
constant term and $x being a pattern variable.

Then if I give v as the result of (list (make-simple-frob) (make-foo 3)),
should it match? If I give v as (make-frob 3) should it match? Are
you sure that (list (make-simple-frob) (make-foo 3)) and (make-frob 3)
are intended to be semantically the same?

It's hard to make a direct comparison to strongly typed languages, since
strongly typed languages often don't give you the ability to examine
representational tokens, and so the extra tokens like the 'foo and 'frob
in the examples above would not be there to confuse things. That makes
this comparison tricky. But the feature of such languages is that many
such languages can't confuse:
(pattern-case v
(frob($x) ...))
or
(pattern-case v
([bar, foo($x)] ...))
because the function wouldn't type-reconcile without knowing this.

Note well: You might assume punning is just bad and has no place in
programming, so you might say that such languages give you a leg up
and are automatically superior. I don't agree. While this particular
instance punning has some problems, there are cases where punning and
dynamic inspect gives you very sophisticated effects that are hard to
simulate in static languages.

Language choices are not about Good vs Bad, they are about design
trade-offs: you trade away the things you don't plan to do in favor of
the things you do plan to do. The hard part is getting that planning
right so you aren't pinned into a corner down the line. Since Lisp
supports changing one's mind later, I tend to like that, but it comes
at some occasional costs, and I think there's a minor but manageable
cost on the issue of clarity of intent on certain intentional type
issues. It's not a cost that troubles me because it buys other things
I care about. Static typing feels like a stranglehold to me. But
it's worth acknowledging that there are people who will be troubled by
these design trade-offs because they value things differently.

For other related issues, see my http://www.nhplace.com/kent/PS/EQUAL.html
.

Relevant Pages

  • Re: Design Patterns and Functional programming
    ... OCaml, Standard ML and Scala. ... Impurity is not required, as purely functional languages do exist, but it ... the model-view-controller design pattern. ... Then you can use pattern matching to manipulate ...
    (comp.object)
  • Universal Translators - undoing babel
    ... the hologram to encode it as a specific image. ... The interference pattern diffracts beams of light creating ... sound waves can be interfered and diffracted as well. ... sounded natural continuous and in each of our respective languages. ...
    (rec.arts.startrek.tech)
  • Re: Design Patterns and Functional programming
    ... OCaml, Standard ML and Scala. ... Impurity is not required, as purely functional languages do exist, but it ... this form of static checking requires the pattern matcher to be ... compiler use to parse literals of the type t, that is up to the compiler. ...
    (comp.object)
  • Re: Scheme closures
    ... It's these latter considerations that really limit syntax-rules. ... were writing the macro in a good way. ... > who uses argument pattern matching, ... I like the sort of pattern-matching used in functional languages ...
    (comp.lang.lisp)
  • Re: Design Patterns and Functional programming
    ... Impure functional programming languages like Mathematica, Lisp, Scheme, ... a pattern match gives yes/no ... What is the subject of matching. ... body of another function, here a constructor. ...
    (comp.object)