[Haskell] Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Great! Are there any chances of getting support for non-Win32 platforms with Mono? On Fri, Oct 10, 2008 at 2:12 PM, Andrew Appleyard [EMAIL PROTECTED] wrote: I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine (Hello .NET World!) type Hello.imports System.Console: WriteLine msbuild .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew ___ Haskell-Cafe mailing list [EMAIL PROTECTED] http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] ANNOUNCE: Salsa: A .NET Bridge for Haskell
Great! Are there any chances of getting support for non-Win32 platforms with Mono? On Fri, Oct 10, 2008 at 2:12 PM, Andrew Appleyard [EMAIL PROTECTED] wrote: I'd like to announce the first release of Salsa, an experimental Haskell library that allows Haskell programs to access .NET libraries. Here's a taste: type Hello.hs import Foreign.Salsa import Bindings main = withCLR $ do _Console # _writeLine (Hello .NET World!) type Hello.imports System.Console: WriteLine msbuild .\hello Hello .NET World! Salsa operates by loading the .NET runtime into your Haskell process and using the FFI (and run-time code generation) to marshall calls between the .NET and Haskell runtimes. It includes a code generator and a type-level library (which uses type families) to provide type-safe access to .NET libraries in Haskell with C#-style method overload resolution and implicit conversions. The adventurous can find version 0.1.0.1 of Salsa on Hackage [1], the darcs repository on code.haskell.org [2], and some (limited) documentation on the Haskell wiki [3]. The library is experimental and by no means complete (refer to the wiki page [3] for some of its limitations). Be prepared to end up with incomprehensible error messages and/or a broken compiler! :-) At the moment you'll need Windows, GHC 6.8, and version 3.5 of the .NET Framework to use it. Have fun! [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/Salsa [2] http://code.haskell.org/Salsa [3] http://haskell.org/haskellwiki/Salsa -- Andrew ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal: error on configure
On Tue, Oct 7, 2008 at 9:50 PM, David Barton [EMAIL PROTECTED] wrote: OK, I suspect this is a real newbie error, but please have mercy. I have downloaded and installed cabal (at least it responds to the --help command from the command line). Yet when I do, say (to give a real example): cabal configure parameterized_ data It's great to read that you are using the parameterized-data package. If you have any questions on its use, or have any suggestions, don't hesitate to ask. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: breakage with Cabal-1.6
On Thu, Oct 9, 2008 at 8:55 PM, Duncan Coutts [EMAIL PROTECTED] wrote: * ForSyDe-3.0 Uses the copyDest field from CopyFlags. These record types now use an equivalent of Maybe so they can be empty rather than always containing a default value. It's useful, but also kind of annoying in places. It's an easy fix. If possible at all, what would be the best way to make it compatible with both versions of CopyFlags? Thanks ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Libraries in home dir
On Thu, Oct 9, 2008 at 3:08 PM, Mauricio [EMAIL PROTECTED] wrote: I want to use a few libraries from hackage and have already download and built them. Can I install those libraries somewhere in my home dir (I want to avoid installing as root) so that ghc can find them? Sure, just write: runhaskell Setup.hs configure --user --prefix=personal/directory/where/to/install/the/package --user tells cabal to install the package in the user package-database You might want to use cabal-install [1] in order to automatize the insallation of Cabal packages. By default it uses the --user flag and copies the package files under $HOME/.cabal/. Important caveat: Make sure to also supply the --user flag when compiling other packages which depend on your library. Otherwise Cabal will only look for it in the global package-dabatase and won¡t be able to find it. [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/cabal-install ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] is the a way to reinstall a package with cabal install?
cabal install --reinstall On Thu, Oct 9, 2008 at 6:42 PM, Anatoly Yakovenko [EMAIL PROTECTED] wrote: is the a way to reinstall a package with cabal install? I want to add profiling support to a libarary. Thanks, Anatoly ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell] Announce: Yi 0.5.0.1
On Wed, Oct 8, 2008 at 1:10 PM, Jean-Philippe Bernardy [EMAIL PROTECTED] wrote: I'm pleased to announce the 0.5 release of the Yi editor. I've just tested it and seems to work nicely, thanks. * Unix Console front-end (Gtk2Hs frontend is not supported in this release) What ever happened to the experimental cocoa frontend? I'm sure a lot of Haskell hackers use OSX :) * Haskell support: * Lexical highlighting * Layout-aware parenthesis-matching * Auto-indentation * cabal-build within the editor Some features I would love to see in Yi (I will add them to the tracker). * Automatic generation of module header templates (i.e. author, module name, license ... ) based on the project's Cabal file * Integration with darcs. * Automatic identifier completion and on-the-fly checking of code (e.g. type-checking) and haddock markup. ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
Re: [Haskell-cafe] parsec 3 parsec 2
ghc-pkg hide {pkg-id}
On Thu, Oct 9, 2008 at 5:53 AM, Jason Dusek [EMAIL PROTECTED] wrote:
I don't know anything about how to do that. Is this a Cabal
thing? A GHC package registration thing?
--
_jsn
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: [Haskell] ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial
On Wed, Oct 1, 2008 at 7:38 PM, Don Stewart [EMAIL PROTECTED] wrote: Awesome, native packages now available, http://aur.archlinux.org/packages.php?ID=20422 Thanks Don! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell] ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial
Hi everyone, I am glad to announce the 3.0 release of ForSyDe's implementation, now available from HackageDB. The ForSyDe (Formal System Design) methodology has been developed with the objective to move system design (e.g. System on Chip, Hardware and Software systems) to a higher level of abstraction. ForSyDe is implemented as a Haskell-embedded behavioral DSL (Domain Specific Language). From this release, ForSyDe includes a new deep-embedded DSL and embedded compiler. We have also published tutorial which should be much more user-friendly than the Haddock documentation and the ForSyDe research papers. ForSyDe includes two DSL flavours which offer different features: 1) Deep-embedded DSL (ForSyDe.Signal) Deep-embedded signals, based on the same concepts as Lava, are aware of the system structure. Based on that structural information ForSyDe's embedded compiler, can perform different analysis and transformations. o Thanks to Template Haskell, computations are expressed in Haskell, not needing to specifically design a DSL for that purpose. o Embedded compiler backends: + Simulation + VHDL (with support for Modelsim and Quartus II) + GraphML (with yFiles graphical markup support.) o Synchronous model of computation. o Support for components. o Support for fixed-sized vectors à la VHDL. 2) Shallow-embedded DSL (ForSyDe.Shallow.Signal) Shallow-embedded signals are modeled as streams of data isomorphic to lists. Systems built with them are unfortunately restricted to simulation, however, shallow-embedded signals provide a rapid-prototyping framework with which to experiment with Models of Computation (MoCs). o Synchronous MoC. o Untimed MoC. o Continuous Time MoC. o Domain Interfaces allow connecting various subsystems with different timing (domains) regardless of their MoC. o Deep-embedded models can be integrated through simulation. Links ForSyDe website: http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/ ForSyDe tutorial: http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/files/tutorial/tutorial.html HackageDB package page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe Darcs repository: darcs get http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/darcs/ForSyDe/ ___ Haskell mailing list Haskell@haskell.org http://www.haskell.org/mailman/listinfo/haskell
[Haskell-cafe] ANN: Haskell-Embedded System Design: ForSyDe 3.0 and Tutorial
Hi everyone, I am glad to announce the 3.0 release of ForSyDe's implementation, now available from HackageDB. The ForSyDe (Formal System Design) methodology has been developed with the objective to move system design (e.g. System on Chip, Hardware and Software systems) to a higher level of abstraction. ForSyDe is implemented as a Haskell-embedded behavioral DSL (Domain Specific Language). From this release, ForSyDe includes a new deep-embedded DSL and embedded compiler. We have also published tutorial which should be much more user-friendly than the Haddock documentation and the ForSyDe research papers. ForSyDe includes two DSL flavours which offer different features: 1) Deep-embedded DSL (ForSyDe.Signal) Deep-embedded signals, based on the same concepts as Lava, are aware of the system structure. Based on that structural information ForSyDe's embedded compiler, can perform different analysis and transformations. o Thanks to Template Haskell, computations are expressed in Haskell, not needing to specifically design a DSL for that purpose. o Embedded compiler backends: + Simulation + VHDL (with support for Modelsim and Quartus II) + GraphML (with yFiles graphical markup support.) o Synchronous model of computation. o Support for components. o Support for fixed-sized vectors à la VHDL. 2) Shallow-embedded DSL (ForSyDe.Shallow.Signal) Shallow-embedded signals are modeled as streams of data isomorphic to lists. Systems built with them are unfortunately restricted to simulation, however, shallow-embedded signals provide a rapid-prototyping framework with which to experiment with Models of Computation (MoCs). o Synchronous MoC. o Untimed MoC. o Continuous Time MoC. o Domain Interfaces allow connecting various subsystems with different timing (domains) regardless of their MoC. o Deep-embedded models can be integrated through simulation. Links ForSyDe website: http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/ ForSyDe tutorial: http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/files/tutorial/tutorial.html HackageDB package page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/ForSyDe Darcs repository: darcs get http://www.ict.kth.se/org/ict/ecs/sam/projects/forsyde/www/darcs/ForSyDe/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] bug in number reading?
:; ghc -e '10e4' 10e4 = 10*10^4 = 10^5 = 1e5 = 10.0 10.0 It seems to be OK. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GADTs and functional dependencies
On Tue, Sep 23, 2008 at 6:36 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Pattern matching against the data constructor GADT specializes a to (). Since Class uses a functional dependency, it is clear that b has to be (). True, but it wont work if you provide () as the result and b in the explicit signature. GHC is ranting with reason, the provided type, b, does not match (). On the other hand, this works: fun :: (Class a b) = GADT a - b fun GADT = undefined And as you stated, b can only be () ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] How to check if two Haskell files are the same?
On Wed, Sep 17, 2008 at 1:03 AM, Brandon S. Allbery KF8NH [EMAIL PROTECTED] wrote: On 2008 Sep 16, at 10:30, Mauricio wrote: I would like to write a Haskell pretty-printer, using standard libraries for that. How can I check if the original and the pretty-printed versions are the same? For instance, is there a file generated by GHC at the compilation pipe that is always guaranteed to have the same MD5 hash when it comes from equivalent source? Compare .hi files? You an also compare the resulting object files ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: pandoc 1.0.0.1
On Sun, Sep 14, 2008 at 3:29 AM, John MacFarlane [EMAIL PROTECTED] wrote: Some highlights of this release: + New GNU Texinfo writer (contributed by Peter Wang) + New OpenDocument XML writer (contributed by Andrea Rossato) + New ODT (OpenOffice document) writer + New MediaWiki markup writer I can't wait for a: + New Docbook markup reader The reason being, I would kill for a good Docbook-to-LaTeX translator (or a good set of Docbook-to-TeXML XSLT stylesheets): * Most of the opensource XSL-FO tools out there (fop, xmlroff et all) are immature or do a poor typesetting job [1]. * The other LaTeX-based solutions seem to be broken and/or unmaintained (http://db2latex.sourceforge.net, http://dblatex.sourceforge.net/ ...) A good post on the topic: http://uucode.com/blog/2007/02/23/general-questions-about-docbook-latex/ [1] I wanted to show how bad the PDF version of the GHC manual looks (at least the one generated by fop), but all the PDF links from GHC's page seem to be broken at the moment. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] template haskell -- include a file?
On Fri, Sep 12, 2008 at 9:47 PM, Jason Dusek [EMAIL PROTECTED] wrote: I'd like to use template Haskell to include as a string in a Haskell file. How do I do it? I presume you mean Include a string from the outside world with a IO action (a file, keyborad, etc ...) -- module EmbedStr (embedStr) where import Language.Haskell.TH import Language.Haskell.TH.Syntax (lift) embedStr :: IO String - ExpQ embedStr readStr = lift = runIO readStr -- For example, to get asked about the string you want to embed during compilation ... $ ghci -XTemplateHaskell EmbedStr.hs GHCi, version 6.8.2: http://www.haskell.org/ghc/ :? for help Loading package base ... linking ... done. [1 of 1] Compiling EmbedStr ( EmbedStr.hs, interpreted ) Ok, modules loaded: EmbedStr. *EmbedStr let myStr = $(embedStr ((putStrLn What string?) getLine)) Loading package array-0.1.0.0 ... linking ... done. Loading package packedstring-0.1.0.0 ... linking ... done. Loading package containers-0.1.0.1 ... linking ... done. Loading package pretty-1.0.0.0 ... linking ... done. Loading package template-haskell ... linking ... done. What String? Foo *EmbedStr myStr Foo *EmbedStr Is there any lengthy documentation with examples for Template Haskell? The pages linked to from `haskell.org` are a little sparse. Uhm, I only know about http://www.haskell.org/haskellwiki/Template_Haskell#Template_Haskell_tutorials_and_papers I particularly like Mark Snyder's Template Haskell chapter on the Software Generation and Configuration Report , but the link is broken :( ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Why doesn't this work?
I haven't tried to run the code, but my first bet is that, due to the rank-2 polymorphism of ST, you should use parenthesis instead of $ in the case of runST. On Sun, Aug 24, 2008 at 3:25 PM, Andrew Coppin [EMAIL PROTECTED] wrote: colour_grid :: (Particle - IO ()) - Grid ph - IO () colour_grid fn g = sequence_ $ runST $ do ps - grid_coords g mapM (\pix - do particle - read_grid g pix return $ fn particle ) ps When I attempt to run this, GHCi just gives me a very cryptic type checker error. I can't figure out what's wrong here. As far as I can tell, this should run... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] FPGA / Lava and haskell
We'll soon (before september, hopefully) relase a deep-embedded version of ForSyDe[1] which, among other things, has a VHDL backend (with specific support for Altera's Modelsim and Quartus). ForSyDe's new implementation is internally based upon the same concept as Lava (Observable Sharing). However, it has quite a few differences: * ForSyDe is behavioural (computations are expressed in plain haskell) * It has support for components * Is not barely targeted at synchrounous hardware systems (although the VHDL backend is obviously aimed at them). It has suport for other MoCs (Models of Computation). [1] http://www.imit.kth.se/info/FOFU/ForSyDe/ On Tue, Jul 8, 2008 at 7:43 PM, Marc Weber [EMAIL PROTECTED] wrote: Is Haskell still used (in industry as well ?) to write (V)HDL code to program FPGAs and create circuits on chips? The Chalmers Lava homepage tells abouta Xilinx version which should be merged in soon. But on the xilinx homepage there was no reference to neither Lava nor haskell.. I'm thinking about designing a similar tool to www.combimouse.com. Sincerly Marc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] A type signature inferred by GHCi that is rejected when written explicitly
Hi Pablo, On Mon, Jul 7, 2008 at 10:07 AM, Pablo Nogueira [EMAIL PROTECTED] wrote: GHCi infers it has type (up to renaming): (From a1 (s (a1 x)) x, Bifunctor s, To a2 (s (a2 y)) y) = (x - y) - a1 x - a2 y But if I cut and paste the type into the code I get type errors: Could not deduce (From a1 (s1 (a11 x)) x) ... Could not deduce (From a11 (s1 (a11 x)) x, To a21 (s1 (a21 y)) y) ... Could not deduce (From a1 (s1 (a11 x)) x) ... I myselft don't understand why GHCi doesn't accept the type it infered as an explicit signature ... but your problem seems to be caused by a lack of functional dependencies. Redefining To and From as .. class From a c x | a - c where from :: a x - c x class To a c y | c - a where to :: c y - a y ... hushes GHCi. The question now is, of course, if the new dependencies are too restrictive for your problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] number-parameterized types and heterogeneous lists
Inspired in Oleg's ideas, I implemented the packages type-level and parameterized-data (which includes number-parameterized vectors). To get an idea about how they work you might want to read their haddock documentation in hackage: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/type-level http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parameterized-data You can get their darcs repositories (including some minor updates) from: darcs get http://code.haskell.org/type-level darcs get http://code.haskell.org/parameterized-data On Fri, Jun 20, 2008 at 8:01 AM, Harald ROTTER [EMAIL PROTECTED] wrote: Dear Haskellers, after reading Oleg Kiselyov's paper on number-parameterized types I started to play around with the class Digits that encodes decimal numbers in types. The typed number 10 would e.g. be defined as D1 $ D0 $ Sz I wondered if it would be possible replace the expression above by a heterogeneous list like [D1,D0] so I tried to define data Digit = forall a b.(Digits a, Digits (b a)) = Digit (a - b a) Loading this into ghci yields: :t Digit D0 interactive:1:0: Ambiguous type variable `a' in the constraint: `Digits a' arising from a use of `Digit' at interactive:1:0-7 Probable fix: add a type signature that fixes these type variable(s) Removing the type constraints in the definition of Digit: data Digit = forall a b.Digit (a - b a) makes it work like this: :t Digit D0 Digit D0 :: Digit :t [Digit D0, Digit D1] [Digit D0, Digit D1] :: [Digit] Digit, however, is far too general (it also includes e.g. \x - [x]), but I would like it to be restricted to the Digit class. Any help is appreciated. Thanks Harald. CODE: module Test where data D0 a = D0 a data D1 a = D1 a data D2 a = D2 a data D3 a = D3 a data D4 a = D4 a data D5 a = D5 a data D6 a = D6 a data D7 a = D7 a data D8 a = D8 a data D9 a = D9 a class Digits ds where d2num :: Num a = ds - a - a data Sz = Sz-- zero size instance Digits Sz where d2num _ acc = acc instance Digits ds = Digits (D0 ds) where d2num dds acc = d2num (t22 dds) (10*acc) instance Digits ds = Digits (D1 ds) where d2num dds acc = d2num (t22 dds) (10*acc+1) instance Digits ds = Digits (D2 ds) where d2num dds acc = d2num (t22 dds) (10*acc+2) instance Digits ds = Digits (D3 ds) where d2num dds acc = d2num (t22 dds) (10*acc+3) instance Digits ds = Digits (D4 ds) where d2num dds acc = d2num (t22 dds) (10*acc+4) instance Digits ds = Digits (D5 ds) where d2num dds acc = d2num (t22 dds) (10*acc+5) instance Digits ds = Digits (D6 ds) where d2num dds acc = d2num (t22 dds) (10*acc+6) instance Digits ds = Digits (D7 ds) where d2num dds acc = d2num (t22 dds) (10*acc+7) instance Digits ds = Digits (D8 ds) where d2num dds acc = d2num (t22 dds) (10*acc+8) instance Digits ds = Digits (D9 ds) where d2num dds acc = d2num (t22 dds) (10*acc+9) t22 :: f x - x t22 = undefined --data Digit = forall a b.(Digits a, Digits (b a)) = Digit (a - b a) data Digit = forall a b.Digit (a - b a) - Ce courriel et les documents qui y sont attaches peuvent contenir des informations confidentielles. Si vous n'etes pas le destinataire escompte, merci d'en informer l'expediteur immediatement et de detruire ce courriel ainsi que tous les documents attaches de votre systeme informatique. Toute divulgation, distribution ou copie du present courriel et des documents attaches sans autorisation prealable de son emetteur est interdite. This e-mail and any attached documents may contain confidential or proprietary information. If you are not the intended recipient, please advise the sender immediately and delete this e-mail and all attached documents from your computer system. Any unauthorised disclosure, distribution or copying hereof is prohibited. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Meaning of ribbonsPerLine at Text.PrettyPrint.HughesPJ ?
On Wed, Jun 18, 2008 at 5:41 PM, Duncan Coutts [EMAIL PROTECTED] wrote: And isn't 100 columns a bit non-standard for a default? I thought 80 columns had more traction? I know that's what my terminals are at... Yeah. I'd vote for 80. That's what we use in pretty printing messages in Cabal. Yep, me too, I'm also using 80. I'd also vote for a default ribbonsPerLine of 1 (whatever that is). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Meaning of ribbonsPerLine at Text.PrettyPrint.HughesPJ ?
Hi,
Can anyone give a good explanation of what ribbonsPerLine means?
Maybe it would be better to simply ask for the meaning of ribbon in
this context. The documentation is totally meaningless to me:
reibbonsPerLine: Ratio of ribbon length to line length.
I asked at #haskell and frankly, I was surprised by the answer:
fons: can anyone tell me what the heck does ribbonsPerLine mean in
Text.PrettyPrint.HughesPJ?
fons: renderStyle style{lineLength=10, ribbonsPerLine=1} $ sep [text
foo ,text bar]
lambdabot: foo bar
fons: renderStyle style{lineLength=10, ribbonsPerLine=2} $ sep [text
foo ,text bar]
lambdabot: foo\nbar
fons: ok, somehow it affects the line width ...
byorgey: fons: I can't explain it, all I know is that you must set it
to 1 or else it does bizarre things
fons: hahah, ok
fons: byorgey: that's funny considering its default value is 1.5
byorgey: if you set it to 1 then lineLength means what you think it should
byorgey: fons: EXACTLY
Cheers,
Fons
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: type-level integers using type families
On Thu, May 29, 2008 at 5:15 AM, Peter Gavin [EMAIL PROTECTED] wrote: Has anyone else tried implementing type-level integers using type families? When I started to work on thetype-level and parameterized data packages, I considered using type-families and GADTs, but I found quite a few problems which have been nicely summarized by Benedikt in this thread. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] problems with derive/TH
On Fri, May 23, 2008 at 5:11 PM, Thomas Hartman [EMAIL PROTECTED] wrote: I am assuming this used to work, but something changed, either in TH itself or switching from ghc6.6 to ghc6.8. The deriving rules of 6.8 are more restrictive in some cases. However, the same result can be obtained in 6.8 byt using stand-alone deriving declarations: http://www.haskell.org/ghc/docs/latest/html/users_guide/deriving.html#stand-alone-deriving I guess this can be the problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Link to Hierarchical-libraries documentation generated with haddock 2.0?
Hi all, GHC's documentation page [1] only points to hierarchical-libraries documentation generated by haddock-0.8 [2]. I need the 2.0 version in order to get links in the documentation of the project I'm working on (which needs haddock 2.0 due to the use of quite a few GHC extensions). Before I proceed to generate them myself, has anyone done it already? (I guess that must be the case since HackageDB users haddock 2.0 and gets all the links right) I would be more than happy to just click a link instead :) Either way, I think it would be a good idea to provide an alternative link to the 2.0 version. Thanks, Fons [1] http://www.haskell.org/ghc/documentation.html [2] http://www.haskell.org/ghc/docs/latest/libraries.html.tar.gz ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Dynamic over the wire
On Tue, May 13, 2008 at 7:39 PM, Jules Bean [EMAIL PROTECTED] wrote: One thing which you can't obviously do is write Read or Show instances for Dynamic. So can we pass Dynamic data over the wire? If not, Dynamic is limited to the context of within a single program, and can't be used over the network between cooperating programs, or in file formats, etc. I've never used hs-plugins, but if I recall properly, it includes its own implementation of TypeRep (and consequently Dynamic) in order to overcome the serialization problem you have mentioned. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics?
On Wed, May 7, 2008 at 7:47 AM, Jules Bean [EMAIL PROTECTED] wrote: Alfonso Acosta wrote: It would certainly be difficult map any Haskell type to VHDL, so, by now we would be content to map enumerate algebraic types (i.e. algebraic types whose all data constructors have arity zero, e.g. data Colors = Green | Blue | Red) Wouldn't it be much simpler to use the standard deriveable classes Bounded and Enum, instead of an admittedly very clever trick using Data? No, for the reasons explained in the probably_unnnecesary_background I don't see how those instantiations would help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics?
Hi all, probably_unnnecesary_background I'm writing a Hardware-oriented DSL deep-embedded in Haskell (similar to Lava, for those familiar with it). One of the goals of the language is to support polymorphic signals (i.e. we would like to allow signals to carry values of any type, including user-defined types) The embedded compiler has different backends: simulation, VHDL, graphical representation in GraphML ... The simulation backend manages to support polymorphic signals by forcing them to be Typeable. In that way, circuit functions, no matter what signals they process, can be transformed to Dynamic and included in the AST for later simulation. The situation is more complicated for the VHDL backend. The Typeable trick works just fine for translating a limited set of predefined types (e.g. tuples) but not for user-defined types, since the embedded-compiler doesn't have access to the user-defined type declarations. One possible solution to access the type-definition of signal values would be constraining them to instances of Data. Then, we could use dataTypeOf to get access to the type representation. (Another option would be using template Haskell's reify, but I would like to avoid that by now) It would certainly be difficult map any Haskell type to VHDL, so, by now we would be content to map enumerate algebraic types (i.e. algebraic types whose all data constructors have arity zero, e.g. data Colors = Green | Blue | Red) /probably_unnnecesary_background So, the question is. Is there a way to figure out the arity of data constructors using Data.Generics ? I'm totally new to generics, but (tell me if I'm wrong) it seems that Constr doesn't hold any information about the data-constructor arguments. Why is it so? Do you think there is a workoaround for this problem? (maybe using some other function from Data.Generics different to dataTypeOf?) Thanks in advance, Alfonso Acosta ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Figuring out if an algebraic type is enumerated through Data.Generics?
Thanks a lot for your answer, it was exactly what I was looking for.
Just for the record, based on your solution I can now easily code a
function to check if a Data value belongs to an enumerated algebraic
type (as I defined it in my first mail).
{-# LANGUAGE DeriveDataTypeable, ScopedTypeVariables #-}
import Data.Generics
newtype Arity a = Arity Int
deriving (Show, Eq)
consArity :: Data a = Constr - Arity a
consArity = gunfold (\(Arity n) - Arity (n+1)) (\_ - Arity 0)
belongs2EnumAlg :: forall a . Data a = a - Bool
belongs2EnumAlg a = case (dataTypeRep.dataTypeOf) a of
AlgRep cons - all (\c - consArity c == ((Arity 0) :: Arity a )) cons
_ - False
-- tests
data Colors = Blue | Green | Red
deriving (Data, Typeable)
test1 = belongs2EnumAlg 'a' -- False
test2 = belongs2EnumAlg Red -- True
test3 = belongs2EnumAlg a -- False
On Tue, May 6, 2008 at 7:42 PM, Edward Kmett [EMAIL PROTECTED] wrote:
On Tue, May 6, 2008 at 12:34 PM, Alfonso Acosta
[EMAIL PROTECTED] wrote:
| So, the question is. Is there a way to figure out the arity of data
| constructors using Data.Generics ?
| I'm totally new to generics, but (tell me if I'm wrong) it seems that
| Constr doesn't hold any information about the data-constructor
| arguments. Why is it so?
Hmrmm,
Playing around with it, I was able to abuse gunfold and the reader
comonad to answer the problem :
fst $ (gunfold (\(i,_) - (i+1,undefined)) (\r - (0,r)) (toConstr
Hello) :: (Int,String))
returns 2, the arity of (:), the outermost constructor in Hello
A longer version which does not depend on undefined would be to take
and define a functor that discarded its contents like:
module Args where
import Data.Generics
newtype Args a = Args { runArgs :: Int } deriving (Read,Show)
tick :: Args (b - r) - Args r
tick (Args i) = Args (i + 1)
tock = const (Args 0)
argsInCons = runArgs $ (gunfold tick tock (toConstr Hello) :: (Args
String)
Basically all I do is rely on the fact that gunfold takes the 'tick'
argument and calls it repeatedly for each argument after a 'tock' base
case.
The use of the reader comonad or functor is to give gunfold a
'functor-like' argument to meet its type signature.
-Edward Kmett
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] C++ interface with Haskell
Although you could use gcc to link the code I wouldn't recommend it
(mainly for the problems you are currently having)
SImply call GHC to compile both the C and Haskell code. It will take
care of finding the headers and supplying the necessary linker
arguments.
ghc -ffi -c foo.hs myfoo_c.c
BTW, you don't need to compile viaC
2008/4/17 Miguel Lordelo [EMAIL PROTECTED]:
Well Isaac...I became now a little bit smarter then yesterday!!!
I show you the example that I found and on which I´m working with.
File: foo.hs
module Foo where
foreign export ccall foo :: Int - IO Int
foo :: Int - IO Int
foo n = return (length (f n))
f :: Int - [Int]
f 0 = []
f n = n:(f (n-1))
To get the C wrapper you insert the following command:
ghc -ffi -fvia-C -C foo.hs
After execution you will have these following additional files:
foo.hc
foo.hi
foo_stub.c
foo_stub.h
foo_stub.o
What I did next was to create a file named: myfoo_c.c, where I will call the
foo function (implemented in Haskell).
(you can see this example on
http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html )
But the problem is to compile with gcc (must I put any flag or whatever set
something)
The gcc output is:
myfoo_c.c:2:19: error: HsFFI.h: No such file or directory
I downloaded this header file from: (I know that is not the correct way, but
it was the only idea that occurs at the moment)
http://www.koders.com/c/fidD0593B84C41CA71319BB079EFD0A2C80211C9337.aspx
I compiled again and the following return error appears:
myfoo_c.c:(.text+0x1c): undefined reference to `hs_init'
myfoo_c.c:(.text+0x31): undefined reference to `foo'
myfoo_c.c:(.text+0x50): undefined reference to `hs_exit'
collect2: ld returned 1 exit status
These functions are necessary to setup GHC runtime (see:
http://www.haskell.org/ghc/docs/latest/html/users_guide/ffi-ghc.html )
What I want to know is how to compile myfoo_c.c?! Is it with GCC or GHC?!
Chears,
Miguel Lordelo.
On Wed, Apr 16, 2008 at 9:16 PM, Isaac Dupree [EMAIL PROTECTED]
wrote:
perhaps
haskell:
foreign export foo_func foo :: Int - IO Int
-- I forget the rest of the syntax here
C++:
extern C {
int foo_func(int i);
}
int some_cplusplus_function() {
int bat = 3;
int blah = foo_func(bat);
return blah;
}
Is that all you need to do?
Miguel Lordelo wrote:
Hi all,
Well...somehow I'm a beginner in Haskell. But actually my interest in
Haskell will increase if it is possible to call a haskell function in
C++.
Something like GreenCard ( http://www.haskell.org/greencard/ )
simplifying
the task of interfacing Haskell programs to external libraries
(usually).
But is there also a task to interface a foreign language with Haskell,
but
calling Haskell functions. Or c2hs which is an interface generator that
simplifies the development of Haskell bindings to C libraries.
I want to know this, because in my company some guys are doing some
testing
with Frotran and MatLab and I want to show them the power of haskell and
the
software which we are using is implemented in C++ (there is the reason
to
make Haskel - C++).
I read somewhere that the only way for C++ calling a haskell function is
to
create a binding between Haskell and C and from C to C++, but a easy
Hello
World example was not there.
Unfortunatelly I couldn't found anything usefull, like an complete
example,
or how to compile the code from haskell to C to C++.
Can sombody help me, please :P
Chears,
Miguel Lordelo.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Intro to functional dependencies in Haskell?
Not so long ago, I had difficulties to understand functional dependecies. Due to the (sometimes well-grounded) prejudgement of considering research papers as an unfriendly and obscure source of information, I stupidly ruled out reading Mark P Jones original paper. Then I learned I was totally wrong, it is written in a friendly way, with lots of examples, allowing me to finally understand how functional dependencies work and what was the reason to introduce them: http://web.cecs.pdx.edu/~mpj/pubs/fundeps.html On Thu, Apr 17, 2008 at 7:21 AM, Alexis Hazell [EMAIL PROTECTED] wrote: Hi all, i'm having some trouble 'getting' functional dependencies in the Haskell context (although my understanding of them in the context of relational database theory isn't that great either). Could someone please point me to an introduction / tutorial in this regard? Thanks! Alexis. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Doing without IORef
type MyState a = StateT FilePath IO a Is there any way in which I can do without IORef in tabHandler and commandLoop (written in red and bold, if you can see)? How about keeping the IORef but storing it inside the state? type MySate a = StateT (IORef FilePath) IO a ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Possible to automatically determine typeclass membership?
Hopefully, accessing the instance environment from Tempalte Haskell
will be possible in next GHC's release:
http://hackage.haskell.org/trac/ghc/ticket/1835
2008/3/31 jeff p [EMAIL PROTECTED]:
Hello,
Is it possible in Haskell + GHC extensions to use reflection
techniques to determine typeclass membership? I'm thinking of things
like the following:
I think the short answer is not in general; i.e. I don't think there is any
way to access the members of an arbitrary typeclass (but I'd love to be
proved wrong).
However, you could always explicitly list the members of a typeclass you are
interested in (this is similar to your Idea 2):
{-# OPTIONS_GHC -fglasgow-exts -fallow-undecidable-instances
-fallow-overlapping-instances #-}
class InEq a b | a - b where inEq :: a - Bool
instance TypeCast b HFalse = InEq a b where inEq _ = False
instance InEq Int HTrue where inEq _ = True
instance InEq a b = InEq [a] b where inEq _ = inEq (undefined :: a)
data HTrue
data HFalse
class TypeCast a b | a - b, b- a where typeCast :: a - b
class TypeCast' t a b | t a - b, t b - a where typeCast' :: t - a - b
class TypeCast'' t a b | t a - b, t b - a where typeCast'' :: t - a - b
instance TypeCast' () a b = TypeCast a b where typeCast x = typeCast' ()
x
instance TypeCast'' t a b = TypeCast' t a b where typeCast' = typeCast''
instance TypeCast'' () a a where typeCast'' _ x = x
You can also do an arguably nicer, more flexible version of the previous by
recreating some of the typeclass machinery yourself; Oleg has several
examples of this such as: //okmij.org/ftp/Haskell/poly2.txt
-Jeff
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Success report: Leopard powerpc
On 3/17/08, Chris Kuklewicz [EMAIL PROTECTED] wrote: I used both ghc-6.6.1 and macports to create a working ghc-6.8.2 on OS X 10.5.2 on a powerpc G4 laptop. Great! It would be awsome if a PPC/Lepoard installation package was made available from GHC's page. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Fri, Mar 14, 2008 at 9:58 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 14. März 2008 17:46 schrieben Sie: I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000), I don't think, this is a good idea. Like nobody will need an alias for 8247, nobody will need an alias for 824. The main point is that it is unnecessary to have a continuous range of numbers for which aliases exist. If you need aliases, you need them for outstanding values. Maybe you need aliases for all powers of 2 up to a certain number. Or aliases for all square numbers. Therefore I think that if we want aliases then we should let the user and only the user generate them. This has also the interesting consequence that the type-level package doesn't need the Template Haskell language extension anymore. After all, using the template-haskell package doesn't imply that you have to have a TH-enabled compiler, as far as I know. I don't agree. Not using aliases is a big pain, which means that every user wanting to use vectors with sizes biger than 10 (i.e. all) will have to generate their own alias set. It would be really annoying having to generate the aliases every time the library is used. Let's agree on a minimum alias set likely to be used by most of the users, small enough to get a reasonable object code size and compile time (we can even prevent haddock from parsing the alias module and just write a comment indicating what aliases are and which ones are generated if that helps). Generating type redefinitions up to decimal 500 shouldn't be such a big overhead (at least compared to the quntity of aliases generated right now). droping the other bases, That's a good idea. and exporting a function to extended the alias range at will? I'd rather propose something like this: $(numAliasDecls [2 ^ n | n - 0..16]) So that numAliasDecls has a type like [Int] - [Decl]. That doesn't include bases, which might be important for the end user (for example Oleg wrote his type-evel numerical library in base 2 because it was aimed at system development). I'd rather propose a modification of Data.TypeLevel.Num.Aliases.genAliases which probably should be aware of the aliases already generated in the library so that they are not duplicated. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Fri, Mar 14, 2008 at 5:30 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: I have a feedback from my Grapefruit co-developer about those aliases in the type-level package. He told me that on his machine, building this package took about 15 minutes, obviously because the machine ran out of RAM. He also told me that the generated object code was very large, and that loading the documentation page generated by Haddock took very long. Fair point, it akes quite some time in my machine too (not 15minutes though) And he made a very good point: Who needs aliases for *all* numbers until, say, 1? Who needs to hard-code the vector length 8247 in his code? If I remember correctly aliases are generated until decimal 5000, which might me really long anyway. I think that in practice, you only need very few numbers hard-coded. So it might be better to export a function for letting the package user generate the necessary aliases himself. I even think that it is probably sensible to drop the alias thing completely, at least if you have vector lengths in mind. What vector lengths will appear as fixed in a real world program? 1000? I think, usually you have only sizes like 2 or 3 hard-coded, for vectors in the mathematical sense. And their representation is already very short: D2, D3, … Remember that computed numbers are not shown as aliases in error messages, only numbers that directly appear in your code. My co-author also mentioned that he doesn't see much use for octal and hexadecimal notation. So I propose to drop alias support from type-level or at least let the package user do the necessary generation. I think that removing aliases completely is not a good idea. How about generating much lower aliases for decimals (lets say until 1000), droping the other bases, and exporting a function to extended the alias range at will? (that function could perfectly include the other bases as well). Something called extendAliases would do. I don't have the time to work on it now, but if you send me a patch I'd be happy to apply it. It should be something simple to do. All the Template Haskell machinery is already coded. […] Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell -- when are things evaluated?
Hi Emil, Your problem is related to how are things evaluated not when. The short answer is: if you want to make sure an expression is evaluated before you lift it, don't use quasiquotes, call Language.Haskell.TH.lift On Thu, Mar 13, 2008 at 9:00 AM, Emil Axelsson [EMAIL PROTECTED] wrote: a1 = [| (2::Int) + 2 |] You are lifting the expression AST, not its evaluation. a1 = lift ((2::Int) + 2) would work as you want. a2 = let x = (2::Int) + 2 in [| x |] here you are enclosing a local variable in quasiquotes and, thus, [| x |] is equivalent to lift x a3 = [| y |] where y = (2::Int) + 2 Same as in a2, y is local. Therefore [| y |] is equivalent to lift y z = (2::Int) + 2 a4 = [| z |] z is a global variable and [| z |] is lifted to a variable expression (i.e. a4 is equivalent to varE 'z ) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Template Haskell -- when are things evaluated?
On Thu, Mar 13, 2008 at 11:13 AM, Emil Axelsson [EMAIL PROTECTED] wrote: I'm reading the following rule from your answer: [|exp|] normally returns the unevaluated AST of exp. However, if exp contains local variables, these are lifted using Language.Haskell.TH.lift (i.e. evaluated before lifting). Is that correct? / Emil Yes, that seems to be true. I'm not an expert in the internals of TH though, so I have inferred that rule by extensive use of TH ;). SPJ can confirm if it's right. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating point operations and representation
On Thu, Mar 13, 2008 at 1:35 AM, Jacob Schwartz [EMAIL PROTECTED] wrote:
I have two questions about using the Double data type and the
operations in the Floating typeclass on a computer that uses IEEE
floating point numbers.
I notice that the Floating class only provides log (presumably log
base 'e') and logBase (which, in the latest source that I see for
GHC is defined as log y / log x). However, in C, the math.h
library provides specific log2 and log10 functions, for extra
precision. A test on IEEE computers (x86 and x86-64), shows that for
a range of 64-bit double values, the answers in C do differ (in the
last bit) if you use log2(x) and log10(x) versus log (x) /
log(2) and log(x) / log(10).
I am under the restriction that I need to write Haskell programs using
Double which mimic existing C/C++ programs or generated data sets, and
get the same answers. (It's silly, but take it as a given
requirement.) If the C programs are using log2, then I need log2
in the Haskell, or else I run the risk of not producing the same
answers. My first thought is to import log2 and log10 through the
FFI. I was wondering if anyone on Haskell-Cafe has already done this
and/or has a better suggestion about how to get specialized log2 and
log10 (among the many specialized functions that the math.h
library provides, for better precision -- for now, I'm just concerned
with log2 and log10).
The RULES pragma + FFI solution (as suggested by Henning) seems to be
the most sensible one so far.
My second question is how to get at the IEEE bit representation for a
Double. I am already checking isIEEE n in my source code (and
floatRadix n == 2). So I know that I am operating on hardware that
implements floating point numbers by the IEEE standard. I would like
to get at the 64 bits of a Double. Again, I can convert to a CDouble
and use the FFI to wrap a C function which casts the double to a
64-bit number and returns it. But I'm wondering if there's not a
better way to do this natively in Haskell/GHC (perhaps some crazy use
of the Storable typeclass?).
Posted in a a previous haskell-cafe message [1]
{-# LANGUAGE MagicHash #-}
import Data.Int
import GHC.Exts
foo :: Double - Int64 --ghc only
foo (D# x) = I64# (unsafeCoerce# x)
[1] http://www.haskell.org/pipermail/haskell-cafe/2008-February/04.html
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO () and IO [()]
On Mon, Mar 10, 2008 at 11:11 PM, Paulo J. Matos [EMAIL PROTECTED] wrote: outputLines i = mapM (putStrLn . show) (take i $ iterate ((+) 1) 1) However, this is in fact outputLines :: Int - IO [()] As others suggested you can use mapM_ Furthermore, you can simplify it a bit with some syntactic sugar outputLines i = mapM_ (putStrLn . show) [1..i] BTW, considering how often is (putStrLn.show) used, it is surprising that there is no Ln variant for print (just like it happens with putStr and putStrLn) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] IO () and IO [()]
On Mon, Mar 10, 2008 at 11:48 PM, Daniel Fischer [EMAIL PROTECTED] wrote: But print is (putStrLn . show), so what may be missing is (putStr . show). That's what I meant sorry .. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: parameterized-data 0.1 - Parameterized data library implementing lightweight dependent types
This library provides an implementation of parameterized types using type-level computations to implement the type parameters and emulate dependent types. Right now only fixed-sized vectors are provided (based on Oleg's Number-parameterized types [1] and Frederik Eaton's Vectro library [2]) HackageDB page: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/parameterized-data-0.1 Darcs repository: http://code.haskell.org/parameterized-data/ Again, big thanks to Oleg and Wolfgang for their help and suggestions. [1] http://okmij.org/ftp/Haskell/number-parameterized-types.html [2] http://ofb.net/~frederik/vectro/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best practice for embedding files in a GHC-compiled tool?
A bit late, sorry, but you could use this: http://www.wellquite.org/hinstaller/ On Thu, Feb 7, 2008 at 5:29 AM, Dave Bayer [EMAIL PROTECTED] wrote: What is the best way to embed an arbitrary file in a Haskell program? I would like to use GHC to compile command-line tools to be used with OS X. I want the tool to be a single file, not a package or a directory, that makes no assumptions about what else is present. For example, it should be able to run as part of an OS X install disk. I want this tool to be self reproducing in the sense that one of its options causes it to output its own documentation and source code. I want this data to be stored as a compressed file within the tool binary itself. The distribution model I'm imagining here is where one writes a program anonymously, that isn't hosted anywhere but is passed from user to user because it is useful, and eventually reaches another user who wants to modify the code. Assume that intermediate users will care less about this, and will try to delete anything that they can. That rules out storing the data in a separate file. Think of the M.I.T. game Core Wars from the dawn of the computer age. I'm looking for a strategy here that will be evolutionarily successful in a fairly hostile environment. In other words, I want to be able to write in Haskell, without losing the automatic distribution of source code enjoyed by interpreted languages. No one deletes the source code for a Perl script, because by doing so they're killing the program. There must be some library I'm overlooking that would make this very easy. All I can think of is to use Template Haskell to read a compressed tar file into a Haskell variable. Is that what one does, or is there a better way? Thanks in advance, Dave ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Sessions 2008 2 28 - RFC
On Thu, Feb 28, 2008 at 11:23 PM, Matthew Sackman [EMAIL PROTECTED] wrote: If however, you are as mad as I, and enjoy pushing the GHC type system to the limit, then you may enjoy looking at the implementation in all its glory. base10 numbers, lists, associative maps and a whole lot of other madness works correctly at the type-level in ghc 6.8.2. Only if I had known before before I recently released a library, type-level [1], which implements type-level base10 numbers and Booleans. I could have reused your implementation but didn't know about it ... The plan is to include a common type-level implementation to avoid reinventing the wheel all the time. I'm still know if people will find it useful but if they do I could include your implementation of lists and maps. What do you think? [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/type-level-0.1 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANNOUNCE: type-level 0.1: Haskell type-level programming library
The goal of the Type-level library is to standardize and extend the features offered by the multiple (and heterogeneous) type-level programming implementations already around. To date, type-level Booleans and arbitrary sized Naturals are supported. I implemented a few things I didn't see in any other type-level programming libraries: * Numerals use decimal representation to make error reports friendlier. * Type-level numerals can be intuitively typed in different bases (although everything is internally represented in base 10) by using aliases: D16 represents the type-level decimal 16 B1010 represents the type-level binary 1010 076 represents the type-level octal 76 HFF represents the type-level hexadecimal FF * All basic arithmetic operations are supported (including logarithm and exponentiation in any base) * The library provides reification of Naturals and Booleans (from value-level to type-level) . To get the code: HackageDB page (including haddock documentation): http://hackage.haskell.org/cgi-bin/hackage-scripts/package/type-level-0.1 Darcs repository: http://code.haskell.org/type-level/ Big Thanks to Oleg and Wolfgang for their suggestions and contributions. Actually, most of the implementation of Naturals is based on Oleg's Binary Type Arithmetic http://okmij.org/ftp/Haskell/types.html#binary-arithm ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
OK I'll include the module after I change the things mentioned. BTW, I finally have an initial version of the parameterized-data package: Darcs repository: http://code.haskell.org/parameterized-data Haddock documentation: http://code.haskell.org/~fons/parameterized-data/doc/ Any comments/suggestions would be appreciated. To fix the problem of the vector constructor I included a Template Haskell variant. It is quite simple to use: $ ghci -XTemplateHaskell Prelude :m +Data.Param Prelude Data.Param $(vectorTH [1 :: Int, 2, 3, 4]) Prelude Data.Param :t $(vectorTH [1 :: Int, 2, 3, 4]) (vectorTH [1 :: Int, 2, 3, 4]) :: (Num t) = FSVec Data.TypeLevel.Num.Reps.D4 t Note that the size parameter (type-level decimal numeral) is correct. It would be nice to be able to use a Quasiquoter [1] (available in GHC HEAD) to enable pattern matching and custom syntax to Vector literals. However, I was bitten by a polymorphism problem when implementing it: see [2] for details [1] http://www.haskell.org/ghc/dist/current/docs/users_guide/template-haskell.html#th-quasiquotation [2] http://www.haskell.org/pipermail/template-haskell/2008-February/000655.html On Wed, Feb 20, 2008 at 2:26 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Mittwoch, 20. Februar 2008 00:39 schrieben Sie: Why are the value-level reflecting functionsimplemented as type-class methods? It makes the code more verbose and I don't see any advantage compared to simply defining a function per class. Let me show you an example: This is your implementation of Not: class (Boolean boolean, Boolean boolean') = Not boolean boolean' | boolean - boolean', boolean' - boolean where not :: boolean - boolean' instance Not False True where not _ = true instance Not True False where not _ = false This is how I would do it: class (Boolean boolean, Boolean boolean') = Not boolean boolean' | boolean - boolean', boolean' - boolean where instance Not False True instance Not True False not :: Not a b = a - b not = undefined Your definition of the not function uses the implementation detail that false and true are actually undefined. My implementation of the not function also works if false and true are defined to be something different. Of course, false and true are in the same library, so we know this implementation detail and could make use of it. Furthermore, why did you choose to use Boolean instead of simply Bool? To avoid a name clash. Feel free to change this. Note that False and True don't cause a name clash since they live in a namespace different from the one Prelude's False and True live in. Cheers, Fons Best wishes, Wolfgang ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Wed, Feb 20, 2008 at 11:26 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Hello Fons, why do you use the term vector? I'd say that this term is more or less wrong for what this type is about. The distinguishing property of vectors compared to lists is that there is addition and scalar multiplication for vectors. That depends on how you interpret the word vector, which is polysemous: http://en.wikipedia.org/wiki/Vector You are interpreting it as An element in a vector space, often represented as a coordinate vector whereas in this case I try to mean A one-dimensional array. The data type you defined is a fixed size list. The fact that FSVec is internally implemented using lists doesn't imply that FSVec should be interpreted as a list. FSVec is an ADT and I could as well have used something else to implement it (inmutable arrays for instance). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haddock documentation of Data.Array.* is confusing
On Wed, Feb 20, 2008 at 10:17 PM, Bulat Ziganshin [EMAIL PROTECTED] wrote: Hello Alfonso, Tuesday, February 12, 2008, 11:32:20 PM, you wrote: Excuse me for the subject, but IMHO is absolutely true. Anyhow, the of course, you are right, but for practical goals i may suggest just to read module sources instead of reading [had]docs. Well, that's what I was forced to do in the end, but I still think that the haddock documentation should be clear enough for most of the cases, and, when it comes to Data.Array* it could certainly be improved. seeing the implementation is much more interesting, after all. especially when you are so cool that you are going to add your own instance I don't think that being cool had anything to do with it. My only purpose was to understand the desing of the interface for inmutable arrays. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 14, 2008 10:40 AM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: So we should parameterized for the package name. That's the packagename I've been using. I'm done with a basic implementation but I'd like to test some other things before showing the code. On the other hand, I think that the type-level library is almost ready for it's initial release. Before uploading it to Hackage and making an announcement I would be pleased to receive some comments/suggestions. Here is the darcs repository: http://code.haskell.org/type-level/ Here is the haddock-generated documentation: http://code.haskell.org/~fons/type-level/doc/ There are still some things missing which would be cool to have: * Native support of representations in different bases (I don't know if it's feasible) * Support of negative integers (Björn?) * Support of type-level Booleans (Wolfgang?) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
2008/2/19 Wolfgang Jeltsch [EMAIL PROTECTED]: Attached is just a quickly hacked Boolean module. Nothing very special. I'd be happy if you could prettify this (choose better names, add documentation, etc.). Thanks for any effort. Thanks to you for the module. I have a few questions though. Why are the value-level reflecting functionsimplemented as type-class methods? It makes the code more verbose and I don't see any advantage compared to simply defining a function per class. Let me show you an example: This is your implementation of Not: class (Boolean boolean, Boolean boolean') = Not boolean boolean' | boolean - boolean', boolean' - boolean where not :: boolean - boolean' instance Not False True where not _ = true instance Not True False where not _ = false This is how I would do it: class (Boolean boolean, Boolean boolean') = Not boolean boolean' | boolean - boolean', boolean' - boolean where instance Not False True instance Not True False not :: Not a b = a - b not = undefined Furthermore, why did you choose to use Boolean instead of simply Bool? Cheers, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
I asked Oleg regarding the use of GADTs to emulate dependent types. My conclusion is that I should forget about them. Here is the full answer: -- Forwarded message -- From: [EMAIL PROTECTED] Date: Feb 12, 2008 8:49 AM Subject: Re: GADTs to emulate dependent types? To: [EMAIL PROTECTED] Hello! The main question is whether it is feasible to use GADTs to define fixed-sized vectors or not. The motivation behind it is to avoid needing to code your own trusted core and use the compiler typechecker for that purpose instead. That is a false proposition. In Haskell, any code that uses GADT *MUST* use a run-time test (run-time pattern match). Otherwise, the code is unsound and provides no guarantees. The particular value of a GADT data type is a witness of a proposition expressed in the type of GADT (e.g., type equality). Since it is possible in Haskell to fake this witness (just write undefined), if you don't check the witness at run-time, that is, test that the witness is a real value rather than undefined, you don't get any guarantees. That is why the irrefutable pattern-match does not work with GADT. Incidentally, the first implementation of GADT in GHC did permit irrefutable pattern-match, which did let one write unsound code (that is, code that gave segmentation fault): http://okmij.org/ftp/Haskell/GADT-problem.hs The issue is not present in Coq, for example, whose core calculus is sound and you cannot fake the evidence. Thus, the unsoundness of Haskell (the presence of undefined) mandates the run-time test for any code that uses GADT. So, GADTs are fundamentally less efficient than the typeclasses; the latter can provide assurances that can be checked at compile-time only, with no run-time artifacts. data FSVec :: * - * - * where NullV :: FSVec D0 a (:) :: Succ s s' = a - FSVec s a - FSVec s' a That is an old problem, and a difficult problem. In Singapore I was talking to Zhaohui Luo (you can look him up on Google), who said that the problem of asserting two types being equal (that is, Succ D0 being equal to D1) is a very tough one. Conor McBride have written a paper on observational equality -- but this is not Haskell. So, I don't think this approach works. Cheers, Oleg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Hi Dan, On Feb 10, 2008 6:08 PM, Dan Licata [EMAIL PROTECTED] wrote: The ideal type for the function would be: vector :: [a] - FSVec s a Well, I probably didn't express myself properly when writing The ideal type, the first type which comes to mind would have been more accurate. Thanks for your explanation, which is actually much better than mine and, in fact, almost identical to the one included in http://ofb.net/~frederik/vectro/draft-r2.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 9, 2008 11:33 PM, Alfonso Acosta [EMAIL PROTECTED] wrote: On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: example really applies here. Besides, you should be regarded :* as (,) and not as a constructor which would take a number and a digit Sorry for my lousy English, I meant you should regard not you should be regarded. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 9, 2008 4:08 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: So what would (D1 :* D1) :* (D2 :* D2) mean then? Nothing. That value doesn't satisfy the Nat or Post class constraints and should be taken into consideration. Why should :* be provided a meaning? it is an unavoidable syntactical connective for all that I care. The meaning is provided by class constraints and that's all that matter from the semantical point of view. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 8, 2008 5:14 PM, Stefan Monnier [EMAIL PROTECTED] wrote: How 'bout treating :+ as similar to `append' rather than similar to `cons'? Basically treat :+ as taking 2 numbers (rather than a number and a digit). Interpreting it like that would certainly make make more sense. But again, I think that :* should be interpreted just as an unavoidable syntactical annoyance without meaning or interpretation. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 8, 2008 4:10 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Donnerstag, 7. Februar 2008 16:31 schrieben Sie: Even if () would be preferred from the programmers point of view (I'm not sure how much we could reduce the number of instances though), it makes the representation less attractive on the user-side. Anyone using the library would find it annoying and would wonder why is it neccessary. I wouldn't wonder. Leaving out the () :* part just works because our type-level values are not typed, i.e., there aren't different kinds Digit and Number but only kind *. If :+ would be a data constructor (on the value level), it would take a number and a digit argument which would forbid using a digit as its left argument. Well, the fact is that :+ (or :* as it is called now) is not a value constructor but a type constructor as you said, so I don't think your example really applies here. Besides, you should be regarded :* as (,) and not as a constructor which would take a number and a digit argument which would forbid using a digit as its left argument. Indeed, :* exists as a value-level constructor too and works exactly like that. Furthermore, you probably consider using () as natural and logical because you are still thinking from the implementation side. If you forget the implementation details and think as a user who barely wants to write type-level numerical literals, :* is simply an ugly syntactic requirement which we cannot get rid of (I would be happy to find another representation closer to a literal, but I couldn't until now). That is not the case for (), since, as shown in the initial implementation, can be avoided. So, for me, it's just a matter of usability and syntax, the closer the representation can be to literals, the better. I don't see the semantic implications of :* as a valid argument. For me, :* is just an unavoidable ugly syntactical token without meaning. Imagine that for some reason, adding () as a prefix in every numerical literal made the implementation of a compiler slightly easier/faster. I bet users would rant about it till exhaustion :) If the argument was that, for some reason, () was proven to speed up the implementation or make a big maintainability difference (I still have my doubts) it would maybe make more sense (I still wouldn't be sure if it pays off though). Maybe it would be a good idea to create a patch and see what happens :) As a side note, I think that type-value digits actually are typed (metatyped maybe is a nicer term?). Class constraints take the role of types in this case. After all (sorry if the definition is imprecise), a type establishes a set of valid values. Nat n = n does exactly that. For example, it forces type-level naturals to be normalized (i.e. numerals with leading zeros don't satisfy the Nat constraint) So I consider using a digit on the left as unclean. It's similar to using a number as the second part of a cons cell in LISP. Again, the comparisson is based on semantical implications of the implementation which shouldn't be visible for, or at least not taken into consideration by, the final user. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
On Feb 9, 2008 12:28 AM, Tom Hawkins [EMAIL PROTECTED] wrote: 5) Forget embedding the DSL, and write a direct compiler. In addition to the sharing problem, another shortcoming of Haskell DSLs is they can not fully exploit the benefits of algebraic datatypes. Specifically, pattern matching ADTs can only be used to control the compile-time configuration of the target, it can't be used to describe the target's behavior -- at least for DSLs that generate code that executes outside of Haskell's runtime. Only partly true. Probably you are not aware of them (I myself learned about its existence a few days ago) but pattern quasiquoting (available in GHC's HEAD) can be used for that. http://www.haskell.org/ghc/dist/current/docs/users_guide/template-haskell.html#th-quasiquotation Writing a real compiler would solve both of these problems. Is there any Haskell implementation that has a clean cut-point, from which I can start from a fully type-checked, type-annotated intermediate representation? If you have to write a compiler why not define a language which fits better with the semantics of the embedded language instead of using plain Haskell? The approach you propose has the disadvantages of both the embedded and the standalone languages. On one hand you have to stick with the syntax of the host language which may not fit with your exact semantical requirements and, on the other hand, you cannot take advantage of all the existing machinery around the host language (you have to code your own compiler). Furthermore, the first citizen status of functions make it impossible (or really difficult at least) to compile EDSL descriptions avoiding runtime and simply applying a static analysis approach (using Core or plain Haskell as input). And thanks for the link to John's paper describing Hydra's use of Template Haskell. I will definiately consider TH. Well, TH would be one of those static analysis approaches. Actually, O'Donell's implementation (which uses an outdated version of Template Haskell) only works with a small Haskell subset. So using TH you'd probably be changing the host language anyhow. Furthermore, the TH approach consists in adding node labels by preprocessing the EDSL description, making sharing observable. That makes the original EDSL description inpure. The only difference is that side effects are added by preprocessing instead of using runtime unsafe functions. Some pointers covering the topic: [1] and [2] summarize what are the alternatives to observe sharing in Haskell whereas [3] compares the embedded approach vs standalone approach and advocates the last one. 1) http://www.imit.kth.se/~ingo/MasterThesis/ThesisAlfonsoAcosta2007.pdf (section 2.4.1 and 3.1) 2) http://www.cs.um.edu.mt/svrg/Papers/csaw2006-01.pdf (section 3) 3) http://web.cecs.pdx.edu/~sheard/papers/secondLook.ps ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
Moving on to the implementation of fixed-sized vectors themselves ...
I have been trying to implement them as a GADT but I have run into
quite few problems. As a result, I'm considering to implement them
using the more-traditional phantom type-parameter approach. Anyhow,
I'd like to share those problems with the list, just in case someone
comes with a solution.
Here are some examples of what I was able to define without problems
(although, for some cases, I was forced to break the safety layer of
the GADT by using the toInt reflection function).
Save this email as FSVec.lhs to test them.
{-# LANGUAGE GADTs, Rank2Types, ScopedTypeVariables, KindSignatures #-}
module Data.Param.FSVec where
import Data.TypeLevel.Num
The Fixed Sized Vector data type. I know Wolfgang would prefer
something more closely named to LiSt to, but let's avoid getting into
that discussion now.
data FSVec :: * - * - * where
NullV :: FSVec D0 a
(:) :: Succ s s' = a - FSVec s a - FSVec s' a
infixr :
Some successful examples
headV :: Pos s = FSVec s a - a
headV (x : xs) = x
lastV :: Pos s = FSVec s a - a
lastV = lastV'
-- trusted function without the Pos constraint, otherwise the compiler
would complain about
-- the Succ constraint of : not being met.
where lastV' :: FSVec s a - a
lastV' (x : NullV) = x
lastV' (x : xs)= lastV' xs
atV :: (Pos s, Nat n, n :: s) = FSVec s a - n - a
atV v n = atV' v (toInt n)
-- Reflecting the index breaks checking that the recursive call
-- verifies the atV constraints, however I couldn't find another way.
-- atV' is to be trusted regarding the recursive call
where atV' :: FSVec s a - Int - a
atV' (x : xs) n
| n == 0 = x
| otherwise= atV' xs (n-1)
-- this defition is nicer but doesn't typecheck
-- atV (x : xs) n
-- | toInt n == 0 = x
-- | otherwise = atV xs (predRef n)
Now some functions which I wasn't able to define
Concat function. This would be the naive implementation, but it fails
to compile.
(+) :: Add s1 s2 s3 = FSVec s1 a - FSVec s2 a - FSVec s3 a
NullV + ys = ys
(x:xs) + ys = x : (xs + ys)
Tail function, which is also incorrect.
tailV :: Succ s' s = FSVec s a - FSVec s' a
tailV (x : xs) = xs
And finally, vector, which is supposed to build a fixed-sized vector
out of a list.
The ideal type for the function would be:
vector :: [a] - FSVec s a
But there is no apparent way in which to obtain s based on the length
of the input list.
[1] shows a way in which to create vector using CPS style and a
reification function:
reifyInt :: Int - (forall s . Nat s = FSVect s a - w) - w
The result would be a function with the following type:
vector :: [a] - (forall s . Nat s = FSVec s a - w) - w
Nevertheless, I'm not fully satisfied by it.
Another alternative would be forcing the user to provide the size
explicitly (which is ugly as well)
vector' :: Nat s = s - [a] - FSVec s a
The Succ constraint in the definition of : doesn't allow me to do
such a thing. The following implementation does not typecheck:
vector' :: Nat s = s - [a] - FSVec s a
vector' s l
| toInt s == length l = vector' l
| otherwise = error dynamic/static size mismatch
where vector'' :: [a] - FSVec s a
vector'' []= NullV
vector'' (x : xs) = x : vector' xs
The problem is that I don't know a way in which to bypass the Succ
constraint of : .
Using a traditional phantom type-parameter to express the size is the
only solution I can think of (which would also solve the problems of
init and tail). However, that would mean losing the ability of
pattern matching with (:).
Any comments/suggestions would be very much appreciated.
Cheers,
Fons
[1] http://ofb.net/~frederik/vectro/draft-r2.pdf
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 7, 2008 9:01 PM, Dan Weston [EMAIL PROTECTED] wrote:
This may be a GHC bug, but even though in the module
Data.TypeLevel.Num.Reps has the header
{-# LANGUAGE EmptyDataDecls, TypeOperators #-}
I still get an error with both ghc and ghci version 6.8.2 unless I throw
in the -XTypeOperators flag.
If you are using type operators in a module you have to supply the
flag, independently of what flags are supplied in other modules.
The same applies for other extensions which modify the _syntax_ of the
language (e.g. Template Haskell etc ...)
So, it's not a bug.
As a side note, even if the TypeOperators flag is supplied GHC 6.8.2
fires an error with the following declaration:
instance (Compare x y CEQ) = x :==: y -- GHC fires a Malformed
instance header error
whereas using an equivalent prefix definition works just fine
instance (Compare x y CEQ) = (:==:) x y
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 7, 2008 4:16 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Nat means all natural numbers except zero while Nat0 means all natural numbers (including zero). Since in computer science, natural numbers usually cover zero, we should use Pos instead of Nat and Nat instead of Nat0. Sounds sensible, actually Nat and Nat0 is confusing. However I would rather use Pos and Nat0 to make explicit that naturals include zero . Depending on the definition of naturals they might or might not include zero. http://en.wikipedia.org/wiki/Natural_number You seem to write 12 as 1 :+ 2 instead of () :+ 1 :+ 2. But I think, the latter representation should probably be prefered. With it, :+ always has a number as its left argument and a digit as its right. Without the () :+ we get ugly exceptional cases. You can see this, for example, in the instance declarations for Compare. With the second representation, we could reduce the number of instances dramatically. We would define a comparison of digits (verbose) and than a comparison of numbers based on the digit comparison (not verbose). Even if () would be preferred from the programmers point of view (I'm not sure how much we could reduce the number of instances though), it makes the representation less attractive on the user-side. Anyone using the library would find it annoying and would wonder why is it neccessary. Unless we find a way to use () only internally (we should use a one-character type to make it shorter to type) I think we should stick to current representation. :+ is already used as the constructor for complex numbers. We should probably use some different operator. Right. I didn't think about that, thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 7, 2008 8:38 PM, Dan Weston [EMAIL PROTECTED] wrote:
I know that naming is arbitrary, but...
Digits in types seems ugly to me. In this case, it is also redundant.
Everyone but FORTRAN programmers counts from 0, not 1. Nat and Pos seem
clear. Nat0 could even mean Nat \ {0}, the opposite of what is proposed,
so confusion is even increased with Nat0.
Ok, fair enough. I changed the names of Positives and Naturals (which
do include 0) for Pos and Nat.
The change (together with a connective rename from :+ to :* ) is
already pushed in the darcs repository.
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] I love purity, but it's killing me.
As I pointed out a few days ago in another thread, you can benefit from using Observable sharing [1] Be warned that Observable sharing is a non-conservative extension of Haskell and it breaks referential transparency. [1] http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html On Feb 8, 2008 7:33 AM, Tom Hawkins [EMAIL PROTECTED] wrote: I've been programming with Haskell for a few years and love it. One of my favorite applications of Haskell is using for domain specific languages. However, after designing a handful of DSLs, I continue to hit what appears to be a fundamental hurdle -- or at least I have yet to find an adequate solution. My DSLs invariably define a datatype to capture expressions; something like this: data Expression = Add Expression Expression | Sub Expression Expression | Variable String | Constant Int deriving Eq Using the datatype Expression, it is easy to mass a collections of functions to help assemble complex expressions, which leads to very concise programs in the DSL. The problem comes when I want to generate efficient code from an Expression (ie. to C or some other target language). The method I use invovles converting the tree of subexpressions into an acyclic graphic to eliminate common subexpressions. The nodes are then topologically ordered and assigned an instruction, or statement for each node. For example: let a = Add (Constant 10) (Variable i1) b = Sub (Variable i2) (Constant 2) c = Add a b would compile to a C program that may look like this: a = 10 + i1; b = i2 - 2; c = a + b; The process of converting an expression tree to a graph uses either Eq or Ord (either derived or a custom instance) to search and build a set of unique nodes to be ordered for execution. In this case a, then b, then c. The problem is expressions often have shared, equivalent subnodes, which dramatically grows the size of the tree. For example: let d = Add c c e = Add d d-- e now as 16 leaf nodes. As these trees grow in size, the equality comparison in graph construction quickly becomes the bottleneck for DSL compilation. What's worse, the phase transition from tractable to intractable is very sharp. In one of my DSL programs, I made a seemingly small change, and compilation time went from milliseconds to not-in-a-million-years. Prior to Haskell, I wrote a few DSLs in OCaml. I didn't have this problem in OCaml because each let expression was mutable, and I could use the physical equality operator to perform fast comparisons. Unfortunately, I have grown to love Haskell's type system and its lack of side effects, and could never go back. Is there anything that can be done to dramatically speed up comparisons, or is there a better approach I can take to extract common subexpressions? I should point out I have an opportunity to get Haskell on a real industrial application. But if I can't solve this problem, I may have to resort to far less eloquent languages. :-( Thanks for any and all help. -Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 6, 2008 4:32 AM, Bjorn Buckwalter [EMAIL PROTECTED] wrote: Well, could you elaborate a little on joining efforts? The effort I was planning to invest in my package consists mainly of creating a .cabal file plus some logistics to get tarballs to where they have to be. I understand that you (and Wolfgang) are creating a library of type level decimals for the purpose of constraining vector (list?) lengths. After that I haven't been paying attention fully to the thread. Is the goal to create a general-purpose library for type-level programming and my module would fit into that grander scheme? Yes,the idea is to create a Cabal-ready wide-scope type-level programming library, joining the operations implemented in the different type-level libraries which are around. The goal (or at least mine) is to provide a common reusable type-level library which saves constantly reinventing the wheel. I'll provide an initial implementation (just including naturals in decimal representation) soon. Wolfgang suggested adding booleans at a later point too if I recall properly. Any useful type-level operation should have a place in the library. Or did you have something else in mind with joining efforts? E.g. help reviewing your code or writing new code? This would certainly help too. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 7, 2008 2:30 AM, Bjorn Buckwalter [EMAIL PROTECTED] wrote: Ok. Is this what people want -- one big hold-all library with everything, as opposed to smaller more specialized packages? I guess I can see advantages (real or perceived) to both approaches. Apart from Dockins' typenats library there are no other user-friendly specific type-level libraries that know, so I cannot really tell if people would prefer a hold-all library or a couple of more granular specialized ones. Right now is not hold-all at all (it is still vaporware actually :)), so I think there's no reason to discuss that at this point. Let's see what people think. The other library I use for type-level programming is HList. It has type-level booleans already so you might what to take a look at it if you're not already familiar with it. Thanks I'll have a look at it. In fact, if you are serious about creating the de facto(?) type-level programming library trying to get Oleg involved would be very beneficial both in terms of innovation and credibility. Sure. I've actually been exchanging mail with Oleg. He has given me some useful suggestions and contributed with some code. He didn't mention to what point he wanted to get involved though, but I'm sure he will try to help. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 5, 2008 4:10 PM, Henning Thielemann [EMAIL PROTECTED] wrote: On Fri, 1 Feb 2008, Aaron Denney wrote: On 2008-02-01, Bjorn Buckwalter [EMAIL PROTECTED] wrote: If Naturals had been sufficient for me I wouldn't have done my own implementation (I'm unaware of any other implementation of Integers). And there is certainly a lot of value to the clearer error messages from a decimal representation. I did a balanced-base-three (digits are 0, and +- 1) representation to get negative decimals. Nice. In German the digit values are sometimes called eins, keins, meins. :-) I'm almost done with the decimal library but it would be nice to check some Integer implementations for future inclusion. So, Aaron, Björn, are your implementations available somewhere? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 5, 2008 8:29 PM, Bjorn Buckwalter [EMAIL PROTECTED] wrote: On Feb 5, 2008 2:16 PM, Alfonso Acosta [EMAIL PROTECTED] wrote: On Feb 5, 2008 4:10 PM, Henning Thielemann [EMAIL PROTECTED] wrote: On Fri, 1 Feb 2008, Aaron Denney wrote: On 2008-02-01, Bjorn Buckwalter [EMAIL PROTECTED] wrote: If Naturals had been sufficient for me I wouldn't have done my own implementation (I'm unaware of any other implementation of Integers). And there is certainly a lot of value to the clearer error messages from a decimal representation. I did a balanced-base-three (digits are 0, and +- 1) representation to get negative decimals. Nice. In German the digit values are sometimes called eins, keins, meins. :-) I'm almost done with the decimal library but it would be nice to check some Integer implementations for future inclusion. So, Aaron, Björn, are your implementations available somewhere? As noted elsewhere in the thread my implementation is available at: http://www.buckwalter.se/~bjorn/darcs/dimensional/Numeric/NumType.lhs Thanks! It is my intent to extract this (self-contained) module to its own package and put on hackage. It's been a low priority for me but I'm rather incentivized by this thread. Great! How about joining efforts? As I said I almost have a preliminary version of the decimal library which I'll realease for reviewing purpouses soon (It won't include Integer computations though) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 4, 2008 12:36 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Samstag, 2. Februar 2008 14:54 schrieben Sie: Again, if someone complains about the TH dependency, the aliases could be generated by TH but saved statically in a module for each release. Hmm, this could be a compromise although I'm not sure whether it is sensible to have a module with thousands of declarations. As long as the module is automatically generated I don't see why it would be a problem. Bear in mind that using TH would, in practice, be equivalent to code such a module by hand anyway. Another solution would be to put the Template Haskell convenience stuff into a separate package. The core package would probably be usable with Hugs too, while the convenience package would be usable only with GHC. I'm not sure if it worths it to create a separate package and add another dependency for those who would like to use it. I don't still know how many people would be interested in using the type-level library so, again, I think it won't hurt to include the TH-generated aliases and then change it if some non-GHC user rants about it. So type-level + parametrized-data is my vote. But don't let's spend too much time discussing the name. ;-) Fair enough. type-level + parameterized-data it is then (unless someone else has a better suggestion). I'm going to begin coding now. I'll host the project in community.haskell.org, do you have an account there? PS: BTW, I asked Oleg for permission and, as expected, agreed to create the library under a BS-D license. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 4, 2008 8:27 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Montag, 4. Februar 2008 13:22 schrieben Sie: I don't still know how many people would be interested in using the type-level library so, again, I think it won't hurt to include the TH-generated aliases and then change it if some non-GHC user rants about it. Okay, let's do so for now. Actually, I was considering to conditionally include the TH code or not depending on the compiler (using Cabal configurations). I thought that should make everyone happy. Then, I realized we agreed to make use of infix type constructors anyway (which seems to be a GHC-only extension, tell me if I'm wrong), so the TH dependency is not that important anymore (unless we decide to avoid infix type constructors) I'll host the project in community.haskell.org, do you have an account there? Now, I haven't. :-( Well, you can request one at http://community.haskell.org/admin/account_request.html if you want Otherwise I'll take the maintainer role. PS: BTW, I asked Oleg for permission and, as expected, agreed to create the library under a BS-D license. Great. So the packages you create now will be released under BSD3, right? Yes, that's the intention. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 1, 2008 10:33 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Actually it would maybe be better to create common high-level interface that could include unary, binary and decimal arithmetic so that the library could be easily reused in other projects (people like Bjorn, seem to be using the unary implementation). I don't know if it would be feasible though. I'd say, let's start with the decimal thing. We can extend our package later if there's a need to do this, can't we? OK, let's do it like that. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 1, 2008 10:32 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Freitag, 1. Februar 2008 13:00 schrieb Alfonso Acosta: On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch [EMAIL PROTECTED] This is essentially what I had in mind. While Oleg's implementation needs a thrusted core, the GADT solution doesn't. True. However using GADTs doesn't allow to internally make use of Arrays, which (tell me if I'm wrong) are likely to be faster than the naive GADT implementation. It depends. My first GADT implementation is equivalent to the [] type and often [] is better than arrays. For example, if you read the contents of a file and process it with maps, filters, etc., [] is likely to give you constant space usage which arrays don't. If you want to lookup elements by index, then arrays are better, of course. For my purpose, it would be fine to use a []-like implementation, I think. For mine it would be fine too. Let's implement our needs and then maybe extend it if someone rants about it. To make it friendlier for the end user I thought about defining aliases for lets say the first 1 numbers using Template Haskell. That could even make error reports friendlier (not sure to what point though). What do you think? I have no clear opinion about that at the moment. Maybe it's okay to use the representation directly. This way, we don't introduce a dependeny on the Template Haskell language extension (which is only supported by GHC), and the actual representation will occur in error messages anyway whenever the message shows a computed number. Well, my EDSL already makes extensive use of TH. So, being selfish, it wouldn't be a problem for me (or any other GHC user) and I think it would make the library much more usable. Just compare f :: List (() :- D1 :- D0 :- D0 :- 1000) Int - List (() :- D1 :- D0 :- D0 :- D0) Int with, let's say f :: List A1000 Int - List A1000 Int Again, if someone complains about the TH dependency, the aliases could be generated by TH but saved statically in a module for each release. So, we'll be making two separate libraries then. We should think about names. What about FixedVector for the vector library and DecTypArith (maybe too long) or DecTypes for the type-level decimal arithmetic library? Alas, there is an inconsistency in naming packages already. Some prefer names which are entirely lowercase, some prefer camel case. I prefer lowercase, with hyphens separating parts of the name. And I also don't like unusual abbreviations like typ (not much shorter than type). To mention arithmetics is not so important. So maybe something like type-level-decimals? Maybe it's better to put different type-level programming things into a single package. Then we could name this package type-level or something similar. We could start with our decimals. Other type-level things could be added later. I already have some code about type-level booleans. It's not very sensible to put these few lines into a separate package. It might be nice if we had a general type-level programming package where I could put this code into. Sounds sensible. However, I would rather prefer something like type-level-comp (from type level computations) or type-level-prog (from type level programming). Type level by itself doesn't describe the functionality of the package. As for the name of the fixed-size list package, I have to say that I don't like the term vector in this context. A vector is actually something with addition and scalar multiplication defined on it. Maybe we should make also this package's scope wider. What about something like safe-data or similar? I think safe-data is a bit too general and might lead to confusion with other safe data packages (namely Mitchell's Safe library). Since the main particularity of the library is that safety properties are achieved via emulating dependent types I think that light-dependent-types (from lightweight dependent types), number-parameterized-data or simply parameterized-data (this is the name I like best) would be more appropiate. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Feb 2, 2008 2:54 PM, Alfonso Acosta [EMAIL PROTECTED] wrote: Just compare f :: List (() :- D1 :- D0 :- D0 :- 1000) Int - List (() :- D1 :- D0 :- D0 :- D0) Int I meant f :: List (() :- D1 :- D0 :- D0 :- D0) Int - List (() :- D1 :- D0 :- D0 :- D0) Int sorry for the typo ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
On Jan 31, 2008 11:35 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Am Donnerstag, 31. Januar 2008 18:30 schrieb Dominic Steinitz: Look at http://sneezy.cs.nott.ac.uk/fun/feb-07/jeremy-slides.pdf This is essentially what I had in mind. While Oleg's implementation needs a thrusted core, the GADT solution doesn't. True. However using GADTs doesn't allow to internally make use of Arrays, which (tell me if I'm wrong) are likely to be faster than the naive GADT implementation. Actually the GADT implementation you proposed fits nicely with the Vector definition already used in my EDSL (it is isomorphic actually), but efficiency could be an issue. Some words on the representation of decimal numbers as types. While the representation with types of the form D1 (D2 (D3 Sz)) has the advantage of allowing numbers of arbitrary size, it has the disadvantage of a growing number of parantheses. In my opinion, it would be nicer to have somethink like D1 :- D2 :- D9 :- () with a right-associative operator :-. We could even build the digit list the other way round—() :- D1 :- D2 :- D9—using a left-associative :-. With the latter representation, we wouldn't need to reverse digit sequences when adding numbers. Right, I agree. I think we should use the arbitrary-size implementation (actually, how arbitrary is it? what's the limit of GHC, if any?). To make it friendlier for the end user I thought about defining aliases for lets say the first 1 numbers using Template Haskell. That could even make error reports friendlier (not sure to what point though). What do you think? So, we'll be making two separate libraries then. We should think about names. What about FixedVector for the vector library and DecTypArith (maybe too long) or DecTypes for the type-level decimal arithmetic library? I'll put my hands dirty once we agree on this. Cheers, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Implementing fixed-sized vectors (using datatype algebra?)
What about FixedVector for the vector library and DecTypArith (maybe too long) or DecTypes for the type-level decimal arithmetic library? Actually it would maybe be better to create common high-level interface that could include unary, binary and decimal arithmetic so that the library could be easily reused in other projects (people like Bjorn, seem to be using the unary implementation). I don't know if it would be feasible though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] fast graph algorithms without object identities
You'd probably be interested to read http://www.cs.chalmers.se/~koen/pubs/entry-asian99-lava.html On Jan 31, 2008 9:56 PM, Jan-Willem Maessen [EMAIL PROTECTED] wrote: On Jan 31, 2008, at 5:39 AM, Henning Thielemann wrote: It seems that algorithms on graphs can be implemented particularly efficient in low-level languages with pointers and in-place updates. E.g. topological sort needs only linear time, provided that dereferencing pointers requires constant time. I could simulate pointer dereferencings and pointer updates by Map yielding linear logarithmic time for topological sort. I wonder if it is possible to write a linear time topological sort using lazy evaluation, since the runtime system of Haskell implementations is a graph processor based on pointers. If so, I'd love to see this written up; I think it may be publishable if it isn't published already. Note that even using ST techniques can take more than linear time, given an arbitrary purely-functionally-defined graph as input. We can't (eg) assume that each node contains a reference, or that they are densely numbered, so we end up having to look them up in some fashion (though using a hash table can be reasonably quick if we uniquely number nodes). -Jan-Willem Maessen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Implementing fixed-sized vectors (using datatype algebra?)
Hi, The EDSL implementation (system design) I'm working on would really benefit from an implementation of fixed-sized vectors. I thought this would be a generally desired ADT but it turned out I wasn't able to find an implementation. I was thinking about using datatype algebra plus GADTs to implement a type-level parameter indicating the size of the vector. I'm a total noob with regard to GADTs and type-level algebra trickery. So my questions are: 1) Do you think it is feasible? Can you think about a better approach? 2) An implementation of type-level Naturals would really help. What has already been done? Thanks in advance, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implementing fixed-sized vectors (using datatype algebra?)
On Jan 31, 2008 3:03 PM, Wolfgang Jeltsch [EMAIL PROTECTED] wrote: Hello Fons, interestingly, it occured to me yesterday that the graphics part of Grapefruit would benefit from fixed sized vectors. I think we should implement some small Cabal package which just provides this and upload it to the HackageDB. Are you interested in cooperating with me on this? Sure I am! Actually, thanks to the pointers provided by Henning I learned that Oleg (who else!) already has implemented them. See http://okmij.org/ftp/Haskell/number-parameterized-types.html http://www.haskell.org/tmrwiki/NumberParamTypes http://okmij.org/ftp/Haskell/number-param-vector-code.tar.gz (Oleg's multiple flavour implementations of fixed-sized vectors) I think we should base our implementation on Oleg's (for which we need his permission). Actually, I think we should create two separate libraries. One for decimal type-level arithmetic and another for the vector implementation itself. What do you think? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Implementing fixed-sized vectors (using datatype algebra?)
I remember that type-level arithmetic is already implemented somewhere, certainly more than once, but certainly seldom in a nicely packaged form. erm, here http://www.haskell.org/haskellwiki/Type_arithmetic Yep, there seem to be a few implementations around (decimal, binary, peano) but Oleg's decimal one is likely to be the most friendly when it comes to compiler errors etc .. http://www.haskell.org/ghc/docs/latest/html/libraries/base/Data-Fixed.html#t%3AFixed also here: http://hackage.haskell.org/cgi-bin/hackage-scripts/package/numbers-2007.9.25 ? I'm probably missing something, but I don't understand how these libraries could help. Thanks, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Re[2]: [Haskell-cafe] Implementing fixed-sized vectors (using datatype algebra?)
On Jan 31, 2008 5:47 PM, Bulat Ziganshin [EMAIL PROTECTED] wrote: one more: darcs get --partial --tag '0.1' http://www.eecs.tufts.edu/~rdocki01/typenats/ Thanks for the link, I had already checked this library, but using a binary representation has the same problem as using peano numbers, error reports can be quite cryptic. I still think that using decimals is the way to go. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] threads + IORefs = Segmentation fault?
On Jan 19, 2008 2:36 PM, David Roundy [EMAIL PROTECTED] wrote: Using ghc 6.6, but I've since isolated the bug as being unrelated to the IORefs and threading, it was in an FFI binding that somehow never died until I was testing this new code. In case the you are creating a binding of haskell code. Did you make sure that the runtime constructor and destructor (hs_* functions) are properly called? The could be the source of the segfault. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: Haddock version 2.0.0.0
On Jan 8, 2008 1:28 PM, David Waern [EMAIL PROTECTED] wrote: Dear Haskell community, I'm proud to announce the release of Haddock 2.0.0.0! Great! I already tested a dracs spanshot before the release and seemed to work well with TH code. Any idea about when will hackage adopt this version to generate its documentation? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Type System (Was: Currying and Partial Evaluation)
On Jan 9, 2008 1:07 AM, Achim Schneider [EMAIL PROTECTED] wrote:
Beg pardon? Are you referring to the type of y being described with
'b' instead of 'a'?
Yes.
(a - a) - a and (b - b) - b are equivalent.
For some reason ghc uses b instead of a if you are picky about it,
just provide a type signature explicitly.
Prelude let {y :: (a - a) - a ; y f = f $ y f}
Prelude :t y
y :: (a - a) - a
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what does @ mean?.....
@ works as an aliasing primitive for the arguments of a function f x@(Just y) = ... using x in the body of f is equivalent to use Just y. Perhaps in this case is not really useful, but in some other cases it saves the effort and space of retyping really long expressions. And what is even more important, in case an error is made when choosing the pattern, you only have to correct it in one place. On Dec 28, 2007 12:05 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: Hello, I wonder if someone could answer the following… The short question is what does @ mean in mulNat a b | a = b = mulNat' a b b | otherwise = mulNat' b a a where mulNat' x@(S a) y orig | x == one = y | otherwise = mulNat' a (addNat orig y) orig The long version, explaining what everything means is…. here's a definition of multiplication on natural numbers I'm reading on a blog data Nat = Z | S Nat deriving Show one :: Nat one = (S Z) mulNat :: Nat - Nat - Nat mulNat _ Z = Z mulNat Z _ = Z mulNat a b | a = b = mulNat' a b b | otherwise = mulNat' b a a where mulNat' x@(S a) y orig | x == one = y | otherwise = mulNat' a (addNat orig y) orig Haskell programmers seem to have a very irritating habit of trying to be overly concise...which makes learnign the language extremely hard...this example is actually relatively verbosebut anyway... Z looks like Zero...S is the successor function...Nat are the Natural numbers. mulNat _ Z = Z mulNat Z _ = Z translates to... x * 0 = 0fine... 0 * x = 0fine.. mulNat a b | a = b = mulNat' a b b | otherwise = mulNat' b a a where mulNat' x@(S a) y orig | x == one = y | otherwise = mulNat' a (addNat orig y) orig is a bit more problematic... lets take a as 3 and b as 5... so now we have mulNat' 3 5 5 but what does the x@(S a) mean? in mulNat' x@(S a) y orig From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Nicholls, Mark Sent: 21 December 2007 17:47 To: David Menendez Cc: Jules Bean; haskell-cafe@haskell.org Subject: RE: [Haskell-cafe] nice simple problem for someone struggling Let me resend the code…as it stands…. module Main where data SquareType numberType = Num numberType = SquareConstructor numberType class ShapeInterface shape where area :: Num numberType = shape-numberType data ShapeType = forall a. ShapeInterface a = ShapeType a instance (Num a) = ShapeInterface (SquareType a) where area (SquareConstructor side) = side * side and the errors are for the instance declaration……. [1 of 1] Compiling Main ( Main.hs, C:\Documents and Settings\nichom\Haskell\Shapes2\out/Main.o ) Main.hs:71:36: Couldn't match expected type `numberType' against inferred type `a' `numberType' is a rigid type variable bound by the type signature for `area' at Main.hs:38:15 `a' is a rigid type variable bound by the instance declaration at Main.hs:70:14 In the expression: side * side In the definition of `area': area (SquareConstructor side) = side * side I'm becoming lost in errors I don't comprehend…. What bamboozles me is it seemed such a minor enhancement. From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of David Menendez Sent: 21 December 2007 17:05 To: Nicholls, Mark Cc: Jules Bean; haskell-cafe@haskell.org Subject: Re: [Haskell-cafe] nice simple problem for someone struggling On Dec 21, 2007 11:50 AM, Nicholls, Mark [EMAIL PROTECTED] wrote: Now I have module Main where data SquareType numberType = Num numberType = SquareConstructor numberType This is a valid declaration, but I don't think it does what you want it to. The constraint on numberType applies only to the data constructor. That is, given an unknown value of type SquareType a for some a, we do not have enough information to infer Num a. For your code, you want something like: instance (Num a) = ShapeInterface (SquareType a) where area (SquareConstructor side) = side * side -- Dave Menendez [EMAIL PROTECTED] http://www.eyrie.org/~zednenem/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] what does @ mean?.....
On Dec 28, 2007 12:21 PM, Nicholls, Mark [EMAIL PROTECTED] wrote: So in the example given... Is equivalent ? Yes, it is ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Applying a Dynamic function to a container of Dynamics
Hi all, dynApp allows to apply a Dynamic function to a Dynamic argument: dynApp :: Dynamic - Dynamic - Dynamic I don't seem to find a way (without modifying Data.Dynamic itself) to code this function import Data.Typeable import Data.Dynamic import Data.Foldable dynApp1 :: (Typeable1 container, Foldable container) = Dynamic - container Dynamic - Dynamic dynApp1 f-- originally of type :: container a - b val --- all its values _must_ have type :: b -- I get stuck when trying to transform val to type Dynamic (transform :: container Dynamic - Dynamic) in order to apply f nor even the more concrete case of lists dynAppList :: Dynamic - [Dynamic] - Dynamic Any suggestions? Thanks, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic typing of polymorphic functions
On Dec 19, 2007 9:13 PM, Neil Mitchell [EMAIL PROTECTED] wrote: OK, If you managed to read until this point, you might have noticed that, due to the monomorphism restriction implied by Data.Typeable, it is impossible to build polymorphic processes. Tom Shackell had similar issues with passing code around at runtime. As a result Yhc contains the Yhc.Dynamic module which gives you all polymorphic dynamic typing. It's integrated into the compiler and runtime system. Thanks for your answer Neil. From your description it _seems_ to be exactly what I need (I coudn't reallly figure it out form the sources since its implementation seems to rely on Yhc internals I totally ignore). Are there any examples of use available? Even if Yhc.Dynamic turns out to be what I need, my implementation unfortunately depends on Template Haskell. Could any GHC guru point out if this would be feasible (and how complicated) to implement in GHC? Thanks, Fons ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] Dynamic typing of polymorphic functions
Hi all, As some of you might remember I'm working on a EDSL which models process networks (A process can simply be viewed as a box which has a number of input and output signals and makes computations over them). A simple example of the processes implemented is MapSY, which is similar to Haskell's well-known map function. It takes a signal and a processing function as arguments and applies that function the signal. Following Lava's approach, a specifically designed Signal type hides and secretly forwards the structure of the network. Such structure is logically an untyped graph. For that reason, the processing functions associated to the different processes are kept in Dynamic form. A very simplified implementation could be: -- import Data.Typeable import Data.Dynamic -- the phantom type parameter makes signal typing consistent newtype Signal a = Signal PrimSignal newtype PrimSignal = PrimSignal (Proc (PrimSignal)) data Proc input = MapSY Dynamic -- The processing function input -- The process input -- the rest of the processes are omitted eval :: Proc Dynamic - Dynamic -- evaluates the output of a process for one input eval (MapSY dynF dynIn) = dynApp dynF dynIn -- the map process constructor mapSY :: (Typeable a, Typeable b) = (a - b) - Signal a - Signal b mapSY f (Signal primSig) = Signal (PrimSignal (MapSY (toDyn f) primSig)) - OK, If you managed to read until this point, you might have noticed that, due to the monomorphism restriction implied by Data.Typeable, it is impossible to build polymorphic processes. The approach works nicely for monomorphic processes though: add1 :: Signal Int - Signal Int add1 = mapSY ((+1) :: Int - Int) mapSndInt :: Signal (Int, Int) - Signal Int mapSndInt = mapSY (snd :: (Int, Int) - Int) But it does not work for building polymorphic processes. The following process would be really useful but its compilation obviously fails: mapSnd :: Signal (a, a) - Signal a mapSnd = mapSY snd Could not deduce (Typeable a) from the context () arising from a use of `mapSY' Possible fix: add (Typeable a) to the context of the type signature for `mapSnd' Again, due to the monomorphism restriction of the Typeable class, the compiler's suggestion of adding a Typeable context didn't work. (Well, strangely enough, adding the Typeable a constraint hushed GHC but an error was instead triggered at runtime). I must admit I'm totally stuck with this problem. My two options are: 1) Forcing the user to define mapSnd friends for each combination of types (which can hardly be considered an acceptable solution) 2) Think of a change in the internal representation of signals which made polymorphic processes possible. Polymorphic processes don't have to be necessarily definable by the user. They should be happy enough with a few polymorphic primitives (mapSnd would be one of them). * Maybe an implementation of unsafe dynamics using unsafeCoerce which allowed applying polymorphic functions to monomorphic values for specific safe cases? I would really appreciate any suggestions or remarks regarding my problem/design. Thanks in advance, Alfonso Acosta ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Dynamic typing of polymorphic functions
On Dec 19, 2007 9:13 PM, Neil Mitchell [EMAIL PROTECTED] wrote: OK, If you managed to read until this point, you might have noticed that, due to the monomorphism restriction implied by Data.Typeable, it is impossible to build polymorphic processes. Tom Shackell had similar issues with passing code around at runtime. As a result Yhc contains the Yhc.Dynamic module which gives you all polymorphic dynamic typing. It's integrated into the compiler and runtime system. Thanks for your answer Neil. From your description it _seems_ to be exactly what I need (I coudn't reallly figure it out form the sources since its implementation seems to rely on Yhc internals I totally ignore). Are there any examples of use available? Even if Yhc.Dynamic turns out to be what I need, my implementation unfortunately depends on Template Haskell. Could any GHC guru point out if this would be feasible (and how complicated) to implement in GHC? Thanks, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST Monad - what's wrong?
On Dec 9, 2007 2:39 PM, pepe [EMAIL PROTECTED] wrote: The typechecker in 6.6.1 gets confused by the ($) and loses track of the 'freeness' of s (the thread variable) . The same code should work fine in 6.8.1, or alternatively in 6.6.1 without the ($). True. However, note that the release notes of 6.8.1 encourage not to rely in this new feature because it can change in the feature. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ST Monad - what's wrong?
True. However, note that the release notes of 6.8.1 encourage not to rely in this new feature because it can change in the feature. I obviously meant in the future, sorry. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: ANNOUNCE: GHC 6.8.2 Release Candidate
I know there are some problems with Leopard (OSX 10.5) but, before bothering compile the release, should it be expected to work on Leopard/PPC or Leopard/Intel? On Dec 7, 2007 1:58 PM, Ian Lynagh [EMAIL PROTECTED] wrote: We are pleased to announce the Release Candidate phase for GHC 6.8.2. Snapshots beginning with 6.8.1.20071206 are release candidates for 6.8.2 You can download snapshots from here: http://www.haskell.org/ghc/dist/stable/dist/ Right now we have the source bundles: http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.1.20071206-src.tar.bz2 http://www.haskell.org/ghc/dist/stable/dist/ghc-6.8.1.20071206-src-extralibs.tar.bz2 Only the first of these is necessary. The extralibs package contains various extra packages that are often supplied with GHC - unpack the extralibs tarball on top of the source tree to add them, and they will be included in the build automatically. There is also currently an installer for i386/Windows and binary distributions for x86_64/Linux and i386/Linux. More may appear later. Please test as much as possible; bugs are much cheaper if we find them before the release! We expect to release in a few days, assuming no major issues are discovered. Thanks Ian, on behalf of the GHC team ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: You can now register a trac user for yourself
That's good news. It also means you can set your own preferences (if you did so with the guest account you ended up receiving mails related to ticket you didn't create) ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
[Haskell-cafe] [Offtopic?] Cabal package license and copyright holder question
Hi all, I don't know if this is the right place to ask but, since it's somehow Haskell-related I decided to use haskell-cafe. I'm cabalizing a library which, apart from my own code, has code taken from others. As it could be expected, each piece has its own copyright holder and (slightly) different license. The concrete holder and licenses are clearly annotated in every module. But, even with that, I'm not sure if I'm entitled to set an overall copyright holder and license for the whole cabal package. So, right now, I'm not sure about what license and holder filelds should I set in my .cabal file. Could anyone who had encounterd this problem before suggest a solution? Thanks, Fons ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Offtopic?] Cabal package license and copyright holder question
The copyright field is free-form so you can list all the copyright holders. You can use multiple lines. See for example: http://hackage.haskell.org/packages/archive/bytestring/0.9.0.1/bytestring.cabal Then for the license, use Other and specify a license file with all the appropriate license included in it, or refer to the license files of the various bits. Thanks for the quick reply Duncan, I'll make use of your suggestion. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] State of the GHC-embedded Haddock (AKA Haddock 2.0)?
Hi, Can someone shed some light on what's the state of GHC-Haddock? The thread [1] mentions a haddock.ghc repository which doesn't exist anymore. Are there any plans of releasing it anytime soon? I have a haddock-annotated library which makes massive use of TH, making Haddock 0.8 fail miserably Cheers, Fons . ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: State of the GHC-embedded Haddock (AKA Haddock 2.0)?
Can someone shed some light on what's the state of GHC-Haddock? The thread [1] mentions a haddock.ghc repository which doesn't exist anymore. Forgot to add the reference [1] http://www.mail-archive.com/[EMAIL PROTECTED]/msg20453.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
On Nov 19, 2007 10:35 AM, Simon Marlow [EMAIL PROTECTED] wrote: pwd gives you the directory that the script was invoked *from*, not the directory in which the script resides. This is a common problem on Unix: there's no general way to find out the location of a binary. Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
On Nov 19, 2007 10:51 AM, Alfonso Acosta [EMAIL PROTECTED] wrote: Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones. I meant _use_ the first argument of the script ($0) for absolute paths and combine it with pwd for relative ones. ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: GHC 6.8.1 on Mac OS X 10.5 (Leopard)
Simon, as usual, is right. It's been quite a while since I last seriously coded in C. From the exec* man page: The first argument, *by convention*, should point to the file name associated with the file being executed. However, if nothing better is found I guess it's better to rely on an extended convention rather than hardcoding paths. On Nov 19, 2007 11:40 AM, Simon Marlow [EMAIL PROTECTED] wrote: Christian Maeder wrote: Alfonso Acosta wrote: On Nov 19, 2007 10:51 AM, Alfonso Acosta [EMAIL PROTECTED] wrote: Well, you can always combine the first argument of the script ($0) for absolute paths and combine it with with pwd for relative ones. I meant _use_ the first argument of the script ($0) for absolute paths and combine it with pwd for relative ones. #!/bin/sh reldir=`dirname $0` topdir=`(cd $reldir; pwd)` There's no guarantee that $0 holds anything reasonable: you can set $0 to whatever you like when calling exec*(). Cheers, Simon ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
Re: [Haskell-cafe] can someone explain monad transformers to me, or how do you combine maybe and IO?
On Nov 13, 2007 1:08 AM, Luke Palmer [EMAIL PROTECTED] wrote: We want MaybeT! I third this proposal. It would be nice having MaybeT included in mtl. Besides, and although it's not exactly the same, you can emulate the Maybe monad by using the Either monad (the instance is defined in Control.Monad.Error). And in this case you want a monad transformer, so ErrorT can do the trick. Just consider that all the Left values are Nothing and the Right values are Just. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: missing Control.Monad.State
It seems you haven't the mtl package installed. You can either get a custom package for your OS distribution or grab it from hackage. On Nov 11, 2007 2:29 PM, Hal Daume III [EMAIL PROTECTED] wrote: Hi all -- Something weird just happened and I feel bad asking on the list for help (because it's a dumb question), but I've racked my brains and can't figure it out. I've been happily using ghc for some time now. My current machine died, and the computer folks gave me a new one. Both my old and new were running ubuntu. The new machine came in and I apt-get installed ghc6 ghc6-prof ghc6-docs haskell-mode ghc6-libsrc. But when I try to run ghc on a module that uses Control.Monad.State, I get: ~ ghc --make -fglasgow-exts Main.hs -o hbc Core.hs:24:7: Could not find module `Control.Monad.State': Use -v to see a list of the files searched for. If I say -v, I get: Glasgow Haskell Compiler, Version 6.6, for Haskell 98, compiled by GHC version 6.6 Using package config file: /usr/lib/ghc-6.6/package.conf wired-in package base mapped to base-2.0 wired-in package rts mapped to rts-1.0 wired-in package haskell98 mapped to haskell98-1.0 wired-in package template-haskell mapped to template-haskell-2.0 Hsc static flags: -static *** Chasing dependencies: Chasing modules from: Main.hs Core.hs:24:7: Could not find module `Control.Monad.State': locations searched: Control/Monad/State.hs Control/Monad/State.lhs *** Deleting temp files: Deleting: *** Deleting temp dirs: Deleting: Looking in /usr/lib/ghc-6.6/package.conf, I don't find any mention of Control.Monad.State (or anything with State) for that matter. A find in /usr/lib/ghc-6.6 doesn't turn up anything called State, either. I presume that I'm doing something incredibly stupid, but I'd appreciate a bit of help! Thanks! - Hal -- Hal Daume III --- me AT hal3 DOT name | http://hal3.name Arrest this man, he talks in maths. | http://nlpers.blogspot.com ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users ___ Glasgow-haskell-users mailing list Glasgow-haskell-users@haskell.org http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
