It is encouraging that separate groups have come to similar approaches
wrt to more modular pattern match facilities (though perhaps it isn't all
that surprising, eg, my own musings on this topic started after one of the
early functional logic programming high periods, in the early 1990s, and
have since been shaped by the developments in monadic and type class
programming in Haskell; PMC seems to have come from a rewriting
background, shaped by monadic semantics and type theory; these
would imply the same influences, moderated via different communities?).
There are, however, some differences that might be worth further
inspection. Referring to http://www.cas.mcmaster.ca/~kahl/PMC/ ,
and especially to the MPC 2006 paper, in no particular order, with
no claim to completeness (and please read comments like "odd" as
purely subjective, reflecting only my personal reactions as I'm trying
to figure out the relation!-):
- matchings are not first-class expressions in PMC
the only syntactically correct way to mention a matching in an expression
is inside a splice ( {| match |} ). this is fairly surprising given the aims of
PMC, as one would expect operations on matchings, matchings as
parameters and results of functions, etc. .. until one notices that not
only the operations on matchings, but
- *all* the interesting action in PMC is at the level of matchings,
not at the level of expressions
lambda-abstraction doesn't even exist at expression level, but is
replaced by spliced matching; application exists, but is not needed,
because (f e) = {| e |> {| f |} |} (unless I'm mistaken?)
if one eliminated the oddity of having two applications, but only
one abstraction, the category of expressions would be nearly
empty, apart from constructor terms, and the separation of
expressions and matchings seems needed only to support
conversions between the two:
{| _ |} :: Match -> Expression
^ _ ^ :: Expression -> Match
which directly brings up the next oddity, in that there are no such
types in PMC:
- the difference between matchings and expressions is maintained
in the typing contexts/labels, not in the types
in spite of the monadic semantics, there are no monads in the type
system, and instead of
.. |- pattern |> match :: a -> m b
(as Haskellers might expect to see), one has
.. |M- pattern |> match :: a -> b
I was looking into these details because I was trying to compare
lambda-match and PMC, and while most of the differences seemed
merely cosmetic at first, the one difference I couldn't account for was
that PMC examples seemed to imply an implicit flattening of the
monadic type structure, whereas I had to join nested lambda-matches
explicitly (I would find the ability to join nested matchings quite useful
on occasion, but I fail to see how this could be done implicitly/
automatically, unless by giving up the ability to express nested matches).
if I now understand all these items correctly in combination, PMC is
a flattened monadic framework, ie., one cannot even construct the
equivalent of a ( <nested> :: m (m a))? or am I missing the obvious?-)
cheers,
claus
ps. after reading the MPC 2006 paper, I have to support the referees'
recommendation: as one of many who only occasionally dive into
the most shallow parts of category theory, I don't find the monadic
semantics in its current presentation helpful. A "running commentary"
in computational lambda-calculus, as apparently suggested by the
referees, would have made all the difference (I think, because that
kind of presentation usually translates easily into Haskell;-). As it
stands, I fear you are limiting your audience needlessly.
--
<interactive>:1:0:-)
Couldn't match `Categories' against `Haskell'
Expected type: Haskell
Inferred type: Categories
In the first argument of `readPaper', namely `PMC_MPC2006'
In the definition of `it' : it = readPaper PMC_MPC2006
_______________________________________________
Haskell-prime mailing list
Haskell-prime@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-prime
