Extensible Algebraic Data Types
I think it would be useful to extend Haskell so that one could create algebraic data types in one module that could be union-extended in another. Something like this: data Thing = CharThing Char | IntThing Int | _ ...later... data Thing |= StringThing String This would be useful for two reasons: 1. You could do something akin to dynamic typing without unreasonably stressing the ideas behind the Haskell type system: data BaseExtension = _ data Base = MkBase (Char,Int,BaseExtension) ...later... data Derived = MkDerived (Char,Int,Int,Int) data BaseExtension |= MkDerivedExtension (Int,Int) upcast :: Derived -> Base upcast (MkDerived (a,b,c,d)) = MkBase (a,b,MkDerivedExtension(c,d)) downcast :: Base -> Maybe Derived downcast MkBase (a,b,MkDerivedExtension(c,d)) = Just (MkDerived (a,b,c,d)) downcast MkBase (a,b,_) = Nothing 2. You'd have a way of autogenerating values similar to LISP's gensym: data Token = _ deriving Eq ...later... data Token |= ThisToken data Token |= ThatToken data Token |= BunchOfTokens Int Of course this extension to Haskell begs another, virtual or generic functions. I'm not sure how to do this properly while maintaining the principle that an expression has the same value regardless of other modules loaded. data Thing = CharThing Char | IntThing Int | _ f1 :: Thing -> Int f1 (CharThing c) = ord c f1 (IntThing i) = i -- somehow allow cases to be inserted later here f1 _ = 0 -- multiple dispatch f2 :: Thing -> Thing -> Int f2 (IntThing i) (IntThing j) = i + j -- might want cases inserted here, -- provided they don't cause trouble f2 (IntThing i) _ = i -- or here f2 _ (IntThing i) = i + 1 -- or here f2 _ _ = 0 Are these ideas something worth thinking about? Or would such extensions compromise important principles behind Haskell? -- Ashley Yakeley, Seattle WA ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: strictness question
Strange. You don't supply a complete program, so it's hard to test. Nevertheless, the Haskell Report (Sect 3.12) specifies that a let adds a single twiddle. Thus let (x, (y,z)) = e in b means let x = case e of (x,(y,z)) -> x y = case e of (x,(y,z)) -> y z = case e of (x,(y,z)) -> z in b And that is what GHC implements. You get something different if you add twiddles inside: let (x, ~(y,z)) = e in b means let x = case e of (x,_) -> x y = case e of (_,(y,_)) -> y etc Adding more twiddles means less eager matching. I don't know whether Hugs implements this. Simon | -Original Message- | From: S. Doaitse Swierstra [mailto:[EMAIL PROTECTED]] | Sent: 01 March 2001 11:26 | To: [EMAIL PROTECTED] | Subject: strictness question | | | I ran into a difference between GHC and Hugs. The following code: | | f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = | p (q k) inp |in (((pv qv , r ), m), st)) | | runs fine with Hugs but blows up with GHC, whereas: | | f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), | st) = p (q k) inp |in (((pv qv , r ), m), st)) | | runs fine with GHC too. | | From the Haskell manual I understand that pattern matching | in "let"'s | should be done lazily, so the addition of a collection of ~'s should | not make a difference. Am I right with this interpretation? | | A possible source of this problem may be origination from the smarter | GHC optimiser, but in that case the optimiser is not doing its work | well. | | Doaitse Swierstra | | | | | -- | __ | | S. Doaitse Swierstra, Department of Computer Science, Utrecht | University |P.O.Box 80.089, 3508 TB UTRECHT, the | Netherlands |Mail: mailto:[EMAIL PROTECTED] |WWW: http://www.cs.uu.nl/ |PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Announce: Mysql-HS 0.10.0
MySQL-HS is an interface to the MySQL database. This is a maintaince release. Changes: - Ported to GHC 4.08 and H/Direct 0.17 - Inproved documentation - General polishment This version is considered to be stable. If there don't show any bugs, the next version will be 1.0.0 and probably the conclusive one. (Except for support of new versions of GHC, H/Direct, MySQL). The homepage is at http://www.volker-wysk.de/mysql-hs ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
question re hugs and func dependencies
Dear all, I haven't got a reply from hugs-bugs, so I'll see if anyone here can answer the question. class foo a b | a |-> b where foo :: a -> b -> Int instance foo Int Float where foo x y = 0 instance foo [a] [b] where foo [x] [y] = foo x y g x y = (foo [x] y) + (foo [y] x) It is my conjecture that Hugs terminates on type-checking g because of a depth bound in the type-checker (although there is no indication from the type-checker that this is what is going on). Can anyone confirm or refute this conjecture? FWIW this is as part of the related work section for a paper that has been accepted to JFP: "Type-Checking Multi-Parameter Type Classes," by D. Duggan and J. Ophel. I'd appreciate cc-ing any replies to me, I'm not sure that I'm still on this mailing list. Cheers --dd begin:vcard n:Duggan;Dominic tel;fax:(201) 216-8249 tel;work:(201) 216-8042 x-mozilla-html:FALSE url:http://guinness.cs.stevens-tech.edu/~dduggan/index.html org:Stevens Institute of Technology;Computer Science version:2.1 email;internet:[EMAIL PROTECTED] title:Associate Professor note:Web page: http://guinness.cs.stevens-tech.edu/~dduggan/index.html adr;quoted-printable:;;Department of Computer Science=0D=0AStevens Institute of Technology;Hoboken;New Jersey;07030;USA x-mozilla-cpt:;10656 fn:Dominic Duggan end:vcard
Re: strictness question
On Fri, Mar 02, 2001 at 06:58:16PM +, Marcin 'Qrczak' Kowalczyk wrote: > Toplevel ~ in let doesn't change anything. But nested ~'s do make > a difference. When a variable of a pattern is evaluated, the whole > pattern is matched. When you protect a subpattern by ~ deferring its > matching and a variable from the subpattern is evaluated, again the > whole subpattern is matched, unless its subsubpatterns are protected > with their own ~'s etc. Is the behaviour of Hugs incorrect in this case? Best, Dylan Thurston ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
RE: strictness question
Thanks for the prompt reply. Hugs apparently is more lazy and performs all the matching lazily, and that really makes a difference in my case. Doaitse At 8:11 AM -0800 3/2/01, Simon Peyton-Jones wrote: >Strange. You don't supply a complete program, so it's hard to >test. > >Nevertheless, the Haskell Report (Sect 3.12) specifies that >a let adds a single twiddle. Thus > > let (x, (y,z)) = e in b > >means > > let x = case e of (x,(y,z)) -> x >y = case e of (x,(y,z)) -> y >z = case e of (x,(y,z)) -> z > in b > >And that is what GHC implements. You get something different if you >add twiddles inside: > > let (x, ~(y,z)) = e in b > >means > let x = case e of (x,_) -> x >y = case e of (_,(y,_)) -> y > etc > >Adding more twiddles means less eager matching. I don't know whether >Hugs implements this. > >Simon > >| -Original Message- >| From: S. Doaitse Swierstra [mailto:[EMAIL PROTECTED]] >| Sent: 01 March 2001 11:26 >| To: [EMAIL PROTECTED] >| Subject: strictness question >| >| >| I ran into a difference between GHC and Hugs. The following code: >| >| f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = >| p (q k) inp >|in (((pv qv , r ), m), st)) >| >| runs fine with Hugs but blows up with GHC, whereas: >| >| f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), >| st) = p (q k) inp >|in (((pv qv , r ), m), st)) >| >| runs fine with GHC too. >| >| From the Haskell manual I understand that pattern matching >| in "let"'s >| should be done lazily, so the addition of a collection of ~'s should >| not make a difference. Am I right with this interpretation? >| >| A possible source of this problem may be origination from the smarter >| GHC optimiser, but in that case the optimiser is not doing its work >| well. >| >| Doaitse Swierstra >| >| >| >| >| -- >| __ >| >| S. Doaitse Swierstra, Department of Computer Science, Utrecht >| University >|P.O.Box 80.089, 3508 TB UTRECHT, the >| Netherlands >|Mail: mailto:[EMAIL PROTECTED] >|WWW: http://www.cs.uu.nl/ >|PGP Public Key: >http://www.cs.uu.nl/people/doaitse/ >tel: +31 (30) 253 3962, fax: +31 (30) 2513791 >__ > >___ >Haskell mailing list >[EMAIL PROTECTED] >http://www.haskell.org/mailman/listinfo/haskell -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: Pattern guards vs. case (was, unfortunately :Re: interesting example of laziness/ghc optimisation)
Thu, 1 Mar 2001 20:25:28 +0900 (KST), Laszlo Nemeth <[EMAIL PROTECTED]> pisze:
> > Prelude> let f x | Just _ == x = 0 in f (Just 4)
> > ERROR: Illegal `_' in expression
>
> So it works with (Just 4), but it doesn't with (Just _)?
'Just _ == x' must be an exppression. '_' is a pattern but not an
expression.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
Re: strictness question
Thu, 1 Mar 2001 12:25:33 +0100, S. Doaitse Swierstra <[EMAIL PROTECTED]> pisze:
> From the Haskell manual I understand that pattern matching in "let"'s
> should be done lazily, so the addition of a collection of ~'s should
> not make a difference.
Toplevel ~ in let doesn't change anything. But nested ~'s do make
a difference. When a variable of a pattern is evaluated, the whole
pattern is matched. When you protect a subpattern by ~ deferring its
matching and a variable from the subpattern is evaluated, again the
whole subpattern is matched, unless its subsubpatterns are protected
with their own ~'s etc.
--
__("< Marcin Kowalczyk * [EMAIL PROTECTED] http://qrczak.ids.net.pl/
\__/
^^ SYGNATURA ZASTÊPCZA
QRCZAK
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
strictness question
I ran into a difference between GHC and Hugs. The following code: f (P p) ~(P q) = P (\ k -> \inp -> let (((pv, (qv, r)), m), st) = p (q k) inp in (((pv qv , r ), m), st)) runs fine with Hugs but blows up with GHC, whereas: f (P p) ~(P q) = P (\ k -> \inp -> let ~(~(~(pv, ~(qv, r)), m), st) = p (q k) inp in (((pv qv , r ), m), st)) runs fine with GHC too. From the Haskell manual I understand that pattern matching in "let"'s should be done lazily, so the addition of a collection of ~'s should not make a difference. Am I right with this interpretation? A possible source of this problem may be origination from the smarter GHC optimiser, but in that case the optimiser is not doing its work well. Doaitse Swierstra -- __ S. Doaitse Swierstra, Department of Computer Science, Utrecht University P.O.Box 80.089, 3508 TB UTRECHT, the Netherlands Mail: mailto:[EMAIL PROTECTED] WWW: http://www.cs.uu.nl/ PGP Public Key: http://www.cs.uu.nl/people/doaitse/ tel: +31 (30) 253 3962, fax: +31 (30) 2513791 __ ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
WRS'2001 - Extended deadline
[Apologies for multiple copies of this announcement] ** *** Last call for papers - extended deadline: March 12, 2001 *** ** International Workshop on Reduction Strategies in Rewriting and Programming (WRS 2001) held in conjunction with RTA 2001 Utrecht, The Netherlands, May 26, 2001 -- BACKGROUND AND AIMS Reduction strategies in rewriting and programming have attracted an increasing attention within the last years. New types of reduction strategies have been invented and investigated, and new results on rewriting / computation under particular strategies have been obtained. Research in this field ranges from primarily theoretical questions about reduction strategies to very practical application and implementation issues. The need for a deeper understanding of reduction strategies in rewriting and programming, both in theory and practice, is obvious, since they bridge the gap between unrestricted general rewriting (computation) and (more deterministic) rewriting with particular strategies (programming). Moreover, reduction strategies provide a natural way to go from operational principles (e.g., graph and term rewriting, narrowing, lambda-calculus) and semantics (e.g., normalization, computation of values, infinitary normalization, head-normalization) to implementations of programming languages. Therefore any progress in this area is likely to be of interest not only to the rewriting community, but also to neighbouring fields like functional programming, functional-logic programming, and termination proofs of algorithms. The workshop wants to provide a forum for the presentation and discussion of new ideas and results, recent developments, new research directions, as well as of surveys on existing knowledge in this area. Furthermore we aim at fostering interaction and exchange between researchers and students actively working on such topics. The workshop will be held in conjunction with RTA 2001 in Utrecht (The Netherlands) on May 26, 2001. It will feature 2 invited talks, a panel discussion, and contributed presentations selected from the submissions, with ample time for discussion. The workshop is (co-)organized by U Utrecht, TU Valencia and TU Wien. TOPICS OF INTEREST Topics of interest include, but are not restricted to, - theoretical foundations for the definition and semantic description of reduction strategies - strategies in different frameworks (term rewriting, graph rewriting, infinitary rewriting, lambda calculi, higher order rewriting, conditional rewriting, rewriting with built-ins, narrowing, constraint solving, etc.) and their application in (equational, functional, functional-logic) programming (languages) - properties of reduction strategies / computations under strategies (e.g., completeness, computability, decidability, complexity, optimality, (hyper-)normalization, cofinality, fairness, perpetuality, context-freeness, neededness, laziness, eagerness, strictness) - interrelations, combinations and applications of reduction under different strategies (e.g., equivalence conditions for fundamental properties like termination and confluence, applications in modularity analysis, connections between strategies of different frameworks, etc.) - program analysis and other semantics-based optimization techniques dealing with reduction strategies - rewrite systems / tools / implementations with flexible / programmable strategies as essential concept / ingredient - specification of reduction strategies in (real) languages - data structures and implementation techniques for reduction strategies. SUBMISSIONS We solicit papers on all aspects of reduction strategies in rewriting and programming. Submissions should describe unpublished work, except for survey papers which are explicitly welcome, too. Submissions should not exceed 10 pages (however, survey papers may be longer) and be sent in postscript format to the PC co-chairs ([EMAIL PROTECTED]) by March 12, 2001. Selection of papers by the PC will be based on originality, significance, and correctness. Accepted papers will be included in the workshop proceedings that will be available at the workshop, and electronically on the web. Depending on the number and quality of submissions, formal publication of the proceedings is envisaged. Researchers just interested in attending the workshop may send a corresponding email to [EMAIL PROTECTED] by March 12, 2001, preferably together with a brief position paper (up to two pages in postscript) describing their interest and/or work in the area. However, we will also consider late requests for attendance. INVITED TALKS Sergio Antoy (U Portland State): Evaluation Strateg
