- Haskell-Cafe - Haskell.org

RE: Survival of generic-classes in ghc
by Simon Peyton-Jones 21 Feb '02

21 Feb '02

| and I know from testing earlier versions that the | generic-classes support was pretty buggy. Is there any hope | of a revival? Does it already work in CVS? I suspect it will | rot away if nobody works on it. | | Any comments from the implementors - does the idea "fit well" | with ghc? Is it a lot of work to make it more stable? No, it should not be a lot of work to revive, and I will do it. Keep bugging me until I do. One thing that is slowing me down is a design uncertainty: how to deal cleanly with constructors. To write read, show, etc, one needs access to the constructor name, fixity etc. We dance around that a little in the paper. I'm thinking of this design: -- An example data type data List a = Nil | Cons a (List a) -- The "ring" type derived from it -- Note the Con wrapped around the constructors data ListO a = Con NilT 1 :+: Con ConsT (a :*: List a) -- Con is part of the Generics library, like 1, :*:, :+: newtype Con c a = Con a class ConCls c where name :: c -> String arity :: c -> Arity ..etc.. data NilT -- Phantom types data ConsT -- one per constructor instance ConCls NilT where name _ = "Nil" ...etc... instance ConCls ConsT wher name _ = "Cons" ...etc... Now you can write class Show a where show :: a -> String show {| Con c t |} (Con x) = (name (undefined::c)) ++ show x ...etc.. Note the "undefined::c"; it is really just a type argument to "name", so that we get the string for the right constructor. It's a bit clunky, though. Another possiblity would be to make the ConCls class look like this class ConCls c where name :: String arity :: Int ...etc... Now we'd have to give an explicit type argument at the call site: show {| Constr c t |} (Con x) = (name {| c |}) ++ show x I quite like the thought of being able to supply explicit type arguments.... but I don't konw how to speak about the order of type parameters. What order does map takes its two type parameters in? Another question is whether we need an indication that we have reached a field of the constructor. Should we have: data ListO a = Con NilT (Field 1) :+: Con ConsT (Field a :*: (Field List a)) newtype Field a = Field a Without this, it's hard to write a generic function to count the number of fields of the data type. But in general, one might want to know when making the transition from "this" type to the argument types of the constructors. I think that the main reason I'm not making much progress is that I don't know what design choices to make. I'd be glad to discuss it with interested parties. Simon

2 1

Re: a universal printer for Haskell?
by Bernard James POPE 20 Feb '02

20 Feb '02

Hi all, This thread started with the consideration of a means (hack?) to implement a generic printer in Haskell. It has moved to the bigger issue of Meta programming, in particular reflection. I think this is a topic worthy of consideration, and something we don't seem to talk much about in these groups. > Ashley Yakeley writes: > What I would hate to see is widespread use of reflection in general > programs. It rather seems to miss the point of Haskell's type system. I think the point of Haskell's type system varies depending on who you ask. The rules may be fixed to a certain degree in Haskell 98, but future versions of the language are free to change them. Meta programming is made more difficult when you have a strong static type system, no doubt. But is that a problem of meta programming or of the type system? This is a matter of opinion. Systems such as Meta ML [1], show that the two can be made compatible. I must admit that I haven't used Meta ML, so I'm not in a position to evaluate it, although it does make for some interesting research. My point is that there are some things that can't easily be expressed in current Haskell (like generic printing) that are useful and might be aided by meta-programming technology. The interesting question is can it be done in a way that preserves whatever we want from the type system: safety, security, efficiency, error detection ... > And I don't want other people peeking inside my types at run-time. There are numerous ways to provide security for your data types. You can specifically request that they not be made visible to the meta facility, or you can use a module system to grant access to the implementation of data only in certain modules. It does not have to be program wide. The scheme I suggested for generic printing was not as safe as you might like, but it was intended to be simple and easy to implement, and there is some merit in that I think. Cheers, Bernie.

3 2

Re: a universal printer for Haskell?
by C.Reinke 20 Feb '02

20 Feb '02

> You don't need meta-programming technology (reflection) to do things like > generic prinitng. A generic programming extension of Haskell (like > Generic Haskell, or derivable classes) can do the job for you. Isn't generic programming usually based on a kind of compile-time reflection (if the argument is of this type, do this, else..)? And don't you write generic functions with the intention that the implementation will figure out the approriate type-specific variants, i.e., you write your code at a level of abstraction that is not easily reached with the standard language tools -- a meta level, where functions at different types are the first-class objects of discourse? I find it helpful to think of generic programming support as one way of integrating well-behaved subsets of reflection and other meta-programming techniques into Haskell. It is partly a trade-off: you get some of the features and avoid some of the problems of a fully reflective architecture. It is also a specialisation: by avoiding the full generality, the specific subset of features can be designed in a structured fashion, with the application domain in mind, making them easier to use for that domain. Claus (another fan of reflection and meta-programming, who would like to get their advantages without their disadvantages -- the latter are more clearly visible in a pure functional language than in Lisp)

2 1

Re: a universal printer for Haskell?
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 22:46, Bernard James POPE wrote: >The scheme I suggested for generic printing >was not as safe as you might like, but it was intended to be simple >and easy to implement, and there is some merit in that I think. I strongly recommend you check out generic classes: <http://www.haskell.org/ghc/docs/latest/set/generic-classes.html> I suspect you can use them to do what you want... -- Ashley Yakeley, Seattle WA

2 1

Re: syntax...(strings/interpolation/here docs)
by C.Reinke 20 Feb '02

20 Feb '02

{- > Unlike my rough proposal, one should aim for a combination of > (mostly) in-Haskell implementation and (some) pre-processing. As > Thomas Nordin has pointed out to me in private email, Hugs (Dec > 2001) already supports this (module lib/hugs/Quote.hs and flag +H). > > The real trick is to have the same support in all implementations.. -} module HereDocuments where {- :set +H -} import Quote text = `` When I mentioned pre-processing, I didn't mean doing something to generate a Haskell program, I meant simple language extension (as in: syntactic sugar). It is nice that the Hugs variant of here documents is easily implemented with pre-processing, but that should be done behind the scenes. Usually, I wouldn't make such a fuss, but here documents are really not some new and experimental feature. They're an old hat, and a very useful hat. The only question is how to integrate them into the rest of Haskell. The Lewis/Nordin suggestion implemented in Hugs looks like a good compromise, but it won't do harm to bind the sugar to an option/flag for a test period. In the end, a stable form of here documents should be part of the language (not part of what you can do to it with whatever tools in whatever contexts), directly supported by all implementations. '' main = putStrLn $ trim text -- Claus

5 4

Re: a universal printer for Haskell?
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 20:50, Eray Ozkural wrote: >> It's ugly, and isn't part of the spirit of the language. > >The above statement cannot be a basis for any argument against Bernard's >proposal. It's an aesthetic argument that hopes for an aesthetic consensus among Haskell users (which may or may not exist). ... >Since you are defining the spirit of the language, Oh no, spirit cannot be defined, only suggested. ... >A general concept such as reflection cannot be deemed as worthless in >itself. It might reasonably be considered inappropriate to Haskell. Reflection may be useful for debugging, so I would not call it worthless. I consider reflection such as Generics to be in more or less the same aesthetic category as unsafe IO functions -- something to be generally avoided but perhaps useful in certain limited contexts such as debugging. I don't use Generics or unsafe-anything in my Haskell software. I _do_ occasionally use the 'deriving' construct, which is strictly speaking reflection though I think a relatively harmless form. What I would hate to see is widespread use of reflection in general programs. It rather seems to miss the point of Haskell's type system. >Any system that has a tiny bit of introspective powers can be said to be >reflective to some extent, for instance a Haskell interpreter. That's fine, but I don't include a Haskell interpreter in my compiled Haskell programs. And I don't want other people peeking inside my types at run-time. -- Ashley Yakeley, Seattle WA

1 0

Re: a universal printer for Haskell?
by Ashley Yakeley 20 Feb '02

20 Feb '02

At 2002-02-19 09:56, Richard Uhtenwoldt wrote: >>This is reflection! I'd rather not have Haskell contaminated with such >>things; > >Can you say a little more about why you think reflection is bad? >Does it make the language implementation run slower? It's ugly, and isn't part of the spirit of the language. You shouldn't be able to peer into types that way. If you decide to change the private structure of your types, you shouldn't have to worry about what effects it will have on the rest of the program. Consider: module A (Thing()) where { data Thing = MkThing Char; } module B where { import A; peek :: Thing -> Char; peek thing = (\(MApp _ (MChar c)) -> c) (reify thing); } B can look inside a private structure of A. The problem is not the Reify class, but the compiler's autogeneration of instances. >(I'd ask via private email, but when I emailed you in the past >I didn't get a reply.) That sounds like me... -- Ashley Yakeley, Seattle WA

2 1

Re: a universal printer for Haskell?
by Richard Uhtenwoldt 19 Feb '02

19 Feb '02

Ashley Yakeley writes: >This is reflection! I'd rather not have Haskell contaminated with such >things; Can you say a little more about why you think reflection is bad? Does it make the language implementation run slower? (I'd ask via private email, but when I emailed you in the past I didn't get a reply.)

1 0

performance of monads
by Eric Allen Wohlstadter 19 Feb '02

19 Feb '02

I see a lot of literature that says that monads "simulate" the effects of imperative programming concepts. It seems to me that the relative performance of monadic implementations must be equivalant to imperative ones to provide a strong case for functional programming. For example, in the Exception handling monad it seems that the "bind" function must be called continously to pass the Error value back to an error handling function. However, in imperative languages we can make an immediate non-local transfer of control. Similiar is the way State is handled. Do compilers for haskell do any sort of optimization on these monadic operations or is it all as ineffecient as it looks. Eric Wohlstadter UCDavis Software Tools Lab

12 11

Re: a universal printer for Haskell?
by Ch. A. Herrmann 19 Feb '02

19 Feb '02

Hi Haskellers, >>>>> "Bernard" == Bernard James POPE <bjpop(a)cs.mu.OZ.AU> writes: Bernard> Handling functions is always going to be hard. Actually, a Bernard> related issue in Haskell is what do you do with partially Bernard> evaluated structures? Certainly in some circumstances you Bernard> don't want to force the value just so that you can write it Bernard> out. sorry if I wasn't precise enough. I don't want to force ANY evaluation on the value to be marshalled; in some cases the computation may even not terminate! Instead, the string is an encoding of the smallest part of the heap that is necessary to restore the information. My aim is to save a state which contains unevaluated closures to disk and resume the computation at a later time or to send a state to a remote location. The nice property of a functional language, in contrast to imperative languages, is that you can make a snapshot of your computation without any support by the runtime environment if, of course, those (un)marshalling functions are available. Bernard> If you compiled to byte code, life would be a lot Bernard> easier, however everything will get a lot messier if you Bernard> want to mix machine code and byte code. urgh... The problem is to encode program functions, not just functions that arise during the computation. Compiling to byte code is a different issue. Bernard> It would be nice if you could write out some data to file from Bernard> GHC and then read it in using NHC :) That'll be very complicated and require a deep discussion about an interface language. Bernard> I think Clean has a prototype persistence mechanism, I saw Bernard> a short demo late last year. I'm not sure how they Bernard> represent functional values. I think you can only read the Bernard> data from within the same program that wrote the data. That would be OK for me. It would even be OK if it is the same binary, i.e., not to be used in heterogeneous networks. Anyway, I don't like to change my favourite programming language unless it's better than Haskell and that'll be very likely Haskell-II :-) Cheers -- Christoph

1 0