External Core
Dear fellow GHC users, For a number of years GHC has been equipped with the external core language. For those of you who are unfamiliar with this, it is a way to get GHC to emit or read in programs in a format which is very close to its internal intermediate language. This is for instance useful when you want to play with various optimisations. Currently external core is close to an orphan. Nobody is actively maintaining it and it is low on the GHC team's priority list. However, here at Chalmers we have two projects running which depends critically on external core. We have therefore volunteered to adopt external core and take responsibility for it. I will be the organiser of this effort. We are happy for the blessing from the GHC developers and for trusting us with this. We have a number of ideas on how we would like external core. But before putting up an agenda we would like to hear from all the people out there who uses external core. We would be very happy to hear who you are, what you are doing with external core and what changes you might want to see. I'm hoping that we together can work out an external core format which is useful for many people. Hoping to hear from you, /Josef Svenningsson, PhD student at Chalmers, External core tsar ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Problems with CABAL in GHC head.
Trying to recompile GHC (for the template-haskell existential support), but keeps failing on CABAL (the import for Foreign.Marshal.Alloc is missing from ghc/lib/compat/Distribution/Version.hs as well as import paths for Data/Version.hi which is not compiled yet as it depends on ghc-inplace. Keean. ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
RE: Problems with CABAL in GHC head.
There have been quite a few changes here including new directories. Make sure you cvs update with the -d flag, in both ghc/ and libraries/. And make sure all makefiles and autoconf stuff is up to date. then autoreconf and ./configure. Before doing make, go to ghc/driver and 'make clean'. Simon | -Original Message- | From: [EMAIL PROTECTED] [mailto:glasgow-haskell-users- | [EMAIL PROTECTED] On Behalf Of Keean Schupke | Sent: 15 November 2004 17:37 | To: [EMAIL PROTECTED] | Subject: Problems with CABAL in GHC head. | | Trying to recompile GHC (for the template-haskell existential support), but | keeps failing on CABAL (the import for Foreign.Marshal.Alloc is missing | from ghc/lib/compat/Distribution/Version.hs as well as import paths for | Data/Version.hi which is not compiled yet as it depends on ghc-inplace. | | Keean. | ___ | Glasgow-haskell-users mailing list | [EMAIL PROTECTED] | http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell] Re: Parameterized Show
Graham Klyne wrote (snipped): I like the principle of parameterizing Show to allow for different encoding environments (indeed, I had wondered as I was writing my earlier message if the two cases were really sufficient). Indeed, in the application area that interests me (Semantic Web) it could be beneficial to have different encoding options corresponding to different serializations of RDF (e.g. RDF/XML and Notation3). I like the idea too, not just for Show but for any instances. It seems to me that in general you should be able to combine the convenience of the Haskell type system with the power of Standard ML's structures and functors. Something along these lines was done by Kahl Scheffczyk (Named Instances for Haskell Type Classes, Haskell Workshop 2001). In general I suspect you can do this without even having to extend the existing Haskell typesystem very far. The following language extensions seem sufficient. (1) for a class declaration, a way of declaring that a certain type represents a dictionary of functions for that class, for example class Show a (ShowDict,appFn) where ... would define the new class Show but also the new type (ShowDict a) representing dictionaries for that class. It also declares a value appFn which I shall explain in a moment. (2) for an instance declaration, a way of naming the corresponding dictionary. instance Show Int (intShowDict) where would create a value intShowDict :: ShowDict Int (3) a way of using the dictionary. For this we need (appFn), declaraed by the type declaration. appFn has the unorthodox type appFn :: ShowDict a - (forall a . Show a = b) - b ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
Do you need a language extension at all? You can certainly do it with the existing extensions! data ShowDict a instance Show (ShowDict a) where showsPrec _ (ShowDict a) = ... Keean George Russell wrote: Graham Klyne wrote (snipped): I like the principle of parameterizing Show to allow for different encoding environments (indeed, I had wondered as I was writing my earlier message if the two cases were really sufficient). Indeed, in the application area that interests me (Semantic Web) it could be beneficial to have different encoding options corresponding to different serializations of RDF (e.g. RDF/XML and Notation3). I like the idea too, not just for Show but for any instances. It seems to me that in general you should be able to combine the convenience of the Haskell type system with the power of Standard ML's structures and functors. Something along these lines was done by Kahl Scheffczyk (Named Instances for Haskell Type Classes, Haskell Workshop 2001). In general I suspect you can do this without even having to extend the existing Haskell typesystem very far. The following language extensions seem sufficient. (1) for a class declaration, a way of declaring that a certain type represents a dictionary of functions for that class, for example class Show a (ShowDict,appFn) where ... would define the new class Show but also the new type (ShowDict a) representing dictionaries for that class. It also declares a value appFn which I shall explain in a moment. (2) for an instance declaration, a way of naming the corresponding dictionary. instance Show Int (intShowDict) where would create a value intShowDict :: ShowDict Int (3) a way of using the dictionary. For this we need (appFn), declaraed by the type declaration. appFn has the unorthodox type appFn :: ShowDict a - (forall a . Show a = b) - b ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
Keean Schupke wrote: Do you need a language extension at all? You can certainly do it with the existing extensions! data ShowDict a instance Show (ShowDict a) where showsPrec _ (ShowDict a) = ... I don't understand. How does that help you to, for example, use a function which requires Show Int but (say) substitute the standard function for which which shows in hexadecimal? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
George Russell wrote: I like the idea too, not just for Show but for any instances. It seems to me that in general you should be able to combine the convenience of the Haskell type system with the power of Standard ML's structures and functors. Something along these lines was done by Kahl Scheffczyk (Named Instances for Haskell Type Classes, Haskell Workshop 2001). [..] (3) a way of using the dictionary. For this we need (appFn), declaraed by the type declaration. appFn has the unorthodox type appFn :: ShowDict a - (forall a . Show a = b) - b I've wanted this too. Amongst other things, it would subsume all the fooBy functions in the prelude and libraries - instead of having both sort and sortBy, you could just build an Ord dictionary and pass it to sort. Note that there should be a way of creating a dictionary without creating an ordinary instance - in the OP's application, you would want two intShowDicts, one of which showed in decimal and the other of which showed in hex. In Haskell you can't have two instance declarations for the same type... --KW 8-) ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
Easy: data ShowHex a instance Show (ShowHex a) where showsPrec _ (ShowHex a) = showHex a main = putStrLn $ (show (ShowHex 27)) Here, with labelled instances you would write: show ShowHex 27 instead you write: show (ShowHex 27) Keean. George Russell wrote: Keean Schupke wrote: Do you need a language extension at all? You can certainly do it with the existing extensions! data ShowDict a instance Show (ShowDict a) where showsPrec _ (ShowDict a) = ... I don't understand. How does that help you to, for example, use a function which requires Show Int but (say) substitute the standard function for which which shows in hexadecimal? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
Of course if you want to do it to code independantly of type you need to redifine show: data ShowHex = ShowHex class ShowDict t a where showDict :: a - ShowS instance ShowDict ShowHex Int where showDict a = showHex a test :: ShowDict t a = t - a - ShowS test _ a = showDict a main = putStrLn $ (test ShowHex 27) Keean. Keean Schupke wrote: Easy: data ShowHex a instance Show (ShowHex a) where showsPrec _ (ShowHex a) = showHex a main = putStrLn $ (show (ShowHex 27)) Here, with labelled instances you would write: show ShowHex 27 instead you write: show (ShowHex 27) Keean. George Russell wrote: Keean Schupke wrote: Do you need a language extension at all? You can certainly do it with the existing extensions! data ShowDict a instance Show (ShowDict a) where showsPrec _ (ShowDict a) = ... I don't understand. How does that help you to, for example, use a function which requires Show Int but (say) substitute the standard function for which which shows in hexadecimal? ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
On Mon, Nov 15, 2004 at 12:31:33PM +, Keean Schupke wrote: Easy: Here, with labelled instances you would write: show ShowHex 27 instead you write: show (ShowHex 27) What about Ints buried deep in more complicated data structures: show ShowHex [[1, 2, 3], [4]] vs. show (map (map ShowHex) [[1, 2, 3], [4]]) BTW, This thread reminds me a similar problem that was discussed on haskell list. Unfortunately, there were some problems with this approach (accumulating typeclass contexts). http://www.haskell.org/pipermail/haskell/2004-August/thread.html#14427 Best regards, Tom -- .signature: Too many levels of symbolic links ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell] Re: Parameterized Show
George Russell wrote: I like the idea too, not just for Show but for any instances. It seems to me that in general you should be able to combine the convenience of the Haskell type system with the power of Standard ML's structures and functors. It looks like it would be easy, but it's very hard. The reason type classes work so well right now is that they have a straightforward interpretation as restrictions on the universe of quantification of a type variable. When we translate Haskell to System F, dictionaries come along for the ride as run-time representatives of types. If more than one dictionary is allowed per type, this correspondence breaks down, and all hell breaks loose as a result. We've already seen this happen with implicit parameters. In a program with implicit parameters: * Beta conversion no longer preserves semantics. * The monomorphism restriction is no longer a restriction: it sometimes silently changes the meaning of a program. * Adding type signatures for documentation is no longer safe, since they may silently change the behavior of the program. * It's not even safe in general to add a signature giving the same type that the compiler would infer anyway: there are (common) cases in which this too changes the program's meaning. I ran into this quite by accident the first time I tried to use implicit parameters, and it was enough to scare me away from ever trusting them again. Your proposal, simple though it seems, would extend all of these problems to type classes. Since it hasn't been mentioned yet I should also point people once again to Functional Pearl: Implicit Configurations by Oleg and Chung-chieh Shan, which ingeniously uses polymorphic recursion to construct type class instances at run time. If there's a safe and sane way to add local dictionaries to the language, it's probably along those lines. -- Ben ___ Haskell mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell
[Haskell] CfP reminder: LDTA 2005
[Reminder: deadline Dec. 1st is approaching] ** *** CALL FOR PAPERS *** ****** *** Fifth Workshop on *** *** Language Descriptions, Tools and Applications*** *** LDTA 2005 *** ****** *** Satellite event of ETAPS 2005*** *** April 3, 2005*** *** Edinburgh, Scotland, UK *** ****** *** http://www-i2.informatik.rwth-aachen.de/Events/LDTA2005/ *** ** SCOPE: The aim of this one-day workshop is to bring together researchers from academia and industry interested in the field of formal language definitions and language technologies, with a special emphasis on tools developed for or with these language definitions. This active area of research involves the following basic technologies: Program analysis, transformation, and generation Formal analysis of language properties Automatic generation of language processing tools For example, language definitions can be augmented in a manner so that not only compilers or interpreters can be automatically generated but also other tools such as syntax-directed editors, debuggers, partial evaluators, test generators, documentation generators, etc. Although various specification formalisms like attribute grammars, action semantics, operational semantics, and algebraic approaches have been developed, they are not widely exploited in current practice. It is the aim of the LDTA workshops to bridge this gap between theory and practice. Among others, the following application domains can benefit from advanced language technologies: Software component models and modeling languages Re-engineering and re-factoring Aspect-oriented programming Domain-specific languages XML processing Visualization and graph transformation Programming environments such as Eclipse, Rotor, SUN Java, etc. The workshop welcomes contributions on all aspects of formal language definitions, with special emphasis on applications and tools developed for or with these language definitions. INVITED SPEAKER: LDTA 2005 is going to feature an invited talk by Erik Meijer from Microsoft Research. SUBMISSION PROCEDURE AND PUBLICATION: Submission will be open from autumn 2004. Papers (of at most 15 pages) should be submitted electronically as (optionally compressed/gzipped) PostScript or PDF files to one of the program committee chairs. The message should also contain a text-only abstract and contact author information. Please use the ENTCS style available on the ENTCS Macro Home Page http://www.math.tulane.edu/~entcs/ for preparing your submission. Final versions of accepted papers must not exceed 20 pages and have to conform to the proceedings style. Accepted papers will be published and made available during the workshop. After revision, final copies of the accepted papers will be published in Electronic Notes in Theoretical Computer Science (ENTCS), Elsevier Science. Author's instructions are given here. The authors of the best papers will be invited to write a journal version of their paper which will be separately reviewed and, after acceptance, be published in a special issue devoted to LDTA 2005 of the journal Science of Computer Programming (Elsevier Science). PROGRAM COMMITTEE: John Boyland, University of Wisconsin-Milwaukee, USA (co-chair) [EMAIL PROTECTED] G?rel Hedin, Lund Institute of Technology, Sweden (co-chair) [EMAIL PROTECTED] Shigero Chiba, Tokyo Institute of Technology, Japan Jim Cordy, Queen's University, Kingston, Canada Susan L. Graham, University of California, Berkeley, USA Adrian Johnstone, University of London, UK Paul Klint, CWI, Amsterdam, The Netherlands Jens Knoop, Vienna University of Technology, Austria Eric Madeleine, INRIA, Sophia Antipolis, France Arnd Poetzsch-Heffter, University of Kaiserslautern, Germany Ganesh Sittampalam, Oxford University, UK Anthony Sloane, Macquarie University, Sydney, Australia Doaitse Swierstra, Utrecht University, The Netherlands Kris de Volder, University of British Columbia, Vancouver, Canada Andrew Wendelborn, University of Adelaide, Australia ORGANIZING COMMITTEE: Thomas Noll, RWTH Aachen University, Germany Joost Visser, University of Minho, Braga, Portugal Eric van Wyk, University of Minnesota, Minneapolis, USA IMPORTANT DATES: Submission deadline: December 1, 2004 Notification: January 17, 2005 Final version due:February 15, 2005 Workshop: April 3, 2005
[Haskell] package with ghc and ghci
Hello,
I have some packages for doing signal and image processing stuff.
Here is a little test program :
\begin{code}
module Main where
import Hips
a = listSignal (1,10) [1..10]
b = liftSignals (:+) a a
c = fft b
main = do
putStrLn $ show a
putStrLn $ show b
putStrLn $ show c
\end{code}
1/ Compiled with : ghc -package hips testFFT.hs
2/ interpreted with : ghci-package hips testFFT.h
1/ no problem
2/ dont execute and gives 'unknown package name: =Numeric' (Numeric is
another package called by Hips, included in HaskellDSP).
Any solution ?
Fred
___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] Pure Haskell Printf
(Sorry for the crosspost; I'm not sure which list this should go to.) I've just completed a pure-Haskell printf. Docs at [1], download at [2]. Here are some examples: vsprintf Hello Hello vsprintf Hello, %s\n John Hello, John\n vsprintf %s, your age is %d\n John (10::Integer) John, your age is 10\n sprintfAL %(name)s, your age is %(age)d\n [(name, v John), (age, v (10::Integer))] John, your age is 10\n I have more examples available at the doc page[1]. I used Ian Lynagh's Printf.Printer module to do the actual formatting (I converted it away from TH first). I got the idea for simulating handling variable numbers of function arguments from the haskell-xml-rpc code. I would appreciate comments/critiques. -- John [1] http://gopher.quux.org:70/devel/missingh/html/MissingH.Printf.html [2] http://gopher.quux.org:70/devel/missingh ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe
