Arrays and Assoc

1993-10-05 Thread rabin

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

1993-05-18 Thread rabin

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,

Pattern-translation discussion

1993-05-17 Thread rabin

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!

1992-08-07 Thread Dan Rabin

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
  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
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