[Haskell-cafe] dependent types
in modeling real application we have often the case that the type of some object depends on a value. e.g. small_boat is a vessel with size less than a constant. big_boat is a vessel with a larger size. for example, many legal classifications are expressed in this form (e.g. car vs. truck) depending on the type, operations are applicable or not (e.g. road with restriction 'no trucks'). how could one model such situations in haskell? i assume there are several possibilities... ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] ANN: haskell-src-exts 1.9.0
Fellow Haskelleers, I'm pleased to announce the release of haskell-src-exts-1.9.0! * On hackage: http://hackage.haskell.org/package/haskell-src-exts * Via cabal: cabal install haskell-src-exts * Darcs repo: http://code.haskell.org/haskell-src-exts 1.8.2 -- 1.9.0 === * OptionPragma is renamed to the more descriptive ModulePragma, and adds a constructor AnnModulePragma for handling ANN pragmas preceding module header. * Add instances for Eq/Ord/Data/Typeable for Fixity. * Add 'parseFileWithComments' and 'parseFileContentsWithComments' to L.H.Exts . * More informative error messages when HSX tags are mismatched (thanks Gracjan Polak for the patch!) Cheers, /Niklas ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Dutch HUG Day: Program and Call for Participation
[Apologies for multiple copies.] --- Dutch HUG Day 24 April 2010 Ordina office Niewegein, The Netherlands --- *** *** Please register! *** *** Email Sean Leather leat...@cs.uu.nl by 20 April! *** INTRODUCTION To celebrate our first anniversary, the Dutch Haskell Users Group (HUG) invites Haskell and functional programming enthusiasts in the Netherlands and surrounding area to an afternoon symposium. The Dutch HUG is an informal group with monthly meetings including talks on novel applications of Haskell and socializing in the neighborhood pub. The group was founded on Sunday, April 19, 2009 at the Haskell Hackathon hosted in Utrecht. After a successful year, we renew the trend with the Dutch HUG Day. INVITATION *** Please send an email to Sean Leather leat...@cs.uu.nl by Tuesday, 20 April! *** Join us for a half day of fun and functional programming! We have some great praatjes (the Dutch word for talks) lined up. (Just in case you were confused by my Call for Praatjes, all talks will be in English.) Along with talks, you can join us afterwards for a buffet dinner, graciously provided by our sponsor Ordina. The registration will allow Ordina to know how many people to expect and to satisfy their security concerns. They are also looking for recruiting options and will send attendees an email describing potential opportunities. PROGRAM We are happy to announce a preliminary program. Note that the particular titles or order of talks may change, but the general schedule should remain the same. 13:00Reception 13:30Welcome 13:45Lightweight Program Inversion -- Janis Voigtländer (University of Bonn) 14:00Functional Programming in the Industry? -- Stef Joosten (Ordina, Open University of the Netherlands) 14:30BlazeHtml: Design of a Blazingly Fast HTML Combinator Library -- Jasper van der Jeugt (Ghent University) 15:00Functional Programming at typLAB -- Erik Hesselink (typLAB) 15:30Break 16:00Cλash: Haskell-ish Hardware Descriptions -- Matthijs Kooijman (formerly University of Twente) 16:30Why Haskell Does Not Matter -- Stefan Holdermans (Vector Fabrics) 17:00Lightweight Monadic Regions -- Bas van Dijk (Radboud University Nijmegen, Sensor Sense) 17:30Sirenial: Type-safe SQL Wrapper -- Martijn van Steenbergen (Utrecht University) 17:40Discussion 18:00Dinner 19:00Depart 19:30Drinks LOCATION The event will be held at the Ordina office in Niewegein, a town not far south of the city of Utrecht. You can get there by train to Utrecht Centraal and tram (the Utrecht sneltram) to P+R Westraven. Details on the location can be found at the following link, and we will put more information on our website soon. * http://www.ordina.com/Vestigingen/Nieuwegein.aspx SPONSOR We are grateful to Ordina for allowing us to host this event on their premises. They are also kindly providing drinks during the breaks and dinner afterwards for all participants. You should come and hear from our host how they make use of functional programming. * http://www.ordina.com/ in English * http://www.ordina.nl/ in het Nederlands ORGANIZERS * Sean Leather * Chris Eidhof MORE INFORMATION * Dutch HUG: http://dutchhug.nl/ * Dutch HUG Day: http://dutchhug.nl/DutchHugDay/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: dependent types
On Sun, 2010-04-11 at 10:59 +0200, Andrew U. Frank wrote:
in modeling real application we have often the case that the type of
some object depends on a value. e.g. small_boat is a vessel with size
less than a constant. big_boat is a vessel with a larger size. for
example, many legal classifications are expressed in this form (e.g. car
vs. truck)
depending on the type, operations are applicable or not (e.g. road with
restriction 'no trucks').
how could one model such situations in haskell? i assume there are
several possibilities...
I'd model upper type as actuall type and dependants as newtypes of it
with hidden constructors.
module Car
(
Car,
vehicleToCar,
carToVehicle,
)
where
import Vehicle
newtype Car = Car {carToVehicle :: Vehicle}
vehicleToCar :: Vehicle - Maybe Car
vehicleToCar v | someCondition = Just $! Car v
| otherwise = Nothing
Then you can request that:
moveSomeRoad :: Either Car Bicycle - IO ()
moveSomeRoad = ...
Regards
PS.
If it is possible to define a :-: b which would change (recusivly) a
replacing Either x b into x then you can define 'Vehicle' universe.
However I know too less about type functions to say it for sure.
signature.asc
Description: This is a digitally signed message part
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: GSoC proposal: Extend Cabal Preprocessors.
On Thu, 2010-04-08 at 22:10 -0400, Diego Echeverri wrote: Hi! I finish writing my proposal (maybe a bit too late). I would be glad to read any feedback. Hi Diego, Generally a good proposal. It would be great for Cabal's Simple build system to be able deal with pre-processor chaining and with pre-processors that do not have a simple 1:1 relationship between .hs and other source files. Here are two closely related issues you might like to think about: * pre-processors that have inter-module dependencies (e.g. c2hs) * pre-processors that generate modules from nothing ie there is no special file extension, simply a program that generates a specific module. This is common for things like adding the darcs context, or project-specific generation. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal-install
On Mon, 2010-03-08 at 17:33 +, Andrew Coppin wrote: Miguel Mitrofanov wrote: See http://www.haskell.org/cabal/ for more information. ^ | + Oh, sure, like I haven't already tried *that*. ;-) BTW, for future reference, the user guide on the cabal home page does mostly document the cabal command line interface. It talks about runghc Setup.hs blah but you can mentally substitute that for cabal blah and the same applies. At some point we'll update the user guide to be more specifically about the cabal program, rather than just about the Setup.hs interface. Volunteers welcome! I did recently switch the user guide from docbook xml to markdown, so it should be a lot easier for contributors. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
On Mon, 2010-03-08 at 13:33 +, Maciej Piechotka wrote: While I love Haskell it's packaging system have some problems - especially with parsec. Currently I'm not able to install an practically anything using cabal due to version mismatches (or at least packages linking to both version of parsec). I found the following problems in various cabal packages (the examples are only examples - please do not be offended): - The constraints are too loose. It is written that package works with '0.6 1' but in 0.8 the API has been changed (example of tagsoup hxt. Fixed hxt versions depends on ghc 6.12... and ghc 6.10 if you change 2 lines in cabal file) - The constraints are too tight. It is written that package works with 'parsec 3' but it can run with 3.0 and 3.1 (a lot of packages) Here are a few things which I would like to see implemented that would help all this: * Build reporting in the hackage server The idea here is that cabal sends back anonymous reports to the server to say if a package compiled or not, and against what versions of dependencies. This would make it clearer to maintainers if their dependency versions are correct. Additionally I think it would be useful for hackage to provide tweaked .cabal files for packages with updated constraints, even without new version uploads. We are proposing a GSoC project which would cover some of this. * A package API tool and greater use of the PVP We do have a package versioning policy that maintainers can choose to follow. This helps users of the package write more accurate dependency version constraints. What we lack is a tool to help maintainers check that they are correctly following the PVP. We also have a GSoC proposal for a package tool. * Private build-depends This would help the parsec 2 vs parsec 3 issue. Most packages that depend on parsec, or QuickCheck, do not export (as part of their public API) functions that use types from the parsec/QC packages. That is, the use of those packages is entirely encapsulated and invisible to clients. In this case, diamond dependency problems are impossible and it would be ok to use different versions of the same package within the same dependency graph. Currently cabal does not know which build-depends are public and which are private. The extension would be to let package authors mark some depends as private (though this would also need to be checked). * Improved dependency resolution algorithm in cabal-install The constraint solver is currently not very smart. It does not do so well with tight version constraints, which is exactly what we will get more of, as people use the PVP more. The resolver could be improved to do significantly better in these situations. I have an algorithm in my head, but not much time to implement it. Volunteers welcome on all tasks. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Multiple versions of a cabal package Or what's the right way to update?
On Sun, 2010-03-14 at 17:50 +0100, david fries wrote: Dear Caféistas I desperately need your collective knowledge I have been working on porting the haskell-platform to the FreeBSD operating system for a while now and some versioning issues have come up. FreeBSD is still running on GHC-6.10.4 (6.12 is in the works). The ghc package contains a couple of libraries that ghc is built against and requires to run. For instance, network-2.2.1.2 is one of them. You mean the FreeBSD ghc port includes a bundle of extra libraries including network? Note that the source ghc package does not include network. The network package an extra library that should be packaged separately. The problem is that the Haskell Platform requires version 2.2.1.4. Yes, the platform is free to pick that version precisely because it is not a core package that is distributed with ghc. Under normal circumstances we would port network-2.2.1.4 to FreeBSD and then specify it as a dependency of the Platform port. But then we end up with two (exposed) versions of network installed on the system. Sounds like the solution is to remove the network package that is bundled in the FreeBSD ghc port. I understand it may be impractical for you to change it at this stage and that perhaps such unbundling has to wait until you package ghc 6.12. In a perfect world, I'd be able to install the required HP dependencies without tripping ghc up. Then we could switch over to the platform as a foundation of GHC-6.12. I have lots of questions. Is it smart to have multiple installed versions of the same library? Up until now, we could avoid such situations. It is generally better for distributions not to bundle multiple versions of a package. For the Haskell Platform we make sure that this is possible. We never use a different version of a core library than those that come with the ghc version that HP release targets. If it is perhaps a bad idea to update certain core libraries, is there a way to declare them as such in the cabal file? Core packages are those that actually come with ghc. All other Haskell packages should get their own distro package. Then the HP meta-package depends on the exact versions as appropriate for that HP release. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
* Build reporting in the hackage server The idea here is that cabal sends back anonymous reports to the server to say if a package compiled or not, and against what versions of dependencies. This would make it clearer to maintainers if their dependency versions are correct. Additionally I think it would be useful for hackage to provide tweaked .cabal files for packages with updated constraints, even without new version uploads. We are proposing a GSoC project which would cover some of this. Hmm. I guess there are 2 problems: - Privacy problem. I don't want the software to call home with data without asking. - Spoofing problem. Someone can feed wrong data easily without chance of being discovered (for example to prove how grate 'haxor' he is). Regards signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Difficulties installing LLVM bindings
To actually build the examples, I also needed to remove references to the addCondPropagation optimization pass. I don't know why. I attached the darcs patch I'm using. Aran On Sat, Apr 10, 2010 at 4:42 PM, Aran Donohue aran.dono...@gmail.comwrote: UNIVERSAL=1 worked for me too. Is there a way for cabal install to detect if LLVM wasn't built with this required flag and give a more informative error message? Aran On Sat, Apr 10, 2010 at 2:28 AM, Max Bolingbroke batterseapo...@hotmail.com wrote: On 10 April 2010 03:18, Aran Donohue aran.dono...@gmail.com wrote: problems with ghc-pkg. I think we need to rebuild LLVM forcing 32-mode, but I haven't yet found the results of this. I'd love to hear what you did if you manage to get it going and compile programs. My LLVM checkout was still recompiling when I sent that email, but it's now finished and it fixed the problem. All you need to do is compile LLVM as follows: $ UNIVERSAL=1 make Then make install the result. That made the LLVM bindings configure and compile fine for me. Cheers, Max addCondPropRemoved.dpatch Description: Binary data ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] passing cpp options to c2hs from cabal
On Mon, 2010-03-01 at 10:07 -0500, Chris Casinghino wrote: This works great, thanks! As a footnote: I doubt I will be the only one is confused because cc-options get passed to c2hs but cpp-options don't. Perhaps the cabal designers should revisit this choice. I mostly agree. What is a bit odd about c2hs is that it mixes cpp flags for the C headers with cpp flags for the .chs file itself. So cc-options are really for the C code, and those get passed to c2hs. The cpp-options are for pre-processing Haskell code, and indeed arguably these should be passed to c2hs too because recent c2hs versions also apply something approximating cpp to the .chs file itself. So depending on whether your -U__BLOCKS__ flag is to influence the C headers or the contents of the .chs file, then use cc-options or cpp-options. I'll update this for some future release. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Alternative dependencies in Cabal file
On Fri, 2010-03-19 at 00:34 +0100, Henning Thielemann wrote: Matthias Reisner schrieb: Thanks, I missed that the flags are set dynamically if a dependency cannot be satisfied. Only cabal-install does this, plain Cabal only takes flags that were set by the user. No, plain Cabal does it too. You're thinking of the fact that only cabal-install does automatic package dependency resolution. Both do automatic flag resolution. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] developing against privately patched libraries, and cabal
On Sun, 2010-03-21 at 13:15 -0400, Leon Smith wrote: As somebody who's hacked on cabal-install a bit (but don't have a worthwhile patch to contribute (yet?)), I can tell you that versions support a tag structure, at least internally, but I haven't seen a non-empty tags field and don't know how to make the tags field non-empty. For that I'd have to go source-code diving again. We no longer use tags because they have no sane semantics. Yes, the tag is still present internally in the Version type, however I hope to eventually eliminate it entirely. Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] libraries and executables in cabal
On Thu, 2010-03-25 at 14:52 +0100, Paul Brauner wrote: Hi, i'm working on a project made of - lots of modules - one excutable importing these modules - another excutable importing these same modules I don't especially want to expose those modules as libraries, especially on hackage, since they are meaningless without the executables. But, if I declare two executables in my .cabal file, cabal will compile all those modules two times each time I want to compile the executables. Is there a way to tell cabal that those modules should be considered part of a private library ? Not yet. We recently added the ability for executables within a package to depend on a public library [1]. What we are missing is the ability to specify convenience or private libraries [2]. [1]: http://hackage.haskell.org/trac/hackage/ticket/89 [2]: http://hackage.haskell.org/trac/hackage/ticket/276 Duncan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
Am Sonntag 11 April 2010 18:43:30 schrieb Maciej Piechotka: * Build reporting in the hackage server The idea here is that cabal sends back anonymous reports to the server to say if a package compiled or not, and against what versions of dependencies. This would make it clearer to maintainers if their dependency versions are correct. Additionally I think it would be useful for hackage to provide tweaked .cabal files for packages with updated constraints, even without new version uploads. We are proposing a GSoC project which would cover some of this. Hmm. I guess there are 2 problems: - Privacy problem. I don't want the software to call home with data without asking. I think in the default cabal config, build-reporting would be turned off and you'd have to turn it on yourself. Turning it on by default wouldn't be sensible. - Spoofing problem. Someone can feed wrong data easily without chance of being discovered (for example to prove how grate 'haxor' he is). Regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
Excerpts from Daniel Fischer's message of Sun Apr 11 16:20:30 -0400 2010: I think in the default cabal config, build-reporting would be turned off and you'd have to turn it on yourself. Turning it on by default wouldn't be sensible. I doubt you'd get very much runtime with that. I'd suggest prompting the user to submit a failed build report if the build fails. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
On Sun, Apr 11, 2010 at 9:26 AM, Duncan Coutts duncan.cou...@googlemail.com wrote: On Mon, 2010-03-08 at 13:33 +, Maciej Piechotka wrote: While I love Haskell it's packaging system have some problems - especially with parsec. Currently I'm not able to install an practically anything using cabal due to version mismatches (or at least packages linking to both version of parsec). I found the following problems in various cabal packages (the examples are only examples - please do not be offended): - The constraints are too loose. It is written that package works with '0.6 1' but in 0.8 the API has been changed (example of tagsoup hxt. Fixed hxt versions depends on ghc 6.12... and ghc 6.10 if you change 2 lines in cabal file) - The constraints are too tight. It is written that package works with 'parsec 3' but it can run with 3.0 and 3.1 (a lot of packages) Here are a few things which I would like to see implemented that would help all this: * Build reporting in the hackage server The idea here is that cabal sends back anonymous reports to the server to say if a package compiled or not, and against what versions of dependencies. This would make it clearer to maintainers if their dependency versions are correct. Additionally I think it would be useful for hackage to provide tweaked .cabal files for packages with updated constraints, even without new version uploads. We are proposing a GSoC project which would cover some of this. * A package API tool and greater use of the PVP We do have a package versioning policy that maintainers can choose to follow. This helps users of the package write more accurate dependency version constraints. What we lack is a tool to help maintainers check that they are correctly following the PVP. We also have a GSoC proposal for a package tool. * Private build-depends This would help the parsec 2 vs parsec 3 issue. Most packages that depend on parsec, or QuickCheck, do not export (as part of their public API) functions that use types from the parsec/QC packages. That is, the use of those packages is entirely encapsulated and invisible to clients. In this case, diamond dependency problems are impossible and it would be ok to use different versions of the same package within the same dependency graph. Currently cabal does not know which build-depends are public and which are private. The extension would be to let package authors mark some depends as private (though this would also need to be checked). * Improved dependency resolution algorithm in cabal-install The constraint solver is currently not very smart. It does not do so well with tight version constraints, which is exactly what we will get more of, as people use the PVP more. The resolver could be improved to do significantly better in these situations. I have an algorithm in my head, but not much time to implement it. I've noticed another type of diamond dependency problem. Suppose I build and install Foo today and it depends on Bar 2.0.0. In a week, I install Bar 2.0.1. Next I installed Baz that also depends on Bar, and it gets Bar 2.0.1. When I install a package that depends on Foo, Baz, and possibly Bar, then cabal won't be able to figure out proper dependencies because Foo needs one version of Bar and Baz needs a different version. But if all these packages followed the PVP, then either version of Bar could have been used, if it was used consistently. i'm not sure what is the best solution to this problem. Perhaps in this scenario, cabal should ask the user if it should rebuild Foo and/or Baz so they use the same Bar. I think this could lead to a lot of rebuilding, and that rebuilding gets tedious when you're doing it manually. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
Edward Z. Yang ezy...@mit.edu writes: I doubt you'd get very much runtime with that. I'd suggest prompting the user to submit a failed build report if the build fails. Exactly like how Windows keeps prompting you to allow it to send an error report to Microsoft? I don't know about you, but I always found it irritating... -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dependent types
On Sun, Apr 11, 2010 at 1:59 AM, Andrew U. Frank fr...@geoinfo.tuwien.ac.at
wrote:
in modeling real application we have often the case that the type of
some object depends on a value. e.g. small_boat is a vessel with size
less than a constant. big_boat is a vessel with a larger size. for
example, many legal classifications are expressed in this form (e.g. car
vs. truck)
depending on the type, operations are applicable or not (e.g. road with
restriction 'no trucks').
how could one model such situations in haskell? i assume there are
several possibilities...
The two main ways I can think of for this use typeclasses or witness types.
The type class way is like this:
class Vehicle a where
data Car
data Truck
instance Vehicle Car where
instance Vehicle Truck where
Now you can have things that take a Car or a Truck or they can take a
Vehicle instead.
moveVehicle :: Vehicle v = v - Simulation ()
carsOnly :: Car - ...
If you want to understand this approach better, I think this is how HList
works to some extent. For example, see their HBool type class.
Or, you could use witness types:
data Vehicle classification = Vehicle { ... }
mkCar :: Vehicle Car
mkTruck :: Vehicle Truck
Then you would export the smart constructors, (mkCar/mkTruck) without
exporting the Vehicle constructor.
moveVehicle :: Vehicle c - Simulation ()
carsOnly :: Vehicle Car - ...
In the witness type version you may find that defining Vehicle as a GADT is
even better:
data Vehicle classification where
mkCar :: ... - Vehicle Car
mkTruck :: ... - Vehicle Truck
This is nice because it's direct and when you pattern match on the
constructor you recover the type of classification. For example, I believe
this would type check:
foo :: Vehicle c - c
foo (mkCar ...) = Car
foo (mkTruck ...) = Truck
(Note: I didn't test any of the above, so I could have errors/typos.)
Jason
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal dependency hell
Excerpts from Ivan Lazar Miljenovic's message of Sun Apr 11 17:37:15 -0400 2010: Edward Z. Yang ezy...@mit.edu writes: I doubt you'd get very much runtime with that. I'd suggest prompting the user to submit a failed build report if the build fails. Exactly like how Windows keeps prompting you to allow it to send an error report to Microsoft? I don't know about you, but I always found it irritating... I think the primary irritation is that Microsoft gets all of these error reports and they disappear into the great black VOID. Some public statistics might help alleviate the irritation. Cheers, Edward ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dependent types
On 11 April 2010 22:54, Jason Dagit da...@codersbase.com wrote: ... class Vehicle a where data Car data Truck instance Vehicle Car where instance Vehicle Truck where Now you can have things that take a Car or a Truck or they can take a Vehicle instead. moveVehicle :: Vehicle v = v - Simulation () unfortunately, now you cannot use pattern matching while defining moveVehicle. ... Jason -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] dependent types
On Sun, Apr 11, 2010 at 4:15 PM, Ozgur Akgun ozgurak...@gmail.com wrote: On 11 April 2010 22:54, Jason Dagit da...@codersbase.com wrote: ... class Vehicle a where data Car data Truck instance Vehicle Car where instance Vehicle Truck where Now you can have things that take a Car or a Truck or they can take a Vehicle instead. moveVehicle :: Vehicle v = v - Simulation () unfortunately, now you cannot use pattern matching while defining moveVehicle. That's true. Although, if you're writing a simulation where Cars and Trucks are objects in that simulation, they are likely to be defined as records as they will probably have many fields. If that's the case, it's unlikely you'd be using pattern matching with them anyway. It's just a small step from there to using typeclass functions to access the parts you care about. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] floating-point comparison (was haskell gsoc proposal for richer numerical type classes and supporting algorithms)
On Thu, Apr 8, 2010 at 7:29 PM, Doug Burke doug_j_bu...@yahoo.com wrote: --- On Thu, 4/8/10, Gregory Crosswhite gcr...@phys.washington.edu wrote: From: Gregory Crosswhite gcr...@phys.washington.edu On a tangental note, I've considered coding up a package with an AlmostEq typeclass that allows one to test for approximate equality. The problem is that different situations call for different tolerances so there is no standard approximate equal operator that would work for everyone, but there might be a tolerance that is good enough for most situations where it would be needed (such as using QuickCheck to test that two different floating-point functions that are supposed to return the same answer actually do so) to make it worthwhile to have a standard package for this around for the sake of convenience. Anyone have any thoughts on this? I've always wondered if Haskell would make it easy to track number of significant digits. The other thought is that you could probably use Oleg's implicit configurations to handle the tolerance in a rather nice way: http://www.cs.rutgers.edu/~ccshan/prepose/prepose.pdf The example in the paper is managing the modulus implicitly and I would imagine the amount of precision could be managed similarly. Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Cabal, GHC and Preprocessors
I want identifier concatenation in Haskell. For instance:
#define CDecl(n) = class C_##n a where { f_##n :: a };
CDecl(1)
CDecl(2)
CDecl(3)
(Actual motivator involves generating by type kind.)
I have no trouble switching on CPP, but this doesn't work.
The trouble is, GHC uses gcc for preprocessing, and it passes
-traditional which switches this off. There doesn't seem to be a flag
to override this.
I've tried replacing the GHC preprocessor with cpphs using -pgmP, but
GHC passes include files using -include, while cpphs only accepts
--include.
I've tried telling Cabal to use cpphs, but even if you rename the source
file to .cpphs, it will still use GHC's gcc preprocessor rather than
cpphs. In any case, it's not clear how to tell Cabal to pass --hashes to
cpphs.
I've tried using Template Haskell instead, but you can't easily splice
identifiers, only expressions, types and top-level declarations.
--
Ashley Yakeley
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
