[ ghc-Bugs-1303232 ] parse error on input `\' when using -cpp
Bugs item #1303232, was opened at 2005-09-24 14:25 Message generated for change (Tracker Item Submitted) made by Item Submitter You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1303232group_id=8032 Please note that this message will contain a full copy of the comment thread, including the initial issue submission, for this request, not just the latest update. Category: None Group: None Status: Open Resolution: None Priority: 5 Submitted By: Peter (peter26) Assigned to: Nobody/Anonymous (nobody) Summary: parse error on input `\' when using -cpp Initial Comment: When compiling code like: infixl 9 \ (\) = undefined causes a parser error, when compiling with the -cpp option -- You can respond by visiting: https://sourceforge.net/tracker/?func=detailatid=108032aid=1303232group_id=8032 ___ Glasgow-haskell-bugs mailing list Glasgow-haskell-bugs@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-bugs
[Haskell] Object-Orientation and Haskell
Here's a simple test for object orientation (for some reasonable definition): Define a type A such that for any type B you can define up :: B - A down :: A - Maybe B such that down . up = Just You can do this quite easily in Java or C++, mutatis mutandis. You can't do this in Haskell, I don't think. You can't actually do this in O'Haskell either, it seems the O' essentially amounts to syntactic sugar. You can do a weaker form of this with Haskell's Dynamic, where you only have to deal with Bs that are instances of Typeable. But even with that, note that Dynamic/Typeable/TypeRep are a bit messy, with instances for Typeable defined for a wide range of known types. An alternative approach would be to identify your B within A not per-B but per-(up,down). This would allow for instance separate (up,down) for the same B such that down1 . up2 = Nothing down2 . up1 = Nothing Of course this can be done with Dynamic too, by defining dummy types. But it's ugly. A better extension is something like extensible data-types. This allows a type to be defined as open, which can later be extended by disjoint union. Here's a sample syntax that achieves my OO test: module P where data A = .. module Q where import P A |= MkB B up = MkB down (MkB b) = Just b down _ = Nothing Actually, it is possible to define Dynamic in this way. Here's a naive attempt: data Dynamic = .. class Typeable' a where toDyn :: a - Dynamic fromDynamic :: Dynamic - Maybe a -- for each type... Dynamic |= MkBool Bool instance Typeable' Bool where toDyn = MkBool fromDynamic (MkBool b) = Just b fromDynamic _ = Nothing This attempt however doesn't allow easy creation of Typeable1, Typeable2 etc. A better way is to use type-constructor parameters: data Dynamic0 (f :: * - *) = .. data Dynamic1 (g :: (* - *) - *) = .. type Dynamic = Dynamic0 Identity data Type a = MkType type TypeRep = Dynamic0 Type class Typeable0 a where toDyn0 :: f a - Dynamic0 f fromDynamic0 :: Dynamic0 f - Maybe (f a) class Typeable1 p where toDyn1 :: g p - Dynamic1 g fromDynamic1 :: Dynamic1 g - Maybe (g p) data Compose p q a = MkCompose (p (q a)) data Compose1 d0 f p = MkCompose1 (d0 (Compose f p)) Dynamic0 f |= MkDynamic1 (Dynamic1 (Compose1 Dynamic0 f)) unDynamic1 :: Dynamic0 f - Maybe (Dynamic1 (Compose1 Dynamic0 f)) unDynamic1 (MkDynamic1 xx) = Just xx unDynamic1 _ = Nothing instance (Typeable1 p,Typeable0 a) = Typeable0 (p a) -- toDyn0 :: f (p a) - Dynamic0 f toDyn0 = MkDynamic1 . toDyn1 . MkCompose1 . toDyn0 . MkCompose -- fromDynamic0 :: Dynamic0 f - Maybe (f (p a)) fromDynamic0 dyn = do dcdf - unDynamic1 dyn (MkCompose1 dcfp) - fromDynamic1 dcdf (MkCompose fpa) - fromDynamic0 dcfp return fpa -- for each type Dynamic0 f |= MkInt (f Int) instance Typeable0 Int where toDyn0 = MkInt fromDynamic0 (MkInt fi) = Just fi fromDynamic0 _ = Nothing Dynamic1 g |= MkMaybe (g Maybe) instance Typeable1 Maybe where toDyn1 = MkMaybe fromDynamic1 (MkMaybe gm) = Just gm fromDynamic1 _ = Nothing I submit that this is hairy rather than ugly, but I suspect the Type-Constructors Of Unusual Kind (TCOUKs) get even hairier for Typeable2, Typeable3 etc... -- Ashley Yakeley, Seattle WA ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
RE: [Haskell] Object-Orientation and Haskell
Define a type A such that for any type B you can define up :: B - A down :: A - Maybe B such that down . up = Just You can do this quite easily in Java or C++, mutatis mutandis. You can't do this in Haskell, I don't think. You can't actually do this in O'Haskell either, it seems the O' essentially amounts to syntactic sugar. You can't even do this in OCaml. However, in OOHaskell you can. From the TOC of the OOHaskell paper http://homepages.cwi.nl/~ralf/OOHaskell/ 5.4 Casts based on dynamics 50 5.5 Casts based on unions 51 The second technique may add something to this discussion here. We use a sort of intersection-type encoding (also reminiscent of TICs). Thanks, Ralf ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell] *** ICFP '06 CALL FOR WORKSHOP PROPOSALS ***
ICFP '06 CALL FOR WORKSHOP PROPOSALS The ICFP 2006 ACM SIGPLAN International Conference on Functional Programming will be held in Portland, Oregon from September 18 to September 20, 2006. Proposals for workshops are invited for consideration of ACM SIGPLAN sponsorship and affiliation with ICFP 2006. Affiliated workshops will be held on September 16 and 17 (as well as on September 21, if necessary). The purpose of these workshops is to provide a forum for presenting novel ideas in a less formal and possibly more focused way than at ICFP itself. They may also provide good opportunities for young researchers to present their work to, and to obtain feedback from, a specialized community. The format of each workshop is to be determined by its organizers, but it is expected that each workshop allows ample time for general discussion. The preference is for workshops which span only one day, but other schedules will also be considered. Researchers and practitioners are invited to submit workshop proposals to the ICFP 2006 Workshop Chairs, Matthias Blume and Patricia Johann, via e-mail ([EMAIL PROTECTED]), NO LATER THAN NOVEMBER 11, 2005. Submission may be made by e-mail (Postscript, PDF, or ASCII) with ICFP06 Workshop Submission in the subject header. Following ACM SIGPLAN's sponsorship procedures, proposals must include: 1. The name of the workshop. 2. A statement of goals for the workshop. 3. The names and addresses of the organizers. 4. The names of potential participants, such as program committee members. (It would be wise to inform your potential comittee members that they have been selected pending SIGPLAN approval.) 5. A description of plans for calls for participation (e.g., calls for papers). 6. The expected number of attendees and planned length of the workshop. 7. A description of plans for publicity. 8. An explanation of any plans for a published proceedings. 9. A description of past versions of the workshop, including dates, organizers, submission and acceptance counts, attendance, sites, registration fees and summary budget information. 10. The URL of the workshop web site. Note that should a proposal be accepted, a final report about the workshop, suitable for publication in SIGPLAN Notices, will be required. Notification of acceptance will be made by DECEMBER 15, 2005. Accepted workshops will be sponsored by SIGPLAN (see http://www.acm.org/sigplan/sigplan_workshop_proposal.htm for more information). A committee chaired by the ICFP 2006 Workshop Chairs and consisting of the ICFP Program and General Chairs and the SIGPLAN Executive Committee will evaluate all proposals. The workshop selection committee members are: * Matthias Blume, TTI-Chicago, Workshop co-Chair for ICFP 2006 * Patricia Johann, Rutgers University, Workshop co-Chair for ICFP 2006 * Julia Lawall, DIKU, Program Chair for ICFP 2006 * John Reppy, University of Chicago, General Chair for ICFP 2006 The maximum number of workshop proposals to be accepted is 6. Any further information needed for preparing a workshop proposal can be obtained by sending email to the workshop chairs ([EMAIL PROTECTED]) or consulting the ICFP 2006 web site at http://icfp06.cs.uchicago.edu/. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] RE: Typing problems with basic arithmetic - help!
For some reason the following code is producing an error message from ghci that the the patterns are non-exhaustive. Does anyone have any idea why that could be, given that the patterns are, at least in my meaning, provably exhaustive? You forgot to match against the empty list. Try adding choosenonuniqueset n [] = [] -Chad Scherrer ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
