Arrays and Assoc
John Launchbury makes the suggestion, inter alia, that Haskell 1.3 `should get rid of Assoc.' Reading some of the followup messages, I see that there is some division on this point. Those closer to the scientific applications community, such as Nikhil and Joe Fasel's acquaintances, seem to be warmed by the familiar sight of `:=', whereas the more pure-mathematically motivated commentators seem to find the (assuredly equivalent) pair constructor more congenial. There have also been some noises about compatibility, since adopting John's suggestion will definitely stop old code dead in its tracks (namely, in the type-checker). Clearly, what's needed to satisfy all parties and make Haskell 1.3 the rousing success that it deserves to be is to introduce a class `Associator' with methods `key', `image', `associate', `toPair', `toAssoc'. Then the array prelude functions could be redefined in terms of the class by (1) pattern-matching on `toAssoc assoc' instead of `assoc' for each variable assoc :: Assoc, and (2) replacing explicit applications of the constructor `:=' by `associate'. I don't think user code would have to change, but users might wonder about the new inferred type constraints on their array code. Of course, to recover efficiency, all Haskell implementors will have to treat the class `Associator' specially so that no dictionary usage is actually produced (as long as the users haven't perversely introduced their own instances, which suggests some wondrous new interpretations of the concept `array'). I intended this message to be humorous when I started, but I'm beginning to think this is a reasonable approach to such matters. So let's generalize with wild abandon: what would be the consequences of automatically deriving an class abstraction for _every_ Haskell data type? Even function types are eligible via the abstract operation `apply'. What new vistas now unfold? - Dan Rabin I must Create a System Department of Computer Scienceor be enslav'd by another Man's. P.O. Box 208285 I will not Reason Compare: New Haven, CT 06520-8285 my business is to Create. [EMAIL PROTECTED] -- William Blake, `Jerusalem' -
n+k patterns
Phil Wadler says: You are quite right. I'd forgotten about local rebinding, because I feel that all local rebinding should be disallowed. Anyone want to start a movement to eliminate local rebinding? (1/2 :-) Cheers, -- P And *I* think we should stop using names altogether and program in terms of SKI combinators! Since these constructs have well-known, unchanging meanings there is little chance that a program will be misunderstood*. I don't know about the rest of the people reading this, but I find the notation S(S(S(KS)K))((S(S(KS)K))(KI)) = (S(S(KS)K))(S(S(KS)K))(KI) to be much more precise than the n+k equivalent, 1 + 1 = 2. The similarity of the latter notation to the informal numerals of everyday life is an open invitation to sloppy reasoning leading to widespread program bugs. Besides, anybody who can't handle needless complexity shouldn't be fooling around with dangerous machines such as computers. -- Dan Rabin ([EMAIL PROTECTED]) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) :-) *in fact, there is little chance that a program will be understood, period.
Pattern-translation discussion
Lennart Augustsson has just posted a couple of queries concerning the Haskell Report's transformations for defining the semantics of pattern-matching constructs. His questions are of the following form: In the RHS of the translation, does symbol `X' refer to its meaning in the canonical module PreludeCore, or its meaning in the context of the translated expression? I think it's pretty clear (from cultural understanding, not from the Report) that the former meaning is intended, so I assume that the question is really `How could the Report make this intention clear?' It's probably easiest just to insert a sentence explaining the convention to be observed, but it may be worth noting that the Lisp community has ample experience with this issue. In most Lisps, syntactic translation (macro definition) is part of the language, not the metalanguage. Thus, avoiding or requesting name-capture in macro-expansions is a user-level issue, requiring attention on the part of language-feature designers. A good place to start reading about this subject is the appendix on macros in the Revised^4 Report on Scheme. -- Dan Rabin ([EMAIL PROTECTED])
The need for C.A.T.S.U.P. lives on!
It's time to repost the following, with no hard feelings towards the participants in the current discussion about the never-ending sense of wonder and astonishment that Haskell's concrete syntax inspires in even the most jaded programmer. Brought to you by Haskell, a founding member language of the League for Avoiding Waste in Character Set Usage. Our motto: a meaning for every squiggle, and two squiggles for every meaning! [Originally transmitted 13 March 1991] :-) Are you tired of your precious mail-reading time being usurped for the nitpicking discussion of Haskell operator precedence minutiae? :-) Are you itching to get back to the careful study of the design and implementation of programming language CAPABILITIES? :-) Are you concerned that this debilitating disunity among the prophets of the TRUE FUNCTIONAL RELIGION may be the work of agents-provocateurs in the service of the EVIL IMPERATIVE EMPIRE? :-) Then don't just sit there passively--join C.A.T.S.U.P., the Committee Advocating The Superstitious Use of Parentheses! :-) C.A.T.S.U.P. is a new political action coalition being convened around a nucleus of Old Lisp Hands, Moderate Pragmatists, and Abstract Thinkers Who Are Above Thinking About Concrete Syntax. C.A.T.S.U.P.'s objective is to restore the functional programming community to full research productivity by advocating the adoption of the following credo: :-) Inference Rule 1) If you can't remember the operator precedence, Then put in some extra parentheses. :-) Inference Rule 2) If you thought you had the precedence right, but the computation did not proceed as expected, Then put in some extra parentheses and try again. :-) Axiom A) Nobody remembers operator precedences. :-) Lemma: Some extra parentheses will be put in, no matter how carefully the operator precedence is designed (provided, of course, that some infix operators are used at all). Proof: Immediate from Axiom A and Inference Rule 1. :-) -- -- Dan Rabin, Old Lisp Hand, Moderate Pragmatist, and Abstract-Thinker-Who's-Above-Thinking-About-Concrete-Syntax-in-training.
