From omari at smileystation.com Fri May 1 01:46:25 2015 From: omari at smileystation.com (Omari Norman) Date: Thu, 30 Apr 2015 21:46:25 -0400 Subject: [Haskell-cafe] Is it acceptable if Applicative behave not like a Monad In-Reply-To: References: Message-ID: On Thu, Apr 30, 2015 at 1:32 PM, Nikita Volkov wrote: > I'm afraid I have to disagree with Adam as well. Recently I've triggered a > prolonged discussion on exactly the subject ( > https://github.com/ekmett/either/pull/38). Being originally convinced > that the instances can behave however it fits, I think I've been > over-persuaded in the end. > > Shortly speaking, while I can't say I like it, the rule seems to be that > `<*>` should produce the same side effects as Monad's `ap`. > > One example of a library where the Applicative and Monad instances mismatch is uu-parsinglib. http://stackoverflow.com/questions/18275123/cannot-compute-minimal-length-of-a-parser-uu-parsinglib-in-haskell/18292328#18292328 There's a good reason the library is this way but the behavior can be rather startling. -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Fri May 1 05:11:49 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Thu, 30 Apr 2015 22:11:49 -0700 Subject: [Haskell-cafe] Is it acceptable if Applicative behave not like a Monad In-Reply-To: References: Message-ID: Why can't the library provide a `newtype`, one which supports `Applicative` *and* `Monad` interfaces (where the applicative and monadic interfaces match), and an un-newtyped variant that only supports `Applicaative`, as well as conversion functions? I think this would be clearer, as it would force you to switch into "Monad"-mode purposefully, and the documentation on the conversion function can make very clear what is going on. I agree that, now that we have AMP, applicative and monadic interfaces absolutely *should* match, and that it should be considered an error for them not to; semantically different interfaces can be provided with newtypes. -- Andrew On Thu, Apr 30, 2015 at 6:46 PM, Omari Norman wrote: > On Thu, Apr 30, 2015 at 1:32 PM, Nikita Volkov > wrote: > >> I'm afraid I have to disagree with Adam as well. Recently I've triggered >> a prolonged discussion on exactly the subject ( >> https://github.com/ekmett/either/pull/38). Being originally convinced >> that the instances can behave however it fits, I think I've been >> over-persuaded in the end. >> >> Shortly speaking, while I can't say I like it, the rule seems to be that >> `<*>` should produce the same side effects as Monad's `ap`. >> >> > One example of a library where the Applicative and Monad instances > mismatch is uu-parsinglib. > > > http://stackoverflow.com/questions/18275123/cannot-compute-minimal-length-of-a-parser-uu-parsinglib-in-haskell/18292328#18292328 > > There's a good reason the library is this way but the behavior can be > rather startling. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri May 1 05:36:50 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 1 May 2015 06:36:50 +0100 Subject: [Haskell-cafe] Is it acceptable if Applicative behave not like a Monad In-Reply-To: References: Message-ID: <20150501053650.GA9137@weber> On Thu, Apr 30, 2015 at 10:11:49PM -0700, Andrew Gibiansky wrote: > Why can't the library provide a `newtype`, one which supports `Applicative` > *and* `Monad` interfaces (where the applicative and monadic interfaces > match), and an un-newtyped variant that only supports `Applicaative`, as > well as conversion functions? This sounds like the right solution to me. From ky3 at atamo.com Fri May 1 07:16:00 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 1 May 2015 14:16:00 +0700 Subject: [Haskell-cafe] Haskell Weekly News Message-ID: *Top Picks:* - Haskell wins a bumper crop of 18 accepted Google Summer of Code proposals . Mentor offers total 44, another thumpin' sign of life. Kudos to Edward Kmett, Johan Tibell, Shachaf Ben-Kiki, and Gershom Bazerman. Gloria Haskella sine labore nulla. - Reddit Haskell celebrates 20k subscribers. It's the 7th largest PL community on reddit after python, javascript, java, php, ruby, c++, in that order. - Matthew Griffith migrates away from Python: "I do most of my web prototyping in Haskell now." A journey vividly logged and much loved on Hacker News . And also on Proggit and Reddit Haskell . - A web developer migrates away from Rails to Haskell and explains on HN the 10x advantage he reaps. - Fancy Python in Haskell dress? Check out Dogelang , charmingly defiant: "With Haskell's syntax but none of its type system, dg is the best way to make fans of static typing shut up already." Proggit kibbitzing here , HN there . - Caio Rordrigues copiously illustrates Haskell programming. Pretty: a tax bracket tool and a coffee shop Point-of-Sale DSL . It's almost a whole book! - Christian Marie starts the ball rolling on library cheatsheets to guide your way through the jungle of hackage. Moar, moar! - Got a C library you'd love Haskell bindings for? Remember Ian Ross and his new C2HS release ? Well, Ian's happy to do it for you. Provisos apply. - Olle Fredriksson announces a combinator-based Earley parsing library which accepts context-free but not context-sensitive (monadic parsing) grammars. Discussion reveals that "one enormously important difference for this library is that it reports all possible parses." - Another Lennart, last name Spitzner, creates another genie that turns type signatures into programs. Unlike Djinn, Exference makes no promises over termination. "Your wish is my command even at the expense of closure." - Like Agda? You can now enjoy the hole-driven development style in Haskell, brought to you courtesy of Mote by Izaak Meckler . Discussion here . - Federico Tomassetti creates a web-based interface to Andrew Gallant's erd tool . Entity-Relationship Diagrams (ERD) come from the database world and help visualize {one,many} to {one,many} relationships. Federico's web app enables him to use erd everywhere without having to install the tool chain multiple times. - Mark Dominus gives a beginner spin to the chestnut of SEND + MORE = MONEY . This puzzle site has comparisons with other languages. - Got a number system? Flip it into a data structure . Re-flip it into an efficient search algorithm . Edward Kmett shows you how. Respective discussion here and here . *In Memoriam* - A key founder of Haskell, Professor Paul Hudak, completed his end-of-life plan after a five-year encounter with leukemia. He stays in the thoughts of all who cherish his gifts from the heart. *Quotes of the Week* - A type system flattens the cost of change curve . -- Chad Austin - The MLs and Haskell remind me of Brian Eno's line about how the first Velvet Underground album only sold 30,000 copies, but "everyone who bought one of those 30,000 copies started a band". -- Source - On the value of Haskell : I find I'm able to accomplish tasks which would otherwise be beyond my skill and intelligence. For example, even though C was the first language I learned, I can't imagine writing a parser in C after discovering the simplicity & readability of monadic parsing in Haskell. - Haskell's level of abstraction is so crazy that they can actually swap out their entire I/O system for another one without changing any application interfaces, this one blew my mind, it's the change that makes GHC 7.8 run the Warp webserver twice as fast. ... All of this without changing a line in Warp, they just transparently made every traditional Haskell use modern I/O principles. Academics man, they're smart ;) -- Source - An old man loved is winter with flowers. -- Edgar Z. Friedenberg *Cool Beans of the Week* - Ravi Chugh and his fine team at U. Chicago just concluded stateside's first ever FRP-based FP course for undergrads using Elm. Check out the student projects for inspiration on FRP architecture. Over in Bonn, Janis Voigtl?nder also gave such a course that completed this year. Paul's legacy lives on. p.s. Coming soon: Cabal Hell -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Fri May 1 10:36:28 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Fri, 1 May 2015 12:36:28 +0200 Subject: [Haskell-cafe] Is it acceptable if Applicative behave not like a Monad In-Reply-To: <20150501053650.GA9137@weber> References: <20150501053650.GA9137@weber> Message-ID: If you don't mind your users wishing you death when they code breaks when they combine applicative style with do notation like: foo <- bar <$> baz <*> qux then sure, go ahead. Seriously, though, Andrew Gibiansky is right, use a newtype. Best regards, Marcin Mrotek From R.Paterson at city.ac.uk Fri May 1 12:00:11 2015 From: R.Paterson at city.ac.uk (Ross Paterson) Date: Fri, 1 May 2015 13:00:11 +0100 Subject: [Haskell-cafe] Is it acceptable if Applicative behave not like a Monad In-Reply-To: References: Message-ID: <20150501120011.GA4036@city.ac.uk> On Thu, Apr 30, 2015 at 10:11:49PM -0700, Andrew Gibiansky wrote: > I agree that, now that we have AMP, applicative and monadic interfaces > absolutely *should* match, and that it should be considered an error for them > not to; semantically different interfaces can be provided with newtypes. This requirement is in the documentation for both Applicative and Monad classes. (It's been in Applicative since 2010, and was added to Monad in the AMP release.) From P.Achten at cs.ru.nl Fri May 1 12:39:50 2015 From: P.Achten at cs.ru.nl (Peter Achten) Date: Fri, 01 May 2015 14:39:50 +0200 Subject: [Haskell-cafe] [TFP'15] call for participation Message-ID: <55437416.7060803@cs.ru.nl> ----------------------------- L A S T C A L L F O R P A R T I C I P A T I O N ----------------------------- ======== TFP 2015 =========== 16th Symposium on Trends in Functional Programming June 3-5, 2015 Inria Sophia Antipolis, France http://tfp2015.inria.fr/ The symposium on Trends in Functional Programming (TFP) is an international forum for researchers with interests in all aspects of functional programming, taking a broad view of current and future trends in the area. It aspires to be a lively environment for presenting the latest research results, and other contributions (see below). Authors of draft papers will be invited to submit revised papers based on the feedback receive at the symposium. A post-symposium refereeing process will then select a subset of these articles for formal publication. The selected revised papers will be published as a Springer Lecture Notes in Computer Science (www.springer.com/lncs) volume. TFP 2015 will be the main event of a pair of functional programming events. TFP 2015 will be accompanied by the International Workshop on Trends in Functional Programming in Education (TFPIE), which will take place on June 2nd. The TFP symposium is the heir of the successful series of Scottish Functional Programming Workshops. Previous TFP symposia were held in * Edinburgh (Scotland) in 2003; * Munich (Germany) in 2004; * Tallinn (Estonia) in 2005; * Nottingham (UK) in 2006; * New York (USA) in 2007; * Nijmegen (The Netherlands) in 2008; * Komarno (Slovakia) in 2009; * Oklahoma (USA) in 2010; * Madrid (Spain) in 2011; * St. Andrews (UK) in 2012; * Provo (Utah, USA) in 2013; * and in Soesterberg (The Netherlands) in 2014. For further general information about TFP please see the TFP homepage. (http://www.tifp.org/). == INVITED SPEAKERS == TFP is pleased to announce talks by the following two invited speakers: * Laurence Rideau is a researcher at INRIA and is interested in the semantics of programming languages , the formal methods, and the verification tools for programs and mathematical proofs. She participated in the beginnings of the Compcert project (certified compiler), and is part of the Component Mathematical team in the MSR-INRIA joint laboratory, who performed the formalization of the Feit-Thompson theorem successfully. Thirty years ago, computers barged in mathematics with the famous proof of the Four Color Theorem. Initially limited to simple calculation, their role is now expanding to the reasoning whose complexity is beyond the capabilities of most humans, as the proof of the classification of finite simple groups. We present our large collaborative adventure around the formalization of the Feit-Thompson theorem (http://en.wikipedia.org/wiki/Feit%E2%80%93Thompson_theorem) that is a first step to the classification of finite groups and that uses a palette of methods and techniques that range from formal logic to software (and mathematics) engineering. * Anil Madhavapeddy == SCOPE == The symposium recognizes that new trends may arise through various routes. As part of the Symposium's focus on trends we therefore identify the following five article categories. High-quality articles are solicited in any of these categories: Research Articles: leading-edge, previously unpublished research work Position Articles: on what new trends should or should not be Project Articles: descriptions of recently started new projects Evaluation Articles: what lessons can be drawn from a finished project Overview Articles: summarizing work with respect to a trendy subject Articles must be original and not simultaneously submitted for publication to any other forum. They may consider any aspect of functional programming: theoretical, implementation-oriented, or experience-oriented. Applications of functional programming techniques to other languages are also within the scope of the symposium. Topics suitable for the symposium include: Functional programming and multicore/manycore computing Functional programming in the cloud High performance functional computing Extra-functional (behavioural) properties of functional programs Dependently typed functional programming Validation and verification of functional programs Debugging and profiling for functional languages Functional programming in different application areas: security, mobility, telecommunications applications, embedded systems, global computing, grids, etc. Interoperability with imperative programming languages Novel memory management techniques Program analysis and transformation techniques Empirical performance studies Abstract/virtual machines and compilers for functional languages (Embedded) domain specific languages New implementation strategies Any new emerging trend in the functional programming area If you are in doubt on whether your article is within the scope of TFP, please contact the TFP 2015 program chair, Manuel Serrano. == BEST PAPER AWARDS == To reward excellent contributions, TFP awards a prize for the best paper accepted for the formal proceedings. TFP traditionally pays special attention to research students, acknowledging that students are almost by definition part of new subject trends. A student paper is one for which the authors state that the paper is mainly the work of students, the students are listed as first authors, and a student would present the paper. A prize for the best student paper is awarded each year. In both cases, it is the PC of TFP that awards the prize. In case the best paper happens to be a student paper, that paper will then receive both prizes. == SPONSORS == TFP is financially supported by Erlang Solutions. == PROGRAM == Please find the program at: http://tfp2015.inria.fr/program/ The program features two invited talks by Laurence Rideau and Anil Madhavapeddy and one comprehensive Dart tutorial by Florian Loitsch. == IMPORTANT DATES == Registration: May 4, 2015 TFP Symposium: June 3-5, 2015 == PROGRAM COMMITTEE == Janis Voigtl?nder University of Bonn, DE Scott Owens University of Kent, UK Neil Sculthorpe Swansea University, UK Colin Runciman University of York, UK Manuel Serrano Inria (PC chair), FR Rinus Plasmeijer University of Nijmegen, NL Tomas Petricek University of Cambridge, UK Marco T. Morazan Seton Hall University, USA Wolfgang De Meuter Vrije Universiteit Brussel, BE Michel Mauny Ensta ParisTech, FR Sam Lindley The University of Edinburgh, UK Daan Leijen Microsoft, USA Jurriaan Hage Utrecht University, NL Andy Gill University of Kansas, USA Thomas Gazagnaire University of Cambrige, UK Lars-Ake Fredlund Universidad Polit?cnica de Madrid, ES Jean-Christophe Filliatre Universit? Paris Sud Orsay, FR Marc Feeley Universit? de Montr?al, CA Olaf Chitil University of Kent, UK Edwin Brady University of St Andrews, UK From ky3 at atamo.com Fri May 1 13:02:47 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 1 May 2015 20:02:47 +0700 Subject: [Haskell-cafe] Haskell Weekly News In-Reply-To: References: Message-ID: > Another Lennart, last name Spitzner, creates another genie that turns type > signatures into programs. Unlike Djinn, Exference > > makes no promises over termination. "Your wish is my command even at the > expense of closure." > > Like Agda? You can now enjoy the hole-driven development style in Haskell, > brought to you courtesy of Mote by Izaak Meckler > . Discussion here > > . > Relevant addendum: - Ever use 'undefined' when writing definition stubs? Ever wished you had a type-level 'undefined' too? Thomas Winant explains advanced stubbing using GHC 7.10's new PartialTypeSignatures extension. Three years later, Dan Burton's wish is granted. Thanks to Dominique Devriese for prompting inclusion. And speaking of granting wishes, stub-driven development in your favorite editor jetpacked with type-to-term genies is tantalizingly within grasp. Visual Studio , eat your heart out. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From s9gf4ult at gmail.com Fri May 1 19:32:50 2015 From: s9gf4ult at gmail.com (Alexey Uimanov) Date: Sat, 2 May 2015 00:32:50 +0500 Subject: [Haskell-cafe] Swapping type arguments Message-ID: This question probably asked already. I have a type data T m b a = T (m (b, a)) and it should be instance of `Bifunctor` and `MonadTrans` same time. But there is a problem: instance Bifunctor (T m) is ok, but instance MonadTrans (T ... is not, because first argument is `m` but we need `b`. Type can be rewritten like data T b m a = T (m (b, a)) and instance of MonadTrans is ok: instance MonadTrans (T b) but how to define Bifunctor? instance Bifunctor (T ... I did not found how to workaround this. Is there any type magic for such cases? -------------- next part -------------- An HTML attachment was scrubbed... URL: From miguelimo38 at yandex.ru Fri May 1 19:36:23 2015 From: miguelimo38 at yandex.ru (MigMit) Date: Fri, 1 May 2015 21:36:23 +0200 Subject: [Haskell-cafe] Swapping type arguments In-Reply-To: References: Message-ID: <00CA04AA-5D9F-4848-9B07-C7FEEEF14AE5@yandex.ru> There is none. No type can be an instance of both classes, as their signatures are too different. You can create your own type class instead of MonadTrans (or Bifunctor), or you can wrap T in a newtype, swapping arguments. > On 01 May 2015, at 21:32, Alexey Uimanov wrote: > > This question probably asked already. > > I have a type > > data T m b a = T (m (b, a)) > > and it should be instance of `Bifunctor` and `MonadTrans` same time. But there is a problem: > > instance Bifunctor (T m) > > is ok, but > > instance MonadTrans (T ... > > is not, because first argument is `m` but we need `b`. Type can be rewritten like > > data T b m a = T (m (b, a)) > > and instance of MonadTrans is ok: > > instance MonadTrans (T b) > > but how to define Bifunctor? > > instance Bifunctor (T ... > > I did not found how to workaround this. Is there any type magic for such cases? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From alexander.vershilov at gmail.com Fri May 1 20:23:13 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Fri, 1 May 2015 23:23:13 +0300 Subject: [Haskell-cafe] Swapping type arguments In-Reply-To: References: Message-ID: Hello, Alexey. As far as I know this is not directly possible, at least in 7.8. However you could workaround it with a newtypes. (I've changed a bit definition of T, because otherwise there is no way to write MonadTrans instance (it seems)): import Data.Bifunctor import Control.Monad.Trans data T b m a = T (m (Either b a)) instance MonadTrans (T b) where lift g = T (return . Right =<< g) newtype TF m b a = TF { unTF :: T b m a} instance Functor m => Bifunctor (TF m) where bimap f g (TF (T z)) = TF (T (fmap (bimap f g) z)) In order to easily use bimap and friends you can introduce some helpers functions like: withTF :: (TF m b a -> TF m b c) -> T b m a -> T b m c withTF f = unTF . f . TF or look at more heavyweight solutions. -- Best regards, Vershilov Alexander On 1 May 2015 at 22:32, Alexey Uimanov wrote: > This question probably asked already. > > I have a type > > data T m b a = T (m (b, a)) > > and it should be instance of `Bifunctor` and `MonadTrans` same time. But > there is a problem: > > instance Bifunctor (T m) > > is ok, but > > instance MonadTrans (T ... > > is not, because first argument is `m` but we need `b`. Type can be rewritten > like > > data T b m a = T (m (b, a)) > > and instance of MonadTrans is ok: > > instance MonadTrans (T b) > > but how to define Bifunctor? > > instance Bifunctor (T ... > > I did not found how to workaround this. Is there any type magic for such > cases? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alexander From amindfv at gmail.com Sat May 2 00:10:06 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 1 May 2015 20:10:06 -0400 Subject: [Haskell-cafe] Import hiding module Message-ID: <8B462C7E-1530-4735-A4B2-F934525CCF16@gmail.com> It's possible to write e.g. module A (module A.B, x) where To reexport everything from A.B And we can import A hiding (x) Is there a way to also import A hiding (module A.B) ? Thanks From rasen.dubi at gmail.com Sat May 2 00:39:03 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Sat, 02 May 2015 00:39:03 +0000 Subject: [Haskell-cafe] Import hiding module In-Reply-To: <8B462C7E-1530-4735-A4B2-F934525CCF16@gmail.com> References: <8B462C7E-1530-4735-A4B2-F934525CCF16@gmail.com> Message-ID: Hi, To be short, no, I believe there is no way. When module A.B is re-exported, in reality it's not module re-exported but rather all symbols in current scope that were imported from A.B are exported. Furthermore, there is no way to know whether module is defined in a given module or just re-exported; and no way to know module it was re-exported from. This is kind of abstraction that gives some freedom to alter library internals without altering external interface. Best regards, Alexey Shmalko On Sat, May 2, 2015 at 3:10 AM wrote: > It's possible to write e.g. > > module A (module A.B, x) where > > To reexport everything from A.B > > And we can > > import A hiding (x) > > Is there a way to also > > import A hiding (module A.B) > > ? > > Thanks > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From amindfv at gmail.com Sat May 2 04:07:22 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Sat, 2 May 2015 00:07:22 -0400 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <5541F93A.3050309@informatik.uni-tuebingen.de> References: <1429181874.25663.80.camel@dunky.localdomain> <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> Message-ID: <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> I think the idea is that pckage signing is not a requirement, but that git is a requirement for package signing. So users can still get the behavior that they get today, without git. Tom El Apr 30, 2015, a las 5:43, Tillmann Rendel escribi?: > Hi, > > Mathieu Boespflug wrote: >> This is a valid concern. One that I should have addressed explicitly >> in the proposal. Git is fairly well supported on Windows these days >> and installs easily. It could conceivably be included as part of >> MinGHC. There are many alternatives, but I doubt we'll need them: >> statically linking a C implementation (libgit2 or another), or a >> simple native implementation of the git protocol (the protocol is >> quite straightforward and is documented) and basic disk format. > > I did not read your proposal, but if it entails that new Haskell users on Windows need to manually install git before they can use `cabal install something` for the first time, I think that would be bad. > > For programming beginners (think B.Sc. students in a field other than computer science that take an "intro to programming" class), every installation that requires manual configuration is a hassle. Making the cabal executable find the git executable on the path would potentially require manual configuration to set up the search path. I believe that both ghc and git binary packages for Windows package MSYS (or maybe something similar, not sure), so there is also some potential for a cabal+ghc+git installation to confuse which bundled copy of MSYS to use. > > Some of these "intro to programming" classes consist mostly of object-oriented programming, with a bit of FP thrown in. If helping the students to set up a Haskell environment on their laptops takes one lab session or one week of office hours, that's a significant cut from the FP learning time. If students fail their homework because they fail to install the Haskell environment, that takes a significant cut of their FP learning motivation. If instructors only teach plain Haskell without ever using cabal, this gives the impression that Haskell only works for classroom problems, because there seem to be no libraries. > > I'm aware that programming beginners are not the main target for a programming language infrastructure, but we shouldn't forget about their first-use experience completely, either. > > > I'm not even sure whether "statically linking a C implementation" is any better. How would it support `cabal install cabal-install` on Windows, in practice? > > Tillmann > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From adam at bergmark.nl Sat May 2 08:31:16 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Sat, 2 May 2015 10:31:16 +0200 Subject: [Haskell-cafe] PSA: How to use the cabal-version field in cabal files Message-ID: The cabal-version field seems pretty mysterious. Recommendation: Set it no higher than >= 1.10, Cabal will warn you if it's too low. This field contains the format of the cabal file, the number corresponds to the Cabal release. Hence this version is incremented more often than the format actually changes. There have been no significant changes between 1.10 and 1.20. The Cabal source is surprisingly helpful as a changelog: https://github.com/haskell/cabal/blob/641e854ae663e2b34f34ecc11ba663ac3a9bdc19/Cabal/Distribution/PackageDescription/Check.hs#L911-L1091 By setting it too high you risk users getting errors like "The package 'foo' requires Cabal library version -any && >=1.14 but no suitable version is installed." This can be problematic for anyone using an older GHC or if there are Cabal releases outside of the GHC release cycle. You may get this error even if you have a newer Cabal if it doesn't ship with GHC. Happy hacking, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Sat May 2 08:40:47 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Sat, 2 May 2015 10:40:47 +0200 Subject: [Haskell-cafe] Is it acceptable if Applicative behave not like a Monad In-Reply-To: <20150501120011.GA4036@city.ac.uk> References: <20150501120011.GA4036@city.ac.uk> Message-ID: My message was written too hastily, sorry about that. The example Alexey asked is exactly what the ApplicativeDo proposal[1] uses as motivation. The point of it is that you shouldn't need to care about writing applicative or do-style, when the behavior differs the most efficient one can be used. Though as it stands the proposal seems to run into the problem of being unintuitive like others mentioned since you need to enable an extension. A type implementing this functionality would need to be documented as "Enable ApplicativeDo when using this, or be very confused" [1] https://ghc.haskell.org/trac/ghc/wiki/ApplicativeDo - Adam On Fri, May 1, 2015 at 2:00 PM, Ross Paterson wrote: > On Thu, Apr 30, 2015 at 10:11:49PM -0700, Andrew Gibiansky wrote: > > I agree that, now that we have AMP, applicative and monadic interfaces > > absolutely *should* match, and that it should be considered an error for > them > > not to; semantically different interfaces can be provided with newtypes. > > This requirement is in the documentation for both Applicative and Monad > classes. (It's been in Applicative since 2010, and was added to Monad > in the AMP release.) > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From rendel at informatik.uni-tuebingen.de Sat May 2 10:43:52 2015 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Sat, 02 May 2015 12:43:52 +0200 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> Message-ID: <5544AA68.1000309@informatik.uni-tuebingen.de> Hi, [I decided to drop haskell-infrastructure at community.galois.com from the CC list because for my last message in this thread, I got some noise about moderation]. amindfv at gmail.com wrote: > I think the idea is that package signing is not a requirement, but > that git is a requirement for package signing. So users can still get > the behavior that they get today, without git. So there would be `cabal update --unsigned` and `cabal update --signed` and the former doesn't need git? I skimmed the the proposal at https://github.com/commercialhaskell/commercialhaskell/wiki/Git-backed-Hackage-index-signing-and-distribution and did not find this information there. Instead, I found this snippet: > Especially in developing countries, it would be a real liability for > Haskell if the first step before doing anything is having to download > a 1GB Git archive. Especially considering that given the current > growth curve, the Git repository with all content imported will > likely be hitting 2GB by this time next year, and so on. This sounds as if for all Haskell users, "the first step before doing anything" would have to be to use git. Tillmann PS. BTW, check out this stack overflow question to understand why installing and configuring git will be hard for some Haskell users on Windows: http://stackoverflow.com/questions/30000688/windows-loading-haskell-source-code-into-ghci From j.strecha at gmail.com Sat May 2 12:55:57 2015 From: j.strecha at gmail.com (Johannes Strecha) Date: Sat, 2 May 2015 14:55:57 +0200 Subject: [Haskell-cafe] Parsing YAML with varying structure Message-ID: Dear Cafe, I need help parsing YAML files with varying structure. The minimal example is: a yaml file that has one key, which can hold either one key-value pair or two key value pairs. I have data types for the one key, and the two possible sub-keys: >data Var = Var { > v' :: Either MyList Item > } deriving Show > >data MyList = MyList { > a' :: Int, > b' :: Int > } deriving Show > >data Item = Item { > content' :: String > } deriving Show To read MyList and Item from the file I wrote FromJSON instances >instance FromJSON MyList where > parseJSON (Object m) = MyList <$> m .: (pack "a") <*> m .: (pack "b") > parseJSON x = fail ("not an object: " ++ show x) > >instance FromJSON Item where > parseJSON (Object m) = Item <$> m .: (pack "c") > parseJSON x = fail ("not an object: " ++ show x) I also have read functions for MyList and Item: >readItem :: IO Item >readItem = either (error.show) id <$> decodeFileEither "test.yaml" > >readMyList :: IO MyList >readMyList = either (error.show) id <$> decodeFileEither "test.yaml" The file test.yaml looks like >v: > a: 4 > b: 5 or, alternatively >v: > c: "test" The question is how I can decode test.yaml to get Var. Trying to code readVar like readItem (having FromJSON Var like FromJSON Item) failed. For convenience I attached the relevant source files. Regards, Johannes. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: test.tar.gz Type: application/x-gzip Size: 491 bytes Desc: not available URL: From aditya.siram at gmail.com Sat May 2 15:24:26 2015 From: aditya.siram at gmail.com (aditya siram) Date: Sat, 2 May 2015 10:24:26 -0500 Subject: [Haskell-cafe] Start GHCI with a static library Message-ID: Hi all, I have a Haskell library I'd like to load up in GHCI along with a statically linked C library (libblah.a) . Is there any way to do this? My Googling only turns up instructions on loading a shared library (libblah.so). Thanks! -deech -------------- next part -------------- An HTML attachment was scrubbed... URL: From s9gf4ult at gmail.com Sat May 2 20:32:08 2015 From: s9gf4ult at gmail.com (Alexey Uimanov) Date: Sun, 3 May 2015 01:32:08 +0500 Subject: [Haskell-cafe] ANN: applicative-fail-1.0.0 Message-ID: Hi guys, here is reworked applicative-fail http://hackage.haskell.org/package/applicative-fail-1.0.0 You can use it to e.g. parse requests in your web application, or in any other parse-like stuff. -------------- next part -------------- An HTML attachment was scrubbed... URL: From psyzy3 at nottingham.ac.uk Sat May 2 20:48:13 2015 From: psyzy3 at nottingham.ac.uk (Zongzhe Yuan) Date: Sat, 2 May 2015 20:48:13 +0000 Subject: [Haskell-cafe] Meet some problem when installing Agda Message-ID: Hi I want to use Agda on my computer and I follow the instruction http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.MacOSX However when I was using cabal install Agda to install agda, the terminal said The program cpphs version >=1.18.6 && <1.19 is required but the version found at /Users/XXXXXX/Library/Haskell/bin/cpphs is version 1.19 Do you have some idea how could i fix that problem? Zongzhe Yuan This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat May 2 22:16:25 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sun, 03 May 2015 00:16:25 +0200 Subject: [Haskell-cafe] Meet some problem when installing Agda In-Reply-To: References: Message-ID: On Sat, 02 May 2015 22:48:13 +0200, Zongzhe Yuan wrote: > Hi > > I want to use Agda on my computer and I follow the instruction > http://wiki.portal.chalmers.se/agda/pmwiki.php?n=Main.MacOSX > However when I was using cabal install Agda to install agda, the > terminal said > The program cpphs version >=1.18.6 && <1.19 is required but the version > found at /Users/XXXXXX/Library/Haskell/bin/cpphs is version 1.19 > Do you have some idea how could i fix that problem? Run: cabal install cpphs-1.18.9 and install the cpphs executable somewhere in the search path before the one you have now. Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From michael at snoyman.com Sun May 3 05:30:05 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 03 May 2015 05:30:05 +0000 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <5544AA68.1000309@informatik.uni-tuebingen.de> References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: There's actually a really easy solution to "have Git installed": bundle it with MinGHC. Another alternative would be to use one of the many libraries out there that can talk the Git wire protocols. In fact, if anyone is worried about the standard Git tool not being secure enough (either due to C code or some other reason), we could have a Haskell-based Git implementation that focuses on security. There would still be big advantages to using the Git protocol in that case, such as a well understood protocol to work against and easy interop with existing tools. That said, I think bundling the necessary Git tooling with MinGHC is an easy win. On Sat, May 2, 2015 at 1:44 PM Tillmann Rendel < rendel at informatik.uni-tuebingen.de> wrote: > Hi, > > [I decided to drop haskell-infrastructure at community.galois.com from the > CC list because for my last message in this thread, I got some noise > about moderation]. > > amindfv at gmail.com wrote: > > I think the idea is that package signing is not a requirement, but > > that git is a requirement for package signing. So users can still get > > the behavior that they get today, without git. > > So there would be `cabal update --unsigned` and `cabal update --signed` > and the former doesn't need git? > > I skimmed the the proposal at > > > https://github.com/commercialhaskell/commercialhaskell/wiki/Git-backed-Hackage-index-signing-and-distribution > > and did not find this information there. Instead, I found this snippet: > > > Especially in developing countries, it would be a real liability for > > Haskell if the first step before doing anything is having to download > > a 1GB Git archive. Especially considering that given the current > > growth curve, the Git repository with all content imported will > > likely be hitting 2GB by this time next year, and so on. > > This sounds as if for all Haskell users, "the first step before doing > anything" would have to be to use git. > > Tillmann > > PS. BTW, check out this stack overflow question to understand why > installing and configuring git will be hard for some Haskell users on > Windows: > > > http://stackoverflow.com/questions/30000688/windows-loading-haskell-source-code-into-ghci > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Sun May 3 07:26:21 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sun, 03 May 2015 07:26:21 +0000 Subject: [Haskell-cafe] Parsing YAML with varying structure In-Reply-To: References: Message-ID: I think the answer to your question revolves around the Alternative instance for Parser. Does the following code help? Var <$> ((Left <$> parseJSON) <|> (Right <$> parseJSON)) What this is saying is "try to parse a MyList, and then wrap it with a Left. If that fails, try to parse an Item and wrap it with a Right. Whatever the result is from there, wrap it in a Var." On Sat, May 2, 2015 at 3:56 PM Johannes Strecha wrote: > Dear Cafe, > > I need help parsing YAML files with varying structure. The minimal example > is: a yaml file that has one key, which can hold either one key-value pair > or two key value pairs. I have data types for the one key, and the two > possible sub-keys: > > >data Var = Var { > > v' :: Either MyList Item > > } deriving Show > > > >data MyList = MyList { > > a' :: Int, > > b' :: Int > > } deriving Show > > > >data Item = Item { > > content' :: String > > } deriving Show > > To read MyList and Item from the file I wrote FromJSON instances > > >instance FromJSON MyList where > > parseJSON (Object m) = MyList <$> m .: (pack "a") <*> m .: (pack "b") > > parseJSON x = fail ("not an object: " ++ show x) > > > >instance FromJSON Item where > > parseJSON (Object m) = Item <$> m .: (pack "c") > > parseJSON x = fail ("not an object: " ++ show x) > > I also have read functions for MyList and Item: > > >readItem :: IO Item > >readItem = either (error.show) id <$> decodeFileEither "test.yaml" > > > >readMyList :: IO MyList > >readMyList = either (error.show) id <$> decodeFileEither "test.yaml" > > The file test.yaml looks like > > >v: > > a: 4 > > b: 5 > > or, alternatively > > >v: > > c: "test" > > The question is how I can decode test.yaml to get Var. Trying to code > readVar like readItem (having FromJSON Var like FromJSON Item) failed. For > convenience I attached the relevant source files. > > Regards, > Johannes. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tab at snarc.org Sun May 3 07:40:41 2015 From: tab at snarc.org (Vincent Hanquez) Date: Sun, 03 May 2015 08:40:41 +0100 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <1430377680233-5808179.post@n5.nabble.com> References: <87bninfdkp.fsf@karetnikov.org> <1430377680233-5808179.post@n5.nabble.com> Message-ID: <5545D0F9.4000302@snarc.org> On 30/04/2015 08:08, Jeremy wrote: > Mathieu Boespflug-4 wrote >> We're not introducing dependencies on dynamically linked system libraries >> that makes tooling hard to distribute. We're not asking users to install >> anything new that isn't already a staple of most developer desktops > My sole concern with this is that git is often not present on build servers, > which may be minimal cloud VMs. Here's what I get when I try to install git > on mine: > > # apt install git --no-install-recommends > ... > The following NEW packages will be installed: > git git-man libcurl3-gnutls liberror-perl libexpat1 libgdbm3 perl > perl-modules > 0 upgraded, 8 newly installed, 0 to remove and 2 not upgraded. > Need to get 10.4 MB of archives. > After this operation, 57.2 MB of additional disk space will be used. > > I'm no fan of unnecessary bloat, but considering that typical Debian installation of ghc is +500MB (7.4) to +800M (7.10) (severely bloated by multiple almost copies of the same file), I'm not sure how relevant this is on a haskell build server. Plus, many people already uses git on build servers making a zero cost for most of us. -- Vincent From voldermort at hotmail.com Sun May 3 08:16:03 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 3 May 2015 01:16:03 -0700 (MST) Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <5545D0F9.4000302@snarc.org> References: <87bninfdkp.fsf@karetnikov.org> <1430377680233-5808179.post@n5.nabble.com> <5545D0F9.4000302@snarc.org> Message-ID: <1430640963404-5808335.post@n5.nabble.com> Vincent Hanquez wrote > On 30/04/2015 08:08, Jeremy wrote: >> My sole concern with this is that git is often not present on build >> servers, >> which may be minimal cloud VMs. Here's what I get when I try to install >> git >> on mine: >> >> # apt install git --no-install-recommends >> ... >> The following NEW packages will be installed: >> git git-man libcurl3-gnutls liberror-perl libexpat1 libgdbm3 perl >> perl-modules >> 0 upgraded, 8 newly installed, 0 to remove and 2 not upgraded. >> Need to get 10.4 MB of archives. >> After this operation, 57.2 MB of additional disk space will be used. >> >> > I'm no fan of unnecessary bloat, but considering that typical Debian > installation > of ghc is +500MB (7.4) to +800M (7.10) (severely bloated by multiple > almost copies > of the same file), I'm not sure how relevant this is on a haskell build > server. My entire server is under 150Mb (docker image). I build GHC myself without the bloat. -- View this message in context: http://haskell.1045720.n5.nabble.com/Improvements-to-package-hosting-and-security-tp5768710p5808335.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From voldermort at hotmail.com Sun May 3 08:20:21 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 3 May 2015 01:20:21 -0700 (MST) Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <1430640963404-5808335.post@n5.nabble.com> References: <1430377680233-5808179.post@n5.nabble.com> <5545D0F9.4000302@snarc.org> <1430640963404-5808335.post@n5.nabble.com> Message-ID: <1430641221407-5808336.post@n5.nabble.com> Ignore that, cosmic rays flipped some bits in my memory, server footprint is 418Mb (including cabal-install). -- View this message in context: http://haskell.1045720.n5.nabble.com/Improvements-to-package-hosting-and-security-tp5768710p5808336.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From roma at ro-che.info Sun May 3 09:04:59 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 03 May 2015 12:04:59 +0300 Subject: [Haskell-cafe] ANN: applicative-fail-1.0.0 In-Reply-To: References: Message-ID: <5545E4BB.5070305@ro-che.info> On 02/05/15 23:32, Alexey Uimanov wrote: > Hi guys, here is reworked applicative-fail > > http://hackage.haskell.org/package/applicative-fail-1.0.0 > > You can use it to e.g. parse requests in your web application, or in any > other parse-like stuff. Incidentally, I just published an article on this very subject: https://ro-che.info/articles/2015-05-02-smarter-validation -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mboes at tweag.net Sun May 3 09:14:49 2015 From: mboes at tweag.net (Mathieu Boespflug) Date: Sun, 3 May 2015 11:14:49 +0200 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <5544AA68.1000309@informatik.uni-tuebingen.de> References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: Hi Tilman, we should certainly have all Haskell users in mind in this discussion, including beginners, and of course including Windows users. At the end of the day, MinGHC is the recommended way to get Haskell on Windows. It is what haskell.org points to. It includes msys, which is also the main prereq for git on windows. Adding git would grow the archive size by about 5MB (adding Perl not required) to an archive that is 125MB in size. So I don't see Git being a problem on Windows. The more general point here is whether leveraging (arguably standard) third-party commands and/or C code in order to keep our maintainance burden low, and pick up many robust features for free to boot, is a good approach. I believe that it is. Our infrastructure and tooling is cracking at the seams as it is (cabal-install mysteriously dropping HTTP connections and corrupting .cabal files when behind a corporate firewall, updates to hackage-server inadvertently reversing the order of revisions, low availability of Hackage, ...). Leveraging Git would solve all mentioned problems, plus give us incremental updates for free, plus give us package index signing for little effort. To me that sounds like a pretty big win for 99% of users (including Windows + OS X), at a *lower* extra maintenance cost for the community today since we would need to maintain less code. The added reliability and availability should ultimately benefit beginner users, who can find it pretty confounding when following instructions just don't work, because temp glitch, when they've never seen it work before. Now, we are hearing of use cases where an extra 57MB (including perl, which should actually be optional) unpacked is a liability for minimalistic server images. I fully expect other niche use cases that would prefer a different technical solution. But if we use a de facto standard format for histories and for distributing signatures, then we can support multiple ways of accessing and manipulating it, including via a custom haskell (or existing C) git downloader if users of the niche use cases deem the cost worth it. Also, one can envision specialized mirrors where appropriate for certain niche use cases. Why should the "canonical" (or upstream) source for the package index be served via Git then? Because I believe it makes the common case code path on Hackage simpler, and the end user tools people use in the common case simpler, including for advanced features like index signing, which we get nearly for free once we switch to Git. Keep the common case simple, make niche cases possible without complicating the common case. That's what the Julia and the Ocaml folks have been betting on, and for having tried out their tools just recently, they've ended up with tooling that's arguably quite a bit more user friendly than we have. On 2 May 2015 at 12:43, Tillmann Rendel wrote: > Hi, > > [I decided to drop haskell-infrastructure at community.galois.com from the CC > list because for my last message in this thread, I got some noise about > moderation]. > > amindfv at gmail.com wrote: >> >> I think the idea is that package signing is not a requirement, but >> that git is a requirement for package signing. So users can still get >> the behavior that they get today, without git. > > > So there would be `cabal update --unsigned` and `cabal update --signed` > and the former doesn't need git? > > I skimmed the the proposal at > > https://github.com/commercialhaskell/commercialhaskell/wiki/Git-backed-Hackage-index-signing-and-distribution > > and did not find this information there. Instead, I found this snippet: > >> Especially in developing countries, it would be a real liability for >> Haskell if the first step before doing anything is having to download >> a 1GB Git archive. Especially considering that given the current >> growth curve, the Git repository with all content imported will >> likely be hitting 2GB by this time next year, and so on. > > > This sounds as if for all Haskell users, "the first step before doing > anything" would have to be to use git. > > Tillmann > > PS. BTW, check out this stack overflow question to understand why installing > and configuring git will be hard for some Haskell users on Windows: > > http://stackoverflow.com/questions/30000688/windows-loading-haskell-source-code-into-ghci From voldermort at hotmail.com Sun May 3 11:06:49 2015 From: voldermort at hotmail.com (Jeremy) Date: Sun, 3 May 2015 04:06:49 -0700 (MST) Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: <1430651209640-5808342.post@n5.nabble.com> Mathieu Boespflug-2 wrote > Now, we are hearing of use cases where an extra 57MB (including perl, > which should actually be optional) unpacked is a liability for > minimalistic server images. Debian's git packaging requires perl. Maybe https://hackage.haskell.org/package/gitlib would be a suitable alternative to the full package? -- View this message in context: http://haskell.1045720.n5.nabble.com/Improvements-to-package-hosting-and-security-tp5768710p5808342.html Sent from the Haskell - Haskell-Cafe mailing list archive at Nabble.com. From blake.rain at gmail.com Sun May 3 11:09:13 2015 From: blake.rain at gmail.com (Blake Rain) Date: Sun, 3 May 2015 12:09:13 +0100 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: Message-ID: Hi All, I have only just found the time to read through this discussion. I thought perhaps I would offer a few thoughts. It seems that we are all in agreement that the security of Hackage/Cabal is a problem: insecure transmission and no way to verify package authorship. This is something which I feel we must address: Where I work we have a lot of compliance to consider, and a few products require us to provide vary degrees of assurance about the code we link against. This usually leads to the decision to use a third party piece of kit. Going forward, we will need to replace these systems with our own solutions. I would prefer to use Haskell, but swapping out Hackage/Cabal due to security concerns is undesirable from my point of view and the lack of package security will be a show-stopper for senior management. Using git and S3 as Michael suggests seems a good solution to me. To my mind, the increased transparency, ability to create mirrors of S3 and git to access the package metadata offers a number of desirable features. Regarding the use of git: I don't think that we need to implement our own solution, and depending on git is not an issue: Most of our CI uses git anyway. A final point I feel I must raise is that it seems that FP Complete are going to be footing the bill for the S3 hosting. Long term, this seems unfair to FP Complete. Is this something that the haskell.org could take on? Or at the very least some other mechanism to either pay for or offer compensation long term? Kinds Regards, - B. On 13 April 2015 at 11:02, Michael Snoyman wrote: > Many of you saw the blog post Mathieu wrote[1] about having more > composable community infrastructure, which in particular focused on > improvements to Hackage. I've been discussing some of these ideas with both > Mathieu and others in the community working on some similar thoughts. I've > also separately spent some time speaking with Chris about package > signing[2]. Through those discussions, it's become apparent to me that > there are in fact two core pieces of functionality we're relying on Hackage > for today: > > * A centralized location for accessing package metadata (i.e., the cabal > files) and the package contents themselves (i.e., the sdist tarballs) > * A central authority for deciding who is allowed to make releases of > packages, and make revisions to cabal files > > In my opinion, fixing the first problem is in fact very straightforward to > do today using existing tools. FP Complete already hosts a full Hackage > mirror[3] backed by S3, for instance, and having the metadata mirrored to a > Git repository as well is not a difficult technical challenge. This is the > core of what Mathieu was proposing as far as composable infrastructure, > corresponding to next actions 1 and 3 at the end of his blog post (step 2, > modifying Hackage, is not a prerequesite). In my opinion, such a system > would far surpass in usability, reliability, and extensibility our current > infrastructure, and could be rolled out in a few days at most. > > However, that second point- the central authority- is the more interesting > one. As it stands, our entire package ecosystem is placing a huge level of > trust in Hackage, without any serious way to vet what's going on there. > Attack vectors abound, e.g.: > > * Man in the middle attacks: as we are all painfully aware, cabal-install > does not support HTTPS, so a MITM attack on downloads from Hackage is > trivial > * A breach of the Hackage Server codebase would allow anyone to upload > nefarious code[4] > * Any kind of system level vulnerability could allow an attacker to > compromise the server in the same way > > Chris's package signing work addresses most of these vulnerabilities, by > adding a layer of cryptographic signatures on top of Hackage as the central > authority. I'd like to propose taking this a step further: removing Hackage > as the central authority, and instead relying entirely on cryptographic > signatures to release new packages. > > I wrote up a strawman proposal last week[5] which clearly needs work to be > a realistic option. My question is: are people interested in moving forward > on this? If there's no interest, and everyone is satisfied with continuing > with the current Hackage-central-authority, then we can proceed with having > reliable and secure services built around Hackage. But if others- like me- > would like to see a more secure system built from the ground up, please say > so and let's continue that conversation. > > [1] > https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure > > [2] > https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal > > [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror > [4] I don't think this is just a theoretical possibility for some point in > the future. I have reported an easily trigerrable DoS attack on the current > Hackage Server codebase, which has been unresolved for 1.5 months now > [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9 > > -- > You received this message because you are subscribed to the Google Groups > "Commercial Haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to commercialhaskell+unsubscribe at googlegroups.com. > To post to this group, send email to commercialhaskell at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com > > . > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From bertram.felgenhauer at googlemail.com Sun May 3 14:27:54 2015 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun, 3 May 2015 16:27:54 +0200 Subject: [Haskell-cafe] ANN: Important lambabot update (5.0.2.1 release) Message-ID: <20150503142754.GB1771@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Hi, I've just released lambdabot-5.0.2.1 which plugs an embarrassing security hole in the @check command; if you are running lambdabot as an IRC bot, you should upgrade! Generally, lambdabot relies on SafeHaskell and not running user-supplied IO actions for safety. This is unlikely to be bullet-proof, so it's advisable to sandbox mueval. However, the @check command violated this basic principle, and allowed running arbitrary IO actions. This is now fixed by using the (new) QuickCheck-safe package that only uses unsafePerformIO for the specific purposes of catching exceptions and generating the initial seed for random number generation. Thanks to benzfr on Freenode for finding this! There are a few minor changes. Notably, we now ship compiler-specific versions of Pristine.hs so that lambdabot runs out of the box on both ghc-7.6.3 and ghc-7.8.3 (ghc-7.10.1 still needs some work.) and the dict plugin no longer supports looking up several words at once. Cheers, Bertram P.S. As I just realized, I forgot to update the Changelog that comes with lambdabot... will try to remember next time. From bertram.felgenhauer at googlemail.com Sun May 3 14:40:29 2015 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sun, 3 May 2015 16:40:29 +0200 Subject: [Haskell-cafe] ANN: Important lambabot update (5.0.2.1 release) In-Reply-To: <20150503142754.GB1771@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <20150503142754.GB1771@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <20150503144029.GC1771@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Bertram Felgenhauer wrote: > P.S. As I just realized, I forgot to update the Changelog that comes > with lambdabot... will try to remember next time. lambdabot-5.0.2.2 comes with an updated Changelog. Cheers, Bertram From carter.schonwald at gmail.com Sun May 3 15:49:36 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Sun, 3 May 2015 11:49:36 -0400 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: Message-ID: storage for every package ever released on hackage in the history of haskell on s3 totals < 30 cents per month (probably closer to 10 cents). If their s3 host had super high usage, the most it'd cost per month bandwidth is 50-90 dollars (and likely overestimating by at least 10x). a small engineering team probably spends more than that on coffee per month. haskell.org hosting and infrastructure is largely donated by various organizations. If you can get AWS to top the rackspace+dreamhost infra sponsorship, Gershom and others would probably love to hear about it. On Sun, May 3, 2015 at 7:09 AM, Blake Rain wrote: > Hi All, > > I have only just found the time to read through this discussion. I thought > perhaps I would offer a few thoughts. > > It seems that we are all in agreement that the security of Hackage/Cabal > is a problem: insecure transmission and no way to verify package > authorship. This is something which I feel we must address: > > Where I work we have a lot of compliance to consider, and a few products > require us to provide vary degrees of assurance about the code we link > against. This usually leads to the decision to use a third party piece of > kit. Going forward, we will need to replace these systems with our own > solutions. I would prefer to use Haskell, but swapping out Hackage/Cabal > due to security concerns is undesirable from my point of view and the lack > of package security will be a show-stopper for senior management. > > Using git and S3 as Michael suggests seems a good solution to me. To my > mind, the increased transparency, ability to create mirrors of S3 and git > to access the package metadata offers a number of desirable features. > > Regarding the use of git: I don't think that we need to implement our own > solution, and depending on git is not an issue: Most of our CI uses git > anyway. > > A final point I feel I must raise is that it seems that FP Complete are > going to be footing the bill for the S3 hosting. Long term, this seems > unfair to FP Complete. Is this something that the haskell.org could take > on? Or at the very least some other mechanism to either pay for or offer > compensation long term? > > Kinds Regards, > > - B. > > On 13 April 2015 at 11:02, Michael Snoyman wrote: > >> Many of you saw the blog post Mathieu wrote[1] about having more >> composable community infrastructure, which in particular focused on >> improvements to Hackage. I've been discussing some of these ideas with both >> Mathieu and others in the community working on some similar thoughts. I've >> also separately spent some time speaking with Chris about package >> signing[2]. Through those discussions, it's become apparent to me that >> there are in fact two core pieces of functionality we're relying on Hackage >> for today: >> >> * A centralized location for accessing package metadata (i.e., the cabal >> files) and the package contents themselves (i.e., the sdist tarballs) >> * A central authority for deciding who is allowed to make releases of >> packages, and make revisions to cabal files >> >> In my opinion, fixing the first problem is in fact very straightforward >> to do today using existing tools. FP Complete already hosts a full Hackage >> mirror[3] backed by S3, for instance, and having the metadata mirrored to a >> Git repository as well is not a difficult technical challenge. This is the >> core of what Mathieu was proposing as far as composable infrastructure, >> corresponding to next actions 1 and 3 at the end of his blog post (step 2, >> modifying Hackage, is not a prerequesite). In my opinion, such a system >> would far surpass in usability, reliability, and extensibility our current >> infrastructure, and could be rolled out in a few days at most. >> >> However, that second point- the central authority- is the more >> interesting one. As it stands, our entire package ecosystem is placing a >> huge level of trust in Hackage, without any serious way to vet what's going >> on there. Attack vectors abound, e.g.: >> >> * Man in the middle attacks: as we are all painfully aware, cabal-install >> does not support HTTPS, so a MITM attack on downloads from Hackage is >> trivial >> * A breach of the Hackage Server codebase would allow anyone to upload >> nefarious code[4] >> * Any kind of system level vulnerability could allow an attacker to >> compromise the server in the same way >> >> Chris's package signing work addresses most of these vulnerabilities, by >> adding a layer of cryptographic signatures on top of Hackage as the central >> authority. I'd like to propose taking this a step further: removing Hackage >> as the central authority, and instead relying entirely on cryptographic >> signatures to release new packages. >> >> I wrote up a strawman proposal last week[5] which clearly needs work to >> be a realistic option. My question is: are people interested in moving >> forward on this? If there's no interest, and everyone is satisfied with >> continuing with the current Hackage-central-authority, then we can proceed >> with having reliable and secure services built around Hackage. But if >> others- like me- would like to see a more secure system built from the >> ground up, please say so and let's continue that conversation. >> >> [1] >> https://www.fpcomplete.com/blog/2015/03/composable-community-infrastructure >> >> [2] >> https://github.com/commercialhaskell/commercialhaskell/wiki/Package-signing-detailed-propsal >> >> [3] https://www.fpcomplete.com/blog/2015/03/hackage-mirror >> [4] I don't think this is just a theoretical possibility for some point >> in the future. I have reported an easily trigerrable DoS attack on the >> current Hackage Server codebase, which has been unresolved for 1.5 months >> now >> [5] https://gist.github.com/snoyberg/732aa47a5dd3864051b9 >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Commercial Haskell" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to commercialhaskell+unsubscribe at googlegroups.com. >> To post to this group, send email to commercialhaskell at googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/commercialhaskell/CAKA2JgL4MviHic52_S3P8RqxyJndkj3oFA%2BPVG11AAgMhMJksw%40mail.gmail.com >> >> . >> For more options, visit https://groups.google.com/d/optout. >> > > -- > You received this message because you are subscribed to the Google Groups > "Commercial Haskell" group. > To unsubscribe from this group and stop receiving emails from it, send an > email to commercialhaskell+unsubscribe at googlegroups.com. > To post to this group, send email to commercialhaskell at googlegroups.com. > To view this discussion on the web visit > https://groups.google.com/d/msgid/commercialhaskell/CANUq-hHWexCeL%2Bp%2BWSU7PNgpdpWo_j0uPJ47-ui7QRjdktZ9sg%40mail.gmail.com > > . > > For more options, visit https://groups.google.com/d/optout. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Mon May 4 01:12:25 2015 From: gershomb at gmail.com (Gershom B) Date: Sun, 3 May 2015 21:12:25 -0400 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: On May 3, 2015 at 5:14:58 AM, Mathieu Boespflug (mboes at tweag.net) wrote: > The more general point here is whether leveraging (arguably standard) > third-party commands and/or C code in order to keep our maintainance > burden low, and pick up many robust features for free to boot, is a > good approach. I believe that it is. Our infrastructure and tooling is > cracking at the seams as it is (cabal-install mysteriously dropping > HTTP connections and corrupting .cabal files when behind a corporate > firewall, updates to hackage-server inadvertently reversing the order > of revisions, low availability of Hackage, ...). Leveraging Git would > solve all mentioned problems, plus give us incremental updates for > free, plus give us package index signing for little effort. This seems to me to be mixing apples and oranges and pears and artichokes. The primary reason for hackage downtime in the past was instability of our hetzner box. Migrating to rackspace did wonders for us. Regardless, choice of hardware/webhost is orthogonal to git. You then list a logic bug in a version of hackage server. Logic bugs, as I?m sure you?re aware, can be introduced anywhere that code is written. No proposal put forward involves not writing and running code, so while we can work on better regression test suites, code-review procedures, etc., this has very little to do with adoption of git (especially as I understand the reverse in revision order was a bug on _display_ which this proposal doesn?t address at all). Finally, you discuss cabal-install having trouble behind firewalls. I agree with this being a problem, and I want us to work on this. However, git is again not a magic bullet. I?ve had firewalls where I run into trouble with git too, or with mercurial, or where certain website/firewall combinations meant, mysteriously that curl would work but not wget, or vice versa. I think the plans to expand the choice of transports for cabal-install will improve things in this regard, and could in fact lay the basis for adding git as an additional transport as well. In summary: You point to real problems that have occurred (of them, only the first [firewalls] is an ongoing issue). There are many other problems you did not point to, but that are also problems, and remain problems. Moving to git as a transport could potentially address some problems, with certain other tradeoffs in terms of other tooling choices we would have to make. However, I don?t think that migrating to git will solve any of the problems you mentioned above in your parenthetical. It _does_ help with the incremental fetch issue (though there are other ways to do that), and it _is_ a way to tackle the index signing issue, though I?m not sure that it is the best way (in particular, given the difficulty of configuring git _with keys_ on windows). Cheers, Gershom From mboes at tweag.net Mon May 4 08:42:05 2015 From: mboes at tweag.net (Mathieu Boespflug) Date: Mon, 4 May 2015 10:42:05 +0200 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: It takes apples, oranges, pears and artichokes and then some to stay healthy and keep the doctor away. That's why Git, in any capacity, isn't a silver bullet to solve all problems. However, let's break down how the envisioned setup helps with the problems I mentioned: - cabal-install mysteriously dropping HTTP connections and corrupting .cabal files: this particular firewall that I've seen is used by hundreds of developers in the company without it silently truncating requests on anything else but Cabal updates. Investigations so far point to a bad interaction between Network.HTTP and lazy bytestrings, see http://www.hawaga.org.uk/tmp/bug-cabal-zlib-http-lazy.html (no bug report just yet). Reusing the same download mechanism that hundreds of others are already using in the company means we are not at risk of a firewall triggering an obscure latent race condition in the way cabal-install retrieves HTTP responses. It means if there is a real problem with the firewall, it won't just be for the local Haskellian outpost who are trying to sell Haskell to their boss, but for everyone, and therefore fixed. - the reversing revisions issue was NOT just a display issue: it completely broke Stackage Nightly builds that day, which just calls `cabal update` under the hood: https://github.com/haskell/hackage-server/issues/305. Other users of Hackage in that time window also experienced the issue. It's an issue that caused massive breakage in a lot of places. Notice how PkgInfo_v2 is a data structure that is entirely redundant with what Git would provide already, so need not be serialized to disk, have migrations written for it, etc, nor perhaps exist at all. Further, Git would have made it quite impossible to distribute what amounts to a rewritten and inadvertently tampered with history (because the clients would have noticed and refused to fast forward). Fewer pieces of state managed independently + less code = more reliable service. - low availability of hackage: indeed, hosting issues have been a major culprit here. But the point is, with the package database maintained as a Git repo separate from hackage-server, the repo can be served from any (highly available) Git provider, such as Github or Bitbucket, and continue to be served to clients even if the Hackage front page is down for whatever reason. Hosting we don't have to manage ourselves is hosting we don't have to keep humming. Of course no service guarantees 100% uptime, so mirrors are a key additional (or alternative) ingredient here. Efficient, low-latency and reliable mirroring is certainly possible by other means, but mirroring a history of changes is exactly what Git was designed for, and what it does well. Why reinvent that? > However, I don?t think that migrating to git will solve any of the problems you mentioned above in your parenthetical. It _does_ help with the incremental fetch issue (though there are other ways to do that), and it _is_ a way to tackle the index signing issue, though I?m not sure that it is the best way (in particular, given the difficulty of configuring git _with keys_ on windows). That's an interesting concern, though without knowing more, this is not an actionable issue. What difficulties? If MinGHC packaged Git+gpg4win, what would the issue be? Best, Mathieu On 4 May 2015 at 03:12, Gershom B wrote: > On May 3, 2015 at 5:14:58 AM, Mathieu Boespflug (mboes at tweag.net) wrote: > >> The more general point here is whether leveraging (arguably standard) >> third-party commands and/or C code in order to keep our maintainance >> burden low, and pick up many robust features for free to boot, is a >> good approach. I believe that it is. Our infrastructure and tooling is >> cracking at the seams as it is (cabal-install mysteriously dropping >> HTTP connections and corrupting .cabal files when behind a corporate >> firewall, updates to hackage-server inadvertently reversing the order >> of revisions, low availability of Hackage, ...). Leveraging Git would >> solve all mentioned problems, plus give us incremental updates for >> free, plus give us package index signing for little effort. > > This seems to me to be mixing apples and oranges and pears and artichokes. The primary reason for hackage downtime in the past was instability of our hetzner box. Migrating to rackspace did wonders for us. Regardless, choice of hardware/webhost is orthogonal to git. You then list a logic bug in a version of hackage server. Logic bugs, as I?m sure you?re aware, can be introduced anywhere that code is written. No proposal put forward involves not writing and running code, so while we can work on better regression test suites, code-review procedures, etc., this has very little to do with adoption of git (especially as I understand the reverse in revision order was a bug on _display_ which this proposal doesn?t address at all). Finally, you discuss cabal-install having trouble behind firewalls. I agree with this being a problem, and I want us to work on this. However, git is again not a magic bullet. I?ve had firewalls where I run into trouble with git too, or with mercurial, or where certain website/firewall combinations meant, mysteriously that curl would work but not wget, or vice versa. I think the plans to expand the choice of transports for cabal-install will improve things in this regard, and could in fact lay the basis for adding git as an additional transport as well. > > In summary: You point to real problems that have occurred (of them, only the first [firewalls] is an ongoing issue). There are many other problems you did not point to, but that are also problems, and remain problems. Moving to git as a transport could potentially address some problems, with certain other tradeoffs in terms of other tooling choices we would have to make. However, I don?t think that migrating to git will solve any of the problems you mentioned above in your parenthetical. It _does_ help with the incremental fetch issue (though there are other ways to do that), and it _is_ a way to tackle the index signing issue, though I?m not sure that it is the best way (in particular, given the difficulty of configuring git _with keys_ on windows). > > Cheers, > Gershom From gershomb at gmail.com Mon May 4 13:55:34 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 4 May 2015 09:55:34 -0400 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: On May 4, 2015 at 4:42:05 AM, Mathieu Boespflug (mboes at tweag.net) wrote: > - cabal-install mysteriously dropping HTTP connections and corrupting > .cabal files: this particular firewall that I've seen is used by > hundreds of developers in the company without it silently truncating > requests on anything else but Cabal updates. Investigations so far > point to a bad interaction between Network.HTTP and lazy bytestrings, > see http://www.hawaga.org.uk/tmp/bug-cabal-zlib-http-lazy.html (no bug > report just yet). Reusing the same download mechanism that hundreds of > others are already using in the company means we are not at risk of a > firewall triggering an obscure latent race condition in the way > cabal-install retrieves HTTP responses. It means if there is a real > problem with the firewall, it won't just be for the local Haskellian > outpost who are trying to sell Haskell to their boss, but for > everyone, and therefore fixed. Yes, in this particular case, clearly using git is a transport that works and using HTTP is a transport that doesn?t. But as you note, this appears to be a problem with the firewall, not the HTTP library. You?re right that moving to a transport used more widely would help this problem. But, so would moving to curl apparently. In any case, as I wrote, the best way to address this is to make ourselves more generally flexible in our transport layer ? and the way to do this is not to swap the HTTP library simply for git, but to open up our choices more broadly. Which is precisely the plan already under discussion with regards to Cabal. Git is no magic bullet here. It is just ?anything besides the current thing that happens to trigger a specific bug in a specific firewall." > - the reversing revisions issue was NOT just a display issue: it > completely broke Stackage Nightly builds that day, which just calls > `cabal update` under the hood: > https://github.com/haskell/hackage-server/issues/305. Other users of > Hackage in that time window also experienced the issue. It's an issue > that caused massive breakage in a lot of places. Notice how PkgInfo_v2 > is a data structure that is entirely redundant with what Git would > provide already, so need not be serialized to disk, have migrations > written for it, etc, nor perhaps exist at all. Further, Git would have > made it quite impossible to distribute what amounts to a rewritten and > inadvertently tampered with history (because the clients would have > noticed and refused to fast forward). Fewer pieces of state managed > independently + less code = more reliable service. Ah I see ? they were flipped in the migration, not just in the display of the data. Regardless ? there will always be a layer between our data storage ? be it git, acid-state, database, anything else ? and the programmatic use we make of that data. No matter what we do to that storage layer, the intermediate layer will need to turn that into a programmatic representation, and then the frontend services will need to display/make use of it. No matter what, there is always room for such bugs. You might say ?but the server couldn?t cause such a bug in this system!? That?s silly ? the deserialization from that storage layer will just take place later then ? at each client. And they could cause such a bug. So yes, the literal place the bug was found is in code that would be different under a different storage layer. But there?s absolutely nothing in switching storage layers that rules out such bugs. And furthermore, in the migration you propose, which involves taking all our data, pushing it into an entirely new representation, and then rewriting the entire hackage-server to talk to this new representation at all stages, and writing cabal-install to do the same ? I promise that this would necessarily create a _whole lot_ of bugs. Again, there may be reasons to do this (I?m dubious) ? but let?s not overstate them to sell the case. > Hosting we don't have to > manage ourselves is hosting we don't have to keep humming. Of course > no service guarantees 100% uptime, so mirrors are a key additional (or > alternative) ingredient here. Efficient, low-latency and reliable > mirroring is certainly possible by other means, but mirroring a > history of changes is exactly what Git was designed for, and what it > does well. Why reinvent that? In the last case here, you say that mirroring is easier with git? But don?t we already have mirroring now? And haven?t we had it for some time? The work underway, to my knowledge, is only to make mirroring more secure (as a related consequence of making hackage in general more secure). So this seems a silly thing to raise. > > However, I don?t think that migrating to git will solve any of the problems you mentioned > above in your parenthetical. It _does_ help with the incremental fetch issue (though > there are other ways to do that), and it _is_ a way to tackle the index signing issue, though > I?m not sure that it is the best way (in particular, given the difficulty of configuring > git _with keys_ on windows). > > That's an interesting concern, though without knowing more, this is > not an actionable issue. What difficulties? If MinGHC packaged > Git+gpg4win, what would the issue be? I can give you an example I ran into with MinGHC already ? I had a preexisting cygwin install on my machine, and tried to install MinGHC. This mixed msys paths with cygwin paths and everything mismatched and was horrible until I ripped out those msys paths. But now, of course, my new GHC can?t find the libraries to build against for e.g. doing a network reinstall, which was the entire point of the exercise. By analogy, many windows users may have an existing git, and some may have an existing gpg. These may come from windows binaries (in a few flavors ? direct, wrapped via tortoise, etc), from cygwin, or perhaps from another existing msys install. Now they?re going to get multiple copies of these programs on their system with potentially conflicting paths, settings, etc??(Same goes for gpg, but not git on mac). And since we won?t have guarantees that everyone will have git, we?ll need to maintain existing transports anyway, so this only gives us a very partial solution... I know there are some neat ideas in what you?re pushing for. But I feel like you?re overlooking all the potential issues ? and also just underestimating the amount of work it would take to cut everything over to a new storage layer, on both front and backend, while keeping the set of existing features intact.? ?Gershom From gershomb at gmail.com Mon May 4 15:49:56 2015 From: gershomb at gmail.com (Gershom B) Date: Mon, 4 May 2015 11:49:56 -0400 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: <1429185521.25663.103.camel@dunky.localdomain> <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: One more point I realized -- switching to git as a transport _for the package index_ isn't a general purpose solution to the transport problem. Users also need a transport to download cabalized packages, and also to upload them. (And, whenever we get distributed build-reports finished, to upload those too, I suppose.) To my knowledge, the idea on the table doesn't solve that? -g On Mon, May 4, 2015 at 9:55 AM, Gershom B wrote: > On May 4, 2015 at 4:42:05 AM, Mathieu Boespflug (mboes at tweag.net) wrote: > > > - cabal-install mysteriously dropping HTTP connections and corrupting > > .cabal files: this particular firewall that I've seen is used by > > hundreds of developers in the company without it silently truncating > > requests on anything else but Cabal updates. Investigations so far > > point to a bad interaction between Network.HTTP and lazy bytestrings, > > see http://www.hawaga.org.uk/tmp/bug-cabal-zlib-http-lazy.html (no bug > > report just yet). Reusing the same download mechanism that hundreds of > > others are already using in the company means we are not at risk of a > > firewall triggering an obscure latent race condition in the way > > cabal-install retrieves HTTP responses. It means if there is a real > > problem with the firewall, it won't just be for the local Haskellian > > outpost who are trying to sell Haskell to their boss, but for > > everyone, and therefore fixed. > > Yes, in this particular case, clearly using git is a transport that works > and using HTTP is a transport that doesn?t. But as you note, this appears > to be a problem with the firewall, not the HTTP library. You?re right that > moving to a transport used more widely would help this problem. But, so > would moving to curl apparently. In any case, as I wrote, the best way to > address this is to make ourselves more generally flexible in our transport > layer ? and the way to do this is not to swap the HTTP library simply for > git, but to open up our choices more broadly. Which is precisely the plan > already under discussion with regards to Cabal. Git is no magic bullet > here. It is just ?anything besides the current thing that happens to > trigger a specific bug in a specific firewall." > > > - the reversing revisions issue was NOT just a display issue: it > > completely broke Stackage Nightly builds that day, which just calls > > `cabal update` under the hood: > > https://github.com/haskell/hackage-server/issues/305. Other users of > > Hackage in that time window also experienced the issue. It's an issue > > that caused massive breakage in a lot of places. Notice how PkgInfo_v2 > > is a data structure that is entirely redundant with what Git would > > provide already, so need not be serialized to disk, have migrations > > written for it, etc, nor perhaps exist at all. Further, Git would have > > made it quite impossible to distribute what amounts to a rewritten and > > inadvertently tampered with history (because the clients would have > > noticed and refused to fast forward). Fewer pieces of state managed > > independently + less code = more reliable service. > > Ah I see ? they were flipped in the migration, not just in the display of > the data. Regardless ? there will always be a layer between our data > storage ? be it git, acid-state, database, anything else ? and the > programmatic use we make of that data. No matter what we do to that storage > layer, the intermediate layer will need to turn that into a programmatic > representation, and then the frontend services will need to display/make > use of it. No matter what, there is always room for such bugs. You might > say ?but the server couldn?t cause such a bug in this system!? That?s silly > ? the deserialization from that storage layer will just take place later > then ? at each client. And they could cause such a bug. So yes, the literal > place the bug was found is in code that would be different under a > different storage layer. But there?s absolutely nothing in switching > storage layers that rules out such bugs. > > And furthermore, in the migration you propose, which involves taking all > our data, pushing it into an entirely new representation, and then > rewriting the entire hackage-server to talk to this new representation at > all stages, and writing cabal-install to do the same ? I promise that this > would necessarily create a _whole lot_ of bugs. > > Again, there may be reasons to do this (I?m dubious) ? but let?s not > overstate them to sell the case. > > > Hosting we don't have to > > manage ourselves is hosting we don't have to keep humming. Of course > > no service guarantees 100% uptime, so mirrors are a key additional (or > > alternative) ingredient here. Efficient, low-latency and reliable > > mirroring is certainly possible by other means, but mirroring a > > history of changes is exactly what Git was designed for, and what it > > does well. Why reinvent that? > > In the last case here, you say that mirroring is easier with git? But > don?t we already have mirroring now? And haven?t we had it for some time? > The work underway, to my knowledge, is only to make mirroring more secure > (as a related consequence of making hackage in general more secure). So > this seems a silly thing to raise. > > > > However, I don?t think that migrating to git will solve any of the > problems you mentioned > > above in your parenthetical. It _does_ help with the incremental fetch > issue (though > > there are other ways to do that), and it _is_ a way to tackle the index > signing issue, though > > I?m not sure that it is the best way (in particular, given the > difficulty of configuring > > git _with keys_ on windows). > > > > That's an interesting concern, though without knowing more, this is > > not an actionable issue. What difficulties? If MinGHC packaged > > Git+gpg4win, what would the issue be? > > I can give you an example I ran into with MinGHC already ? I had a > preexisting cygwin install on my machine, and tried to install MinGHC. This > mixed msys paths with cygwin paths and everything mismatched and was > horrible until I ripped out those msys paths. But now, of course, my new > GHC can?t find the libraries to build against for e.g. doing a network > reinstall, which was the entire point of the exercise. > > By analogy, many windows users may have an existing git, and some may have > an existing gpg. These may come from windows binaries (in a few flavors ? > direct, wrapped via tortoise, etc), from cygwin, or perhaps from another > existing msys install. > > Now they?re going to get multiple copies of these programs on their system > with potentially conflicting paths, settings, etc? (Same goes for gpg, but > not git on mac). And since we won?t have guarantees that everyone will have > git, we?ll need to maintain existing transports anyway, so this only gives > us a very partial solution... > > I know there are some neat ideas in what you?re pushing for. But I feel > like you?re overlooking all the potential issues ? and also just > underestimating the amount of work it would take to cut everything over to > a new storage layer, on both front and backend, while keeping the set of > existing features intact. > > ?Gershom > -------------- next part -------------- An HTML attachment was scrubbed... URL: From joeyadams3.14159 at gmail.com Mon May 4 16:52:33 2015 From: joeyadams3.14159 at gmail.com (Joey Adams) Date: Mon, 4 May 2015 12:52:33 -0400 Subject: [Haskell-cafe] ANN: applicative-fail-1.0.0 In-Reply-To: References: Message-ID: I wanted something like this in an application I wrote a couple years ago. Namely, to be able to display all errors in a config file rather than just the first. What I settled on was a monad, but if an error occurred parsing an element, the value would go into the structure undefined, and at the end of running the parser, it would check for errors before returning the structure. Something like this: data ParsedConfig = ParsedConfig { server :: HostName, port :: Int } parseConfig = runConfigParser $ do server <- readString "server" port <- readInt "port" return ParsedConfig{..} -- record wild card If the "server" attribute is not available in the input, readString "server" will return an error value, but it will return. Thus, when the ParsedConfig is constructed, it will contain holes if there are any errors. But errors are logged separately, and will be reported before the ParsedConfig is used in the application. This isn't as semantically nice as the applicative approach (suppose you try to do conditional logic on an attribute, but it's an error value), but it's convenient because you can use RecordWildCards to gather up the attributes without repeating their names. I suppose you could still do this and use ApplicativeDo, but it's not available yet (or is it?) On Sat, May 2, 2015 at 4:32 PM, Alexey Uimanov wrote: > Hi guys, here is reworked applicative-fail > > http://hackage.haskell.org/package/applicative-fail-1.0.0 > > You can use it to e.g. parse requests in your web application, or in any > other parse-like stuff. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon May 4 17:02:02 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 04 May 2015 13:02:02 -0400 Subject: [Haskell-cafe] ANN: applicative-fail-1.0.0 In-Reply-To: References: Message-ID: <87vbg81dkl.fsf@gmail.com> Joey Adams writes: snip > This isn't as semantically nice as the applicative approach (suppose you > try to do conditional logic on an attribute, but it's an error value), but > it's convenient because you can use RecordWildCards to gather up the > attributes without repeating their names. I suppose you could still do > this and use ApplicativeDo, but it's not available yet (or is it?) > It's not available yet but progress is being made... [1] Cheers, - Ben [1] https://phabricator.haskell.org/D729 -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From j.strecha at gmail.com Mon May 4 17:46:31 2015 From: j.strecha at gmail.com (Johannes Strecha) Date: Mon, 4 May 2015 19:46:31 +0200 Subject: [Haskell-cafe] Parsing YAML with varying structure In-Reply-To: References: Message-ID: Thanks for the hint. I wasn't aware of <|>. However, I couldn't get it to work yet (due to missing background knowledge -- have to read up). JS. On Sun, May 3, 2015 at 9:26 AM, Michael Snoyman wrote: > I think the answer to your question revolves around the Alternative > instance for Parser. Does the following code help? > > Var <$> ((Left <$> parseJSON) <|> (Right <$> parseJSON)) > > What this is saying is "try to parse a MyList, and then wrap it with a > Left. If that fails, try to parse an Item and wrap it with a Right. > Whatever the result is from there, wrap it in a Var." > > On Sat, May 2, 2015 at 3:56 PM Johannes Strecha > wrote: > >> Dear Cafe, >> >> I need help parsing YAML files with varying structure. The minimal >> example is: a yaml file that has one key, which can hold either one >> key-value pair or two key value pairs. I have data types for the one key, >> and the two possible sub-keys: >> >> >data Var = Var { >> > v' :: Either MyList Item >> > } deriving Show >> > >> >data MyList = MyList { >> > a' :: Int, >> > b' :: Int >> > } deriving Show >> > >> >data Item = Item { >> > content' :: String >> > } deriving Show >> >> To read MyList and Item from the file I wrote FromJSON instances >> >> >instance FromJSON MyList where >> > parseJSON (Object m) = MyList <$> m .: (pack "a") <*> m .: (pack "b") >> > parseJSON x = fail ("not an object: " ++ show x) >> > >> >instance FromJSON Item where >> > parseJSON (Object m) = Item <$> m .: (pack "c") >> > parseJSON x = fail ("not an object: " ++ show x) >> >> I also have read functions for MyList and Item: >> >> >readItem :: IO Item >> >readItem = either (error.show) id <$> decodeFileEither "test.yaml" >> > >> >readMyList :: IO MyList >> >readMyList = either (error.show) id <$> decodeFileEither "test.yaml" >> >> The file test.yaml looks like >> >> >v: >> > a: 4 >> > b: 5 >> >> or, alternatively >> >> >v: >> > c: "test" >> >> The question is how I can decode test.yaml to get Var. Trying to code >> readVar like readItem (having FromJSON Var like FromJSON Item) failed. For >> convenience I attached the relevant source files. >> >> Regards, >> Johannes. >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From iavor.diatchki at gmail.com Mon May 4 21:16:36 2015 From: iavor.diatchki at gmail.com (Iavor Diatchki) Date: Mon, 4 May 2015 14:16:36 -0700 Subject: [Haskell-cafe] [Jobs] Galois is hiring Message-ID: Hello, Galois is hiring! We're looking for researchers, principal investigators, software engineers, and project leads with expertise in functional programming, formal methods, computer security, control systems, or networking. Positions are available at both our Portland OR and Arlington VA offices. For more information on the application process and the available positions, please visit out web site: http://corp.galois.com/careers -Iavor -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Tue May 5 03:42:33 2015 From: mike at proclivis.com (Proclivis) Date: Mon, 4 May 2015 21:42:33 -0600 Subject: [Haskell-cafe] FFI nested structs - malloc - free Message-ID: FFI Gurus, I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. The example at this link uses the same technique, so it will serve as an example. https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. But, there is no explicit free, nor a finalizer. Will the memory be freed when the Ptr of the Storable is freed? If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? Mike From mike at proclivis.com Tue May 5 03:45:40 2015 From: mike at proclivis.com (Proclivis) Date: Mon, 4 May 2015 21:45:40 -0600 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: References: Message-ID: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> I should have mentioned GHC 7.8.3 Ubuntu 64bit Sent from my iPad > On May 4, 2015, at 9:42 PM, Proclivis wrote: > > FFI Gurus, > > I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. > > The example at this link uses the same technique, so it will serve as an example. > > https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc > > Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. > > But, there is no explicit free, nor a finalizer. > > Will the memory be freed when the Ptr of the Storable is freed? > > If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? > > Mike > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From rasen.dubi at gmail.com Tue May 5 04:40:34 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Tue, 5 May 2015 07:40:34 +0300 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> Message-ID: Hi! Disclaimer: I haven't worked much with FFI, so I'd like someone confirmed my words. Seems that allocated memory in your example is supposed to be freed from inside C. It's not a memory leak. If I understand correctly documentation [1], malloc/free are just a simple wrappers around C's malloc/free. It's mallocForeignPtr that sets finalizer. Best regards, Alexey Shmalko [1]: https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ffi-ghc.html On Tue, May 5, 2015 at 6:45 AM, Proclivis wrote: > I should have mentioned GHC 7.8.3 Ubuntu 64bit > > Sent from my iPad > >> On May 4, 2015, at 9:42 PM, Proclivis wrote: >> >> FFI Gurus, >> >> I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. >> >> The example at this link uses the same technique, so it will serve as an example. >> >> https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc >> >> Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. >> >> But, there is no explicit free, nor a finalizer. >> >> Will the memory be freed when the Ptr of the Storable is freed? >> >> If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? >> >> Mike >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From s.j.thompson at kent.ac.uk Tue May 5 08:43:40 2015 From: s.j.thompson at kent.ac.uk (Simon Thompson) Date: Tue, 5 May 2015 09:43:40 +0100 Subject: [Haskell-cafe] IFL 2015 -- call for papers References: <201505041250.t44CoFq8031082@easychair.org> Message-ID: <04C80D50-B2C9-4A68-8096-0E2E3DC538E1@kent.ac.uk> IFL 2015 - Call for papers 27th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2015 University of Koblenz-Landau, Koblenz, Germany In cooperation with ACM SIGPLAN September 14-16, 2015 http://ifl2015.wikidot.com/ Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2015 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review Following the IFL tradition, IFL 2015 will use a post-symposium review process to produce the formal proceedings. All participants of IFL2015 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Important dates August 10: Submission deadline draft papers August 12: Notification of acceptance for presentation August 14: Early registration deadline August 21: Late registration deadline September 7: Submission deadline for pre-symposium proceedings September 14-16: IFL Symposium December 1: Submission deadline for post-symposium proceedings January 15, 2016: Notification of acceptance for post-symposium proceedings March 1, 2016: Camera-ready version for post-symposium proceedings Submission details Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2015 Topics IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2015, please contact the PC chair at rlaemmel at acm.org. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee Chair: Ralf L?mmel, University of Koblenz-Landau, Germany - Malgorzata Biernacka, University of Wroclaw, Poland - Laura M. Castro, University of A Coru?a, Spain - Martin Erwig, Oregon State University, USA - Dan Ghica, University of Birmingham, UK - Andrew Gill, University of Kansas, USA - Stephan Herhut, Google, USA - Zhenjiang Hu, National Institute of Informatics (NII), Japan - Mauro Jaskelioff, CIFASIS/Universidad Nacional de Rosario, Argentina - Fr?d?ric Jouault, ESEO, France - Oleg Kiselyov, Tohoku University, Japan - Lindsey Kuper, Indiana University, USA - Rita Loogen, Philipps-Universit?t Marburg, Germany - Akimasa Morihata, University of Tokyo, Japan - Atsushi Ohori, Tohoku University, Japan - Bruno C. D. S. Oliveira, The University of Hong Kong, Hong Kong - Frank Piessens, Katholieke Universiteit Leuven, Belgium - Norman Ramsey, Tufts University, USA - Matthew Roberts, Macquarie University, Australia - Manfred Schmidt-Schauss, Goethe-University Frankfurt, Germany - Simon Thompson, University of Kent, UK - Stephanie Weirich, University of Pennsylvania, USA - Steve Zdancewic, University of Pennsylvania , USA Venue The 27th IFL will be held in association with the Faculty of Computer Science, University of Koblenz-Landau, Campus Koblenz. Koblenz is well connected by train to several international airports. For instance, Koblenz can be reached from Frankfurt by high-speed train ICE within an hour. The modern Koblenz campus is close to the city center and can be reached by foot, bus, or cab. See the website for more information on the venue. Simon Thompson | Professor of Logic and Computation School of Computing | University of Kent | Canterbury, CT2 7NF, UK s.j.thompson at kent.ac.uk | M +44 7986 085754 | W www.cs.kent.ac.uk/~sjt From agocorona at gmail.com Tue May 5 09:40:05 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue, 5 May 2015 11:40:05 +0200 Subject: [Haskell-cafe] Extensible states Message-ID: Hi, Anyone used some of the extensible record packages to create a kind of extensible state monad? I mean something that besides having "get", "gets" and "put" would have some kind of "add" and "gets": add :: a -> State () gets :: State (Maybe a) or add :: LabelName -> a -> State () gets :: LabelName -> State (Maybe a) So that I can extend the state without using additional monad transformers. Monad transformers are very hard for beginners and scramble error messages I did the first option for MFlow, hplayground and Transient packages (setSData and getSData). But my solution uses a map indexed by type and this requires a lookup for each access. I would like to know if there is an alternative with no lookups. I?m not obsessed with speed but In some applications the speed may be important.... Anyone? -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Tue May 5 09:50:26 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 05 May 2015 12:50:26 +0300 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: Message-ID: <55489262.9020307@ro-che.info> On 05/05/15 12:40, Alberto G. Corona wrote: > Hi, > > Anyone used some of the extensible record packages to create a kind of > extensible state monad? > > I mean something that besides having "get", "gets" and "put" would have > some kind of "add" and "gets": > > add :: a -> State () > gets :: State (Maybe a) > > or > > add :: LabelName -> a -> State () > gets :: LabelName -> State (Maybe a) > > > So that I can extend the state without using additional monad > transformers. Monad transformers are very hard for beginners and > scramble error messages > > I did the first option for MFlow, hplayground and Transient packages > (setSData and getSData). But my solution uses a map indexed by type and > this requires a lookup for each access. > > I would like to know if there is an alternative with no lookups. I?m not > obsessed with speed but In some applications the speed may be important.... > > Anyone? If you care about the error message quality, you'd rather stay away from extensible records. And if you care about speed, most (all?) extensible records give you O(n) access, so you'd be actually better off with a simple (Hash)Map. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From rendel at informatik.uni-tuebingen.de Tue May 5 10:04:27 2015 From: rendel at informatik.uni-tuebingen.de (Tillmann Rendel) Date: Tue, 05 May 2015 12:04:27 +0200 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: References: <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> Message-ID: <554895AB.9040308@informatik.uni-tuebingen.de> Hi, Michael Snoyman wrote: > That said, I think bundling the necessary Git tooling with MinGHC is an > easy win. Agreed. I mostly want to lobby for actually bundling it (properly, see below) instead of merely hand-waiving about how easy it is to install git on Windows. > here's actually a really easy solution to "have Git installed": bundle it with MinGHC This solution is certainly possible, but I'm not so sure whether it is *really easy*. From my perspective, MinGHC+git should be able to coexist on a system with some other system that bundles git, say, FOO+git, and/or just a copy of git that the user installed. (Otherwise, installing git after installing MinGHC+git would break MinGHC+git which would be unfortunate, wouldn't it?) Now how should the various copies of git interact? - should they share a configuration file? - should they use the same shell? - should they ever call each other? I'm imaging a search-path-tweaking nightmare to get this to work. For example, what if a user sets up `git bisect` to call `cabal update` (as part of some larger script) which in turns would call `git whatever` to update the index. Presumably, that should be different copies of git involved. But maybe cabal would need only some low-level git stuff which don't interact with user configuration or use the shell at all? That would make things easier. I'm not sure how valid my concerns here are, but I'm not convinced by "Git is fairly well supported on Windows these days and installs easily." Tillmann From michael at snoyman.com Tue May 5 10:09:54 2015 From: michael at snoyman.com (Michael Snoyman) Date: Tue, 05 May 2015 10:09:54 +0000 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <554895AB.9040308@informatik.uni-tuebingen.de> References: <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> <554895AB.9040308@informatik.uni-tuebingen.de> Message-ID: We've implemented a fair amount of the Git-facing stuff here already (see the stackage-update package). It just needs to clone from an https Git repo on Github and fetch from the same repo. Signature verification is also possible, but not necessary to get an improvement over the current state of affairs. So I don't think interacting with user configs will be a blocker here. That said, I agree with the main thrust of your email: seeing is believing. Let's add Git and GPG to MinGHC and see where that puts us. As usual, more hands help out with getting these things done quicker, so if someone wants to get involved, let me know. But I expect this improvement to happen some time this month. On Tue, May 5, 2015 at 1:04 PM Tillmann Rendel < rendel at informatik.uni-tuebingen.de> wrote: > Hi, > > Michael Snoyman wrote: > > That said, I think bundling the necessary Git tooling with MinGHC is an > > easy win. > > Agreed. I mostly want to lobby for actually bundling it (properly, see > below) instead of merely hand-waiving about how easy it is to install > git on Windows. > > > here's actually a really easy solution to "have Git installed": bundle > it with MinGHC > > This solution is certainly possible, but I'm not so sure whether it is > *really easy*. From my perspective, MinGHC+git should be able to coexist > on a system with some other system that bundles git, say, FOO+git, > and/or just a copy of git that the user installed. (Otherwise, > installing git after installing MinGHC+git would break MinGHC+git which > would be unfortunate, wouldn't it?) > > Now how should the various copies of git interact? > > - should they share a configuration file? > - should they use the same shell? > - should they ever call each other? > > I'm imaging a search-path-tweaking nightmare to get this to work. For > example, what if a user sets up `git bisect` to call `cabal update` (as > part of some larger script) which in turns would call `git whatever` to > update the index. Presumably, that should be different copies of git > involved. > > But maybe cabal would need only some low-level git stuff which don't > interact with user configuration or use the shell at all? That would > make things easier. > > I'm not sure how valid my concerns here are, but I'm not convinced by > "Git is fairly well supported on Windows these days and installs easily." > > Tillmann > -------------- next part -------------- An HTML attachment was scrubbed... URL: From magnus at therning.org Tue May 5 10:10:20 2015 From: magnus at therning.org (Magnus Therning) Date: Tue, 5 May 2015 12:10:20 +0200 Subject: [Haskell-cafe] Improvements to package hosting and security In-Reply-To: <554895AB.9040308@informatik.uni-tuebingen.de> References: <87bninfdkp.fsf@karetnikov.org> <5541F93A.3050309@informatik.uni-tuebingen.de> <2C08370F-DBFD-4D93-B880-13EB94AAA400@gmail.com> <5544AA68.1000309@informatik.uni-tuebingen.de> <554895AB.9040308@informatik.uni-tuebingen.de> Message-ID: On 5 May 2015 at 12:04, Tillmann Rendel wrote: > Hi, > > Michael Snoyman wrote: >> >> That said, I think bundling the necessary Git tooling with MinGHC is an >> easy win. > > > Agreed. I mostly want to lobby for actually bundling it (properly, see > below) instead of merely hand-waiving about how easy it is to install git on > Windows. Or maybe just provide ghc for [msys2](https://github.com/msys2)? /M -- Magnus Therning OpenPGP: 0xAB4DFBA4 email: magnus at therning.org jabber: magnus at therning.org twitter: magthe http://therning.org/magnus From doug at cs.dartmouth.edu Tue May 5 13:07:48 2015 From: doug at cs.dartmouth.edu (Doug McIlroy) Date: Tue, 05 May 2015 09:07:48 -0400 Subject: [Haskell-cafe] finding things on haskell.org Message-ID: <201505051307.t45D7m0C009931@coolidge.cs.dartmouth.edu> The only search feature I'm aware of on the haskell website is the haskell wiki, which is a self-contained little corner. For example, the wiki says nothing about minGHC. To find out what the website has on the subject, I used a Google query: site:haskell.org minghc. Is there thought of a comprehensive site-search facility that can find anything, including stuff that hasn't been wiki-ized? Doug From mike at proclivis.com Tue May 5 13:22:03 2015 From: mike at proclivis.com (Michael Jones) Date: Tue, 5 May 2015 07:22:03 -0600 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> Message-ID: Alexey, That is an interesting insight. I suppose there are C API like that. In my case, the FFI calls ioctl, which calls i2cdev_ioctl, which calls i2cdev_ioctl_rdwr. The only function that can assume anything about the structure is i2cdev_ioctl_rdwr, which as you can see below copies the data, but does not free it. So in this particular case, I need the FFI to free it. On the other hand, I could write a wrapper in C that frees the structure if that is the way FFI is supposed to be used. Does anyone know if there is a FFI solution that would not require a wrapper? Mike static noinline int i2cdev_ioctl_rdrw(struct i2c_client *client, unsigned long arg) { struct i2c_rdwr_ioctl_data rdwr_arg; struct i2c_msg *rdwr_pa; u8 __user **data_ptrs; int i, res; if (copy_from_user(&rdwr_arg, (struct i2c_rdwr_ioctl_data __user *)arg, sizeof(rdwr_arg))) return -EFAULT; On May 4, 2015, at 10:40 PM, Alexey Shmalko wrote: > Hi! > > Disclaimer: I haven't worked much with FFI, so I'd like someone > confirmed my words. > > Seems that allocated memory in your example is supposed to be freed > from inside C. It's not a memory leak. > > If I understand correctly documentation [1], malloc/free are just a > simple wrappers around C's malloc/free. It's mallocForeignPtr that > sets finalizer. > > Best regards, > Alexey Shmalko > > [1]: https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ffi-ghc.html > > On Tue, May 5, 2015 at 6:45 AM, Proclivis wrote: >> I should have mentioned GHC 7.8.3 Ubuntu 64bit >> >> Sent from my iPad >> >>> On May 4, 2015, at 9:42 PM, Proclivis wrote: >>> >>> FFI Gurus, >>> >>> I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. >>> >>> The example at this link uses the same technique, so it will serve as an example. >>> >>> https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc >>> >>> Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. >>> >>> But, there is no explicit free, nor a finalizer. >>> >>> Will the memory be freed when the Ptr of the Storable is freed? >>> >>> If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? >>> >>> Mike >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From johannes.waldmann at htwk-leipzig.de Tue May 5 13:59:43 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Tue, 05 May 2015 15:59:43 +0200 Subject: [Haskell-cafe] Language.Perl? (static analysis of Perl code, in Haskell) Message-ID: <5548CCCF.7070303@htwk-leipzig.de> I am investigating options for analyzing, and refactoring, legacy Perl code. Ideally, the tools would be in a high-level language like Haskell. I found [Pugs][1] and (related) [Language.Perl5][2] but both appear dead. Is there something for Perl that would provide what [hack][4] provides for PHP, and [typescript][5] for JS? (Perhaps I should write a Perl to PHP compiler.) Yes, I know that [Perl is not parseable][3]. - J.W. [1]: http://hackage.haskell.org/package/Pugs [2]: http://hackage.haskell.org/package/HsPerl5 [3]: http://www.perlmonks.org/?node_id=800599 [4]: http://hacklang.org/ [5]: http://www.typescriptlang.org/ From gershomb at gmail.com Tue May 5 14:09:09 2015 From: gershomb at gmail.com (Gershom B) Date: Tue, 5 May 2015 10:09:09 -0400 Subject: [Haskell-cafe] finding things on haskell.org In-Reply-To: <201505051307.t45D7m0C009931@coolidge.cs.dartmouth.edu> References: <201505051307.t45D7m0C009931@coolidge.cs.dartmouth.edu> Message-ID: Site search is a good idea, and we?ve talked about it, but haven?t gotten around to it, perhaps because we?ve let the idea of a ?fancy? site-search (tied into haddocks, etc) get in the way of an ?adequate? one ? just using google?s site-specific embeddable search box. It might be worthwhile to have even the basic one, which is the one that is at all likely to happen. And in fact, one of the arguments against doing anything ourselves is ?google will be better? ? so then, we may as well embed google to make the use of this better thing easier. The ticket discussing these issues is here:?https://github.com/haskell-infra/hl/issues/79 ?Gershom On May 5, 2015 at 9:08:02 AM, Doug McIlroy (doug at cs.dartmouth.edu) wrote: > The only search feature I'm aware of on the haskell website is the > haskell wiki, which is a self-contained little corner. For example, > the wiki says nothing about minGHC. To find out what the website > has on the subject, I used a Google query: site:haskell.org minghc. > > Is there thought of a comprehensive site-search facility that can > find anything, including stuff that hasn't been wiki-ized? > > Doug > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From anatoly.zaretsky at gmail.com Tue May 5 14:37:45 2015 From: anatoly.zaretsky at gmail.com (Anatoly Zaretsky) Date: Tue, 5 May 2015 17:37:45 +0300 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> Message-ID: On Tue, May 5, 2015 at 4:22 PM, Michael Jones wrote: > > In my case, the FFI calls ioctl, which calls i2cdev_ioctl, which calls i2cdev_ioctl_rdwr. > > The only function that can assume anything about the structure is i2cdev_ioctl_rdwr, which as you can see below copies the data, but does not free it. This is a useful bit of context: generally the kernel does not use passed-in user pointers after a system call returns, so you might not need malloc/free at all. Consider this C code sample (don't know anything about this particular API, so the example can be horribly wrong): int some_i2c_bus_transaction(int i2c_dev_fd) { struct i2c_rdwr_ioctl_data req; struct i2c_msg msgs[2]; __u8 read_buf[64], write_buf[8]; write_buf[0] = 0x12; write_buf[1] = 0x34; write_buf[2] = 0x56; msgs[0].flags = I2C_M_RD; msgs[0].buf = write_buf; msgs[0].len = 3; msgs[1].buf = read_buf; msgs[1].len = sizeof(read_buf); req.nmsgs = 2; req.msgs = msgs; return ioctl(i2c_dev_fd, I2C_RDWR, &req); } If your usage is similar to this, you might consider using alloca* functions which are closer to C's automatic stack allocations than heavy-weight "low-level" heap allocations. See the first example in https://wiki.haskell.org/Foreign_Function_Interface#Memory_allocation -- Tolik From omari at smileystation.com Tue May 5 14:54:59 2015 From: omari at smileystation.com (Omari Norman) Date: Tue, 5 May 2015 10:54:59 -0400 Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 Message-ID: I noticed some significant changes to the flags included with -Wall in GHC 7.10. Many flags that were previously included in -Wall are now not included. These include: -fwarn-type-defaults -fwarn-name-shadowing -fwarn-missing-signatures -fwarn-hi-shadowing -fwarn-orphans -fwarn-unused-do-bind -fwarn-trustworthy-safe I can't find any mention in the release notes of this change in behavior. I was wondering what the rationale is for these changes? Any link to relevant discussion would be appreciated if it exists. Also, what opinion do people have? I previously kept my code -Wall clean, but sometimes that would be a pain. For instance I would munge local names so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only noticed this change in behavior in 7.10 because I was considering dumping -Wall, and when I looked at the 7.10 manual I saw that it does not enable -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 manual.) Does this change indicate that people were finding -Wall too onerous and, thus, not using it? I do remember reading complaints about -fwarn-unused-do-bind being added to -Wall, but I previously felt dirty about name shadowing though I wondered if munging names to avoid shadowing was actually worse. -------------- next part -------------- An HTML attachment was scrubbed... URL: From omari at smileystation.com Tue May 5 15:03:36 2015 From: omari at smileystation.com (Omari Norman) Date: Tue, 5 May 2015 11:03:36 -0400 Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: References: Message-ID: CORRECTION: -fwarn-trustworthy-safe was not in -Wall in GHC 7.8, but -fwarn-trustworthy-safe did not exist in GHC 7.8. On Tue, May 5, 2015 at 10:54 AM, Omari Norman wrote: > I noticed some significant changes to the flags included with -Wall in GHC > 7.10. Many flags that were previously included in -Wall are now not > included. These include: > > -fwarn-type-defaults > -fwarn-name-shadowing > -fwarn-missing-signatures > -fwarn-hi-shadowing > -fwarn-orphans > -fwarn-unused-do-bind > -fwarn-trustworthy-safe > > I can't find any mention in the release notes of this change in behavior. > > I was wondering what the rationale is for these changes? Any link to > relevant discussion would be appreciated if it exists. > > Also, what opinion do people have? I previously kept my code -Wall clean, > but sometimes that would be a pain. For instance I would munge local names > so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures > to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only > noticed this change in behavior in 7.10 because I was considering dumping > -Wall, and when I looked at the 7.10 manual I saw that it does not enable > -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 > manual.) Does this change indicate that people were finding -Wall too > onerous and, thus, not using it? > > I do remember reading complaints about -fwarn-unused-do-bind being added > to -Wall, but I previously felt dirty about name shadowing though I > wondered if munging names to avoid shadowing was actually worse. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mikesteele81 at gmail.com Tue May 5 16:10:32 2015 From: mikesteele81 at gmail.com (Michael Steele) Date: Tue, 5 May 2015 09:10:32 -0700 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> Message-ID: Michael, It looks like memory cleanup is being ignored in the example you linked to. newCString and mallocArray do not automatically free memory. When building nested structures simply in order to pass them to a few C functions, I like to use with* and alloca* functions whenever possible. The following (untested) example temporarily marshals a C structure containing 2 pointers to null-terminated strings, and passes that to a supplied action. 4-byte pointers and ints are assumed: > data Person = Person String String Int > withPerson :: Person -> (Ptr Person -> IO r) -> IO r > withPerson (Person fn ln age) f = > -- Haskell's layout rules allow you to line these all up vertically. > -- Just place all your allocations before the first 'do'. > withCString fn $ \pfn -> > withCString ln $ \pln -> > allocaBytes 12 $ \ptr -> do > pokeByteOff ptr 0 pfn > pokeByteOff ptr 4 pln > pokeByteOff ptr 8 age > f ptr In cases where you can't know ahead of time when the memory should be freed, you an use ForeignPtr. I think Real World Haskell gives an example of a nested structure marshaled in this way. By storing the ForeignPtr in a data object that gets carried around, you can guarantee that finalizes get called by the garbage collector only after you are done using them. I hope that helps. -- Michael Steele On Tue, May 5, 2015 at 6:22 AM, Michael Jones wrote: > Alexey, > > That is an interesting insight. I suppose there are C API like that. > > In my case, the FFI calls ioctl, which calls i2cdev_ioctl, which calls > i2cdev_ioctl_rdwr. > > The only function that can assume anything about the structure is > i2cdev_ioctl_rdwr, which as you can see below copies the data, but does not > free it. > > So in this particular case, I need the FFI to free it. > > On the other hand, I could write a wrapper in C that frees the structure > if that is the way FFI is supposed to be used. > > Does anyone know if there is a FFI solution that would not require a > wrapper? > > Mike > > static noinline int i2cdev_ioctl_rdrw(struct i2c_client *client, > unsigned long arg) > { > struct i2c_rdwr_ioctl_data rdwr_arg; > struct i2c_msg *rdwr_pa; > u8 __user **data_ptrs; > int i, res; > > if (copy_from_user(&rdwr_arg, > (struct i2c_rdwr_ioctl_data __user *)arg, > sizeof(rdwr_arg))) > return -EFAULT; > > > > On May 4, 2015, at 10:40 PM, Alexey Shmalko wrote: > > > Hi! > > > > Disclaimer: I haven't worked much with FFI, so I'd like someone > > confirmed my words. > > > > Seems that allocated memory in your example is supposed to be freed > > from inside C. It's not a memory leak. > > > > If I understand correctly documentation [1], malloc/free are just a > > simple wrappers around C's malloc/free. It's mallocForeignPtr that > > sets finalizer. > > > > Best regards, > > Alexey Shmalko > > > > [1]: > https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ffi-ghc.html > > > > On Tue, May 5, 2015 at 6:45 AM, Proclivis wrote: > >> I should have mentioned GHC 7.8.3 Ubuntu 64bit > >> > >> Sent from my iPad > >> > >>> On May 4, 2015, at 9:42 PM, Proclivis wrote: > >>> > >>> FFI Gurus, > >>> > >>> I created a c2hs FFI of a nested C structure, where struct A has a > pointer to a struct B. To do so, I used a malloc, but I am unsure if the > memory will be freed when the resulting Ptr is freed. > >>> > >>> The example at this link uses the same technique, so it will serve as > an example. > >>> > >>> > https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc > >>> > >>> Line 48 and 51 do the malloc and assign the pointer in the struct, > from inside a Storable poke implementation. > >>> > >>> But, there is no explicit free, nor a finalizer. > >>> > >>> Will the memory be freed when the Ptr of the Storable is freed? > >>> > >>> If it is, it implies that some magic keeps track of mallocs inside a > poke, and creates finalizers. Or, this example leaks. If it leaks, how do I > create a finalizer from inside a poke implementation? > >>> > >>> Mike > >>> > >>> _______________________________________________ > >>> Haskell-Cafe mailing list > >>> Haskell-Cafe at haskell.org > >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- -- Michael Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue May 5 16:25:17 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 05 May 2015 09:25:17 -0700 Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: References: Message-ID: <1430843013-sup-8975@sabre> Hello Omari, Just to double check, could you send us a program which fails to produce warnings on 7.10, which does produce warnings on 7.8, and the command line arguments to run it? I tried the following test: [ezyang at hs01 ghc-bisect]$ cat A.hs module A where -- f :: Bool -> Bool -- f x = x && (\x -> x) x g :: IO () g = do (readLn :: IO Int) return () [ezyang at hs01 ghc-bisect]$ ghc -c A.hs -Wall -fforce-recomp A.hs:5:9: Warning: A do-notation statement discarded a result of type ?Int? Suppress this warning by saying ?_ <- (readLn :: IO Int)? or by using the flag -fno-warn-unused-do-bind [ezyang at hs01 ghc-bisect]$ ghc --version The Glorious Glasgow Haskell Compilation System, version 7.10.1 This is 7.10 that is distributed by Arch Linux. I haven't tried any other distributions, including the pre-built binaries. Cheers, Edward Excerpts from Omari Norman's message of 2015-05-05 07:54:59 -0700: > I noticed some significant changes to the flags included with -Wall in GHC > 7.10. Many flags that were previously included in -Wall are now not > included. These include: > > -fwarn-type-defaults > -fwarn-name-shadowing > -fwarn-missing-signatures > -fwarn-hi-shadowing > -fwarn-orphans > -fwarn-unused-do-bind > -fwarn-trustworthy-safe > > I can't find any mention in the release notes of this change in behavior. > > I was wondering what the rationale is for these changes? Any link to > relevant discussion would be appreciated if it exists. > > Also, what opinion do people have? I previously kept my code -Wall clean, > but sometimes that would be a pain. For instance I would munge local names > so they wouldn't trigger -fwarn-name-shadowing, and I would add signatures > to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I only > noticed this change in behavior in 7.10 because I was considering dumping > -Wall, and when I looked at the 7.10 manual I saw that it does not enable > -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 > manual.) Does this change indicate that people were finding -Wall too > onerous and, thus, not using it? > > I do remember reading complaints about -fwarn-unused-do-bind being added to > -Wall, but I previously felt dirty about name shadowing though I wondered > if munging names to avoid shadowing was actually worse. From omari at smileystation.com Tue May 5 16:35:43 2015 From: omari at smileystation.com (Omari Norman) Date: Tue, 5 May 2015 12:35:43 -0400 Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: <1430843013-sup-8975@sabre> References: <1430843013-sup-8975@sabre> Message-ID: I was basing this solely off the documentation: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/options-sanity.html so this may just be a documentation bug. Someone emailed me off-list and said he reported it: https://ghc.haskell.org/trac/ghc/ticket/10386 Thanks. --Omari On Tue, May 5, 2015 at 12:25 PM, Edward Z. Yang wrote: > Hello Omari, > > Just to double check, could you send us a program which fails > to produce warnings on 7.10, which does produce warnings on 7.8, > and the command line arguments to run it? > I tried the following test: > > [ezyang at hs01 ghc-bisect]$ cat A.hs > module A where > -- f :: Bool -> Bool > -- f x = x && (\x -> x) x > g :: IO () > g = do (readLn :: IO Int) > return () > [ezyang at hs01 ghc-bisect]$ ghc -c A.hs -Wall -fforce-recomp > > A.hs:5:9: Warning: > A do-notation statement discarded a result of type ?Int? > Suppress this warning by saying ?_ <- (readLn :: IO Int)? > or by using the flag -fno-warn-unused-do-bind > [ezyang at hs01 ghc-bisect]$ ghc --version > The Glorious Glasgow Haskell Compilation System, version 7.10.1 > > This is 7.10 that is distributed by Arch Linux. I haven't > tried any other distributions, including the pre-built binaries. > > Cheers, > Edward > > Excerpts from Omari Norman's message of 2015-05-05 07:54:59 -0700: > > I noticed some significant changes to the flags included with -Wall in > GHC > > 7.10. Many flags that were previously included in -Wall are now not > > included. These include: > > > > -fwarn-type-defaults > > -fwarn-name-shadowing > > -fwarn-missing-signatures > > -fwarn-hi-shadowing > > -fwarn-orphans > > -fwarn-unused-do-bind > > -fwarn-trustworthy-safe > > > > I can't find any mention in the release notes of this change in behavior. > > > > I was wondering what the rationale is for these changes? Any link to > > relevant discussion would be appreciated if it exists. > > > > Also, what opinion do people have? I previously kept my code -Wall > clean, > > but sometimes that would be a pain. For instance I would munge local > names > > so they wouldn't trigger -fwarn-name-shadowing, and I would add > signatures > > to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I > only > > noticed this change in behavior in 7.10 because I was considering dumping > > -Wall, and when I looked at the 7.10 manual I saw that it does not enable > > -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 > > manual.) Does this change indicate that people were finding -Wall too > > onerous and, thus, not using it? > > > > I do remember reading complaints about -fwarn-unused-do-bind being added > to > > -Wall, but I previously felt dirty about name shadowing though I wondered > > if munging names to avoid shadowing was actually worse. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ezyang at mit.edu Tue May 5 16:41:23 2015 From: ezyang at mit.edu (Edward Z. Yang) Date: Tue, 05 May 2015 09:41:23 -0700 Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: References: <1430843013-sup-8975@sabre> Message-ID: <1430844062-sup-5535@sabre> Sounds like a documentation bug. Someone please file a new bug if they do find a warning that is no longer firing with -Wall. Edward Excerpts from Omari Norman's message of 2015-05-05 09:35:43 -0700: > I was basing this solely off the documentation: > > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/options-sanity.html > > so this may just be a documentation bug. Someone emailed me off-list and > said he reported it: > > https://ghc.haskell.org/trac/ghc/ticket/10386 > > Thanks. --Omari > > On Tue, May 5, 2015 at 12:25 PM, Edward Z. Yang wrote: > > > Hello Omari, > > > > Just to double check, could you send us a program which fails > > to produce warnings on 7.10, which does produce warnings on 7.8, > > and the command line arguments to run it? > > I tried the following test: > > > > [ezyang at hs01 ghc-bisect]$ cat A.hs > > module A where > > -- f :: Bool -> Bool > > -- f x = x && (\x -> x) x > > g :: IO () > > g = do (readLn :: IO Int) > > return () > > [ezyang at hs01 ghc-bisect]$ ghc -c A.hs -Wall -fforce-recomp > > > > A.hs:5:9: Warning: > > A do-notation statement discarded a result of type ?Int? > > Suppress this warning by saying ?_ <- (readLn :: IO Int)? > > or by using the flag -fno-warn-unused-do-bind > > [ezyang at hs01 ghc-bisect]$ ghc --version > > The Glorious Glasgow Haskell Compilation System, version 7.10.1 > > > > This is 7.10 that is distributed by Arch Linux. I haven't > > tried any other distributions, including the pre-built binaries. > > > > Cheers, > > Edward > > > > Excerpts from Omari Norman's message of 2015-05-05 07:54:59 -0700: > > > I noticed some significant changes to the flags included with -Wall in > > GHC > > > 7.10. Many flags that were previously included in -Wall are now not > > > included. These include: > > > > > > -fwarn-type-defaults > > > -fwarn-name-shadowing > > > -fwarn-missing-signatures > > > -fwarn-hi-shadowing > > > -fwarn-orphans > > > -fwarn-unused-do-bind > > > -fwarn-trustworthy-safe > > > > > > I can't find any mention in the release notes of this change in behavior. > > > > > > I was wondering what the rationale is for these changes? Any link to > > > relevant discussion would be appreciated if it exists. > > > > > > Also, what opinion do people have? I previously kept my code -Wall > > clean, > > > but sometimes that would be a pain. For instance I would munge local > > names > > > so they wouldn't trigger -fwarn-name-shadowing, and I would add > > signatures > > > to integers so they wouldn't trigger -fwarn-type-defaults. In fact, I > > only > > > noticed this change in behavior in 7.10 because I was considering dumping > > > -Wall, and when I looked at the 7.10 manual I saw that it does not enable > > > -fwarn-name-shadowing. (I still use 7.8 but Google pulled the 7.10 > > > manual.) Does this change indicate that people were finding -Wall too > > > onerous and, thus, not using it? > > > > > > I do remember reading complaints about -fwarn-unused-do-bind being added > > to > > > -Wall, but I previously felt dirty about name shadowing though I wondered > > > if munging names to avoid shadowing was actually worse. > > From aeyerstaylor11 at gmail.com Tue May 5 16:41:52 2015 From: aeyerstaylor11 at gmail.com (Alexander Eyers-Taylor) Date: Tue, 05 May 2015 17:41:52 +0100 Subject: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 In-Reply-To: <5548E1EA.8020104@gmail.com> References: <5548E1EA.8020104@gmail.com> Message-ID: <5548F2D0.6000005@gmail.com> Sorry I forgot to reply to the list. Here is my earlier email -------- Forwarded Message -------- Subject: Re: [Haskell-cafe] Significant changes in -Wall for GHC 7.10 Date: Tue, 05 May 2015 16:29:46 +0100 From: Alexander Eyers-Taylor To: Omari Norman Those seem to be preciously the flags enabled by -Wall. It seems when updating the documentation the negative was missed and it was updated to list the flags enabled by -Wall. I have submitted a ticket (#10386) to fix the bug. On 05/05/15 16:03, Omari Norman wrote: > CORRECTION: -fwarn-trustworthy-safe was not in -Wall in GHC 7.8, but > -fwarn-trustworthy-safe did not exist in GHC 7.8. > > On Tue, May 5, 2015 at 10:54 AM, Omari Norman > wrote: > > I noticed some significant changes to the flags included with > -Wall in GHC 7.10. Many flags that were previously included in > -Wall are now not included. These include: > > -fwarn-type-defaults > -fwarn-name-shadowing > -fwarn-missing-signatures > -fwarn-hi-shadowing > -fwarn-orphans > -fwarn-unused-do-bind > -fwarn-trustworthy-safe > > I can't find any mention in the release notes of this change in > behavior. > > I was wondering what the rationale is for these changes? Any link > to relevant discussion would be appreciated if it exists. > > Also, what opinion do people have? I previously kept my code > -Wall clean, but sometimes that would be a pain. For instance I > would munge local names so they wouldn't trigger > -fwarn-name-shadowing, and I would add signatures to integers so > they wouldn't trigger -fwarn-type-defaults. In fact, I only > noticed this change in behavior in 7.10 because I was considering > dumping -Wall, and when I looked at the 7.10 manual I saw that it > does not enable -fwarn-name-shadowing. (I still use 7.8 but > Google pulled the 7.10 manual.) Does this change indicate that > people were finding -Wall too onerous and, thus, not using it? > > I do remember reading complaints about -fwarn-unused-do-bind being > added to -Wall, but I previously felt dirty about name shadowing > though I wondered if munging names to avoid shadowing was actually > worse. > > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From ivanperezdominguez at gmail.com Tue May 5 18:15:09 2015 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 5 May 2015 19:15:09 +0100 Subject: [Haskell-cafe] ANN: Yampa 0.9.7 and 0.10.0 Message-ID: Dear all Two new versions of Yampa have just been made available on hackage. A short reminder for those who don't know: Yampa is a Functional Reactive Programming DSL structured around Signal Functions. It enforces a separation between effectful input/output and purely functional signal transformations. Arrow notation can be used to connect signal functions. Yampa has recently been used to write several games available on Github [2] and Google Play (for Android) [3, 4]. Regarding the new versions: - Version 0.9.7 is fully backwards compatible and includes minimal changes. - Version 0.10.0 is mostly, but not fully, backwards compatible and has been restructured in modules to make documentation easier. We expect this to help users find and understand the available combinators better. I have tried both versions with the game Haskanoid [2] and they work. If your project cannot be compiled or executed correctly with either version, please open an issue on our project page [1]. Yampa is being actively developed, and we are working on FRP extensions that we hope will be introduced in future versions. Code, documentation and research contributions are welcome. All the best Ivan [1] https://github.com/ivanperez-keera/Yampa [2] https://github.com/ivanperez-keera/haskanoid [3] https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies [4] https://github.com/keera-studios/magic-cookies From ivanperezdominguez at gmail.com Tue May 5 18:25:44 2015 From: ivanperezdominguez at gmail.com (Ivan Perez) Date: Tue, 5 May 2015 19:25:44 +0100 Subject: [Haskell-cafe] ANN: Yampa 0.9.7 and 0.10.0 In-Reply-To: References: Message-ID: Also, here is the link to the hackage page. The "haddocks" are still in the oven, they should be available in just a few minutes: http://hackage.haskell.org/package/Yampa Sorry for the extra noise. Cheers Ivan On 5 May 2015 at 19:15, Ivan Perez wrote: > Dear all > > Two new versions of Yampa have just been made available on hackage. > > A short reminder for those who don't know: Yampa is a Functional > Reactive Programming DSL structured around Signal Functions. It > enforces a separation between effectful input/output and purely > functional signal transformations. Arrow notation can be used to > connect signal functions. Yampa has recently been used to write > several games available on Github [2] and Google Play (for Android) > [3, 4]. > > Regarding the new versions: > > - Version 0.9.7 is fully backwards compatible and includes minimal changes. > > - Version 0.10.0 is mostly, but not fully, backwards compatible and > has been restructured in modules to make documentation easier. We > expect this to help users find and understand the available > combinators better. > > I have tried both versions with the game Haskanoid [2] and they work. > If your project cannot be compiled or executed correctly with either > version, please open an issue on our project page [1]. > > Yampa is being actively developed, and we are working on FRP > extensions that we hope will be introduced in future versions. Code, > documentation and research contributions are welcome. > > All the best > > Ivan > > [1] https://github.com/ivanperez-keera/Yampa > [2] https://github.com/ivanperez-keera/haskanoid > [3] https://play.google.com/store/apps/details?id=uk.co.keera.games.magiccookies > [4] https://github.com/keera-studios/magic-cookies From vogt.adam at gmail.com Tue May 5 19:23:01 2015 From: vogt.adam at gmail.com (adam vogt) Date: Tue, 5 May 2015 15:23:01 -0400 Subject: [Haskell-cafe] Extensible states In-Reply-To: <55489262.9020307@ro-che.info> References: <55489262.9020307@ro-che.info> Message-ID: On Tue, May 5, 2015 at 5:50 AM, Roman Cheplyaka wrote: > And if you care about speed, most (all?) extensible records give you > O(n) access, so you'd be actually better off with a simple (Hash)Map. > > Roman https://github.com/fumieval/extensible is an example that is log n lookup, but it's not really clear (to me) that it would be faster for a real program since you might have small records only, and maybe other operations are slower. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Tue May 5 20:20:40 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Tue, 5 May 2015 22:20:40 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> Message-ID: Hello, I'm not sure if this is what you're looking for, but vinyl + lens state monad combinators let you write something like this: foo :: State (Rec Foo [B,C,F]) Bar foo = ... bar = State (Rec Foo [A,B,C,D,E,F] bar = do ... x <- zoom rsubset foo ... rlens SA .= 3 ... Unfortunately Vinyl has O(n) lookup (unless it gets optimized away by sufficiently glorious haskell compiler, I guess, but I have no idea whether it actually can happen). But I'm not sure if the speed impact is noticeable, compared to using monad transformer stacks, for example. http://hackage.haskell.org/package/vinyl http://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl-Lens.html http://hackage.haskell.org/package/lens https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Tue May 5 21:03:20 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Tue, 5 May 2015 23:03:20 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> Message-ID: Thanks all of you. So there is no trick that can make extensible records O(1) for field access, like the native haskell records?. I didn?t know that all the extensible records have O(n) or O(log n) at most. That is not better than my State monad with a Data.Map. It is not possible to use HList-like records like the one that Adam mentioned since the type signature must not change when a new field is added. 2015-05-05 22:20 GMT+02:00 Marcin Mrotek : > Hello, > > I'm not sure if this is what you're looking for, but vinyl + lens state > monad combinators let you write something like this: > > foo :: State (Rec Foo [B,C,F]) Bar > foo = ... > > bar = State (Rec Foo [A,B,C,D,E,F] > bar = do > ... > x <- zoom rsubset foo > ... > rlens SA .= 3 > ... > > Unfortunately Vinyl has O(n) lookup (unless it gets optimized away by > sufficiently glorious haskell compiler, I guess, but I have no idea whether > it actually can happen). But I'm not sure if the speed impact is > noticeable, compared to using monad transformer stacks, for example. > > http://hackage.haskell.org/package/vinyl > http://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl-Lens.html > http://hackage.haskell.org/package/lens > > https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial > > Best regards, > Marcin Mrotek > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Wed May 6 05:34:42 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 6 May 2015 01:34:42 -0400 Subject: [Haskell-cafe] ANN: HList 0.4 Message-ID: Hello List, I've uploaded HList-0.4 [1]. Some highlights from this release: * support for 7.6 <= GHC <= 7.10 * new modules HCurry and HSort * many new functions: see the changelog [2] * data HList becomes data family. Trade-offs are explained in the documentation [3] Regards, Adam [1] http://hackage.haskell.org/package/HList-0.4.0.0 [2] http://hackage.haskell.org/package/HList-0.4.0.0/changelog [3] http://hackage.haskell.org/package/HList-0.4.0.0/docs/Data-HList-HList.html#g:1 -------------- next part -------------- An HTML attachment was scrubbed... URL: From Graham.Hutton at nottingham.ac.uk Wed May 6 09:04:40 2015 From: Graham.Hutton at nottingham.ac.uk (Graham Hutton) Date: Wed, 6 May 2015 10:04:40 +0100 Subject: [Haskell-cafe] Assistant Professorship in Nottingham Message-ID: <002ABECC-441D-4A2E-9FB6-CAFBB142EFE7@exmail.nottingham.ac.uk> Dear all, The School of Computer Science at the University of Nottingham is seeking to appoint a new Assistant Professor: http://www.nottingham.ac.uk/jobs/currentvacancies/ref/SCI41814 Applications in the area of the Functional Programming (FP) lab are encouraged. The FP lab is keen to receive applications from candidates with an excellent publication record, experience in combining theory with practice, and the ability to secure external funding to support their research. Further information about the FP lab is available from: http://fp.cs.nott.ac.uk The deadline for applications is Wednesday 15th July 2015. Best wishes, Graham -- Prof Graham Hutton Functional Programming Lab School of Computer Science University of Nottingham, UK http://www.cs.nott.ac.uk/~gmh This message and any attachment are intended solely for the addressee and may contain confidential information. If you have received this message in error, please send it back to me, and immediately delete it. Please do not use, copy or disclose the information contained in this message or in any attachment. Any views or opinions expressed by the author of this email do not necessarily reflect the views of the University of Nottingham. This message has been checked for viruses but the contents of an attachment may still contain software viruses which could damage your computer system, you are advised to perform your own checks. Email communications with the University of Nottingham may be monitored as permitted by UK legislation. From hvriedel at gmail.com Wed May 6 11:08:03 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 06 May 2015 13:08:03 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal Message-ID: <87zj5i55gs.fsf@gmail.com> Hello *, As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension currently relies on the system's C-compiler bundled `cpp` program to provide a "traditional mode" c-preprocessor. This has caused several problems in the past, since parsing Haskell code with a preprocessor mode designed for use with C's tokenizer has caused already quite some problems[1] in the past. I'd like to see GHC 7.12 adopt an implemntation of `-XCPP` that does not rely on the shaky system-`cpp` foundation. To this end I've created a wiki page https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp to describe the actual problems in more detail, and a couple of possible ways forward. Ideally, we'd simply integrate `cpphs` into GHC (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be discussed and debated since affects the overall-license of the GHC code-base, which may or may not be a problem to GHC's user-base (and that's what I hope this discussion will help to find out). So please go ahead and read the Wiki page... and then speak your mind! Thanks, HVR [1]: ...does anybody remember the issues Haskell packages (& GHC) encountered when Apple switched to the Clang tool-chain, thereby causing code using `-XCPP` to suddenly break due to subtly different `cpp`-semantics? From v.dijk.bas at gmail.com Wed May 6 11:11:25 2015 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed, 6 May 2015 13:11:25 +0200 Subject: [Haskell-cafe] How to define a type-level append? Message-ID: Hi, At the bottom I have a type-level programming related question, but first some preliminaries: > {-# LANGUAGE GADTs #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE DataKinds #-} > > import GHC.TypeLits I've implemented a protocol where a client can send a packet of orders to a server. An OrderPacket is either empty (represented by the "NoOrders" constructor) or consists of an Order and possibly more orders (represented by the: "order :> orders" constructor). An Order is defined by a type-level list of numeric addresses and a command. The semantics is that the server should address the command to the list of addresses. When the client sends a packet of orders, the server has to return a reply for each command for each address in order. I lifted this expectation into the type signature so that when the client sends an order the type-checker will complain if it tries to pattern match on the wrong reply. The above is formalized with the following GADT for a packet of orders (I left out some off-topic stuff): > data OrderPacket replies where > NoOrders :: OrderPacket '[] > (:>) :: !(Order addrs cmd) > -> !(OrderPacket replies) > -> OrderPacket > (RepliesFor addrs cmd :++: replies) > > infixr 5 :> > > data Order (addrs :: [Nat]) command where > Order :: (Command command) > => !command -> Order addrs command > > class Command command where > type Response command :: * > -- I left out some encoding/decoding related methods. > > type family RepliesFor (addrs :: [Nat]) > (cmd :: *) :: [*] where > RepliesFor '[] cmd = '[] > RepliesFor (addr ': addrs) cmd = > Reply addr cmd ': RepliesFor addrs cmd > > type family (xs :: [*]) :++: (ys :: [*]) :: [*] where > '[] :++: ys = ys > (x ': xs) :++: ys = x ': (xs :++: ys) > > infixr 5 :++: > > data Reply (addr :: Nat) command = > Response !(Maybe (Response command)) > -- I left out some other stuff that can be in a reply. > Now my problem, I would like to have the ability to append two OrderPackets. I would say the following type properly reflects what I want: > append :: OrderPacket replies1 > -> OrderPacket replies2 > -> OrderPacket (replies1 :++: replies2) How would I implement this? The following naive defintion > append NoOrders ys = ys > append (x :> xs) ys = x :> append xs ys gives the following type error: src/Test.lhs:77:25: Could not deduce ((RepliesFor addrs cmd :++: (replies :++: replies2)) ~ (replies1 :++: replies2)) from the context (replies1 ~ (RepliesFor addrs cmd :++: replies)) bound by a pattern with constructor :> :: forall (addrs :: [Nat]) cmd (replies :: [*]). Order addrs cmd -> OrderPacket replies -> OrderPacket (RepliesFor addrs cmd :++: replies), in an equation for ?append? at src/Test.lhs:77:11-17 NB: ?:++:? is a type function, and may not be injective Expected type: OrderPacket (replies1 :++: replies2) Actual type: OrderPacket (RepliesFor addrs cmd :++: (replies :++: replies2)) Relevant bindings include ys :: OrderPacket replies2 (bound at src/Test.lhs:77:20) xs :: OrderPacket replies (bound at src/Test.lhs:77:16) x :: Order addrs cmd (bound at src/Test.lhs:77:11) append :: OrderPacket replies1 -> OrderPacket replies2 -> OrderPacket (replies1 :++: replies2) (bound at src/Test.lhs:76:3) In the expression: x :> append xs ys In an equation for ?append?: append (x :> xs) ys = x :> append xs ys I suspect I need to adapt the type signature of "append" to suite the definition. Cheers, Bas From jan.stolarek at p.lodz.pl Wed May 6 11:38:16 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 6 May 2015 13:38:16 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: <201505061338.16090.jan.stolarek@p.lodz.pl> One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also bring problems of its own. I, for one, have run into problems with it when installing Agda. There is a very long thread here: https://lists.chalmers.se/pipermail/agda/2014/006975.html and twice as more on my private inbox. We've reached no conclusion about the cause and the only solution was to use system-cpp. Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me to make other arrangements." Janek [1] http://projects.haskell.org/cpphs/ Dnia ?roda, 6 maja 2015, Herbert Valerio Riedel napisa?: > Hello *, > > As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension > currently relies on the system's C-compiler bundled `cpp` program to > provide a "traditional mode" c-preprocessor. > > This has caused several problems in the past, since parsing Haskell code > with a preprocessor mode designed for use with C's tokenizer has caused > already quite some problems[1] in the past. I'd like to see GHC 7.12 > adopt an implemntation of `-XCPP` that does not rely on the shaky > system-`cpp` foundation. To this end I've created a wiki page > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > to describe the actual problems in more detail, and a couple of possible > ways forward. Ideally, we'd simply integrate `cpphs` into GHC > (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be > discussed and debated since affects the overall-license of the GHC > code-base, which may or may not be a problem to GHC's user-base (and > that's what I hope this discussion will help to find out). > > So please go ahead and read the Wiki page... and then speak your mind! > > > Thanks, > HVR > > > [1]: ...does anybody remember the issues Haskell packages (& GHC) > encountered when Apple switched to the Clang tool-chain, thereby > causing code using `-XCPP` to suddenly break due to subtly > different `cpp`-semantics? > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From nicholls.mark at vimn.com Wed May 6 12:01:39 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Wed, 6 May 2015 12:01:39 +0000 Subject: [Haskell-cafe] minor confusion over kinds.... Message-ID: And what "*" means as opposed to other things e.g. an explicit name "Nat" or a kind variable "k" > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} what I want is a typeclass with instances of type level Naturals here's the class, the parameter is of kind (* -> *) i.e. a is some sort of wrapper that maps from types to values > class Foo (a :: * -> *) where > type Bar a > bar :: a (Bar a) lets ignore DataKinds define Zero and Succ as distinct types uninhabited...but of kind "*" and "k -> *" > data Z1 > data S1 nat SNat1 :: * -> * > data SNat1 a where > SZ1 :: SNat1 Z1 > SS1 :: SNat1 a -> SNat1 (S1 a) off we go... > instance Foo SNat1 where > type Bar SNat1 = Z1 > bar = SZ1 now lets do it the datakind route > data Nat where > Z :: Nat > S :: Nat -> Nat ahhh...SNat is of kind "Nat -> *" > data SNat a where > SZ :: SNat 'Z > SS :: SNat a -> SNat ('S a) so I cant make it an instance of the same type class "The first argument of 'Foo' should have kind '* -> *', but 'SNat' has kind 'Nat -> *' In the instance declaration for 'Foo SNat'" > --instance Foo SNat where > -- type Bar SNat = 'Z > -- bar = SZ unless I redefine my class (which seems a bit silly) > class Foo' (a :: k -> *) where > type Bar' a :: k > bar' :: a (Bar' a) now it works. > instance Foo' SNat where > type Bar' SNat = 'Z > bar' = SZ clearly named kinds (?) are somehow distinct from unnames ones? CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Wed May 6 12:14:18 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 6 May 2015 14:14:18 +0200 Subject: [Haskell-cafe] ODP: Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> Message-ID: <554a05ae.86b4980a.0e11.2db3@mx.google.com> I think that the whole point of extensible records is to change the type on appending, to provide more safety at compile time than (hash) maps. If you don't want to use lenses (zoom) to combine different state monads, I guess a map is the best option. Kind regards, Marcin Mrotek -----Wiadomo?? oryginalna----- Od: "Alberto G. Corona " Wys?ano: ?2015-?05-?05 23:03 Do: "Marcin Mrotek" DW: "adam vogt" ; "haskell-cafe" Temat: Re: [Haskell-cafe] Extensible states Thanks all of you. So there is no trick that can make extensible records O(1) for field access, like the native haskell records?. I didn?t know that all the extensible records have O(n) or O(log n) at most. That is not better than my State monad with a Data.Map. It is not possible to use HList-like records like the one that Adam mentioned since the type signature must not change when a new field is added. 2015-05-05 22:20 GMT+02:00 Marcin Mrotek : Hello, I'm not sure if this is what you're looking for, but vinyl + lens state monad combinators let you write something like this: foo :: State (Rec Foo [B,C,F]) Bar foo = ... bar = State (Rec Foo [A,B,C,D,E,F] bar = do ... x <- zoom rsubset foo ... rlens SA .= 3 ... Unfortunately Vinyl has O(n) lookup (unless it gets optimized away by sufficiently glorious haskell compiler, I guess, but I have no idea whether it actually can happen). But I'm not sure if the speed impact is noticeable, compared to using monad transformer stacks, for example. http://hackage.haskell.org/package/vinyl http://hackage.haskell.org/package/vinyl-0.5.1/docs/Data-Vinyl-Lens.html http://hackage.haskell.org/package/lens https://www.fpcomplete.com/school/to-infinity-and-beyond/pick-of-the-week/a-little-lens-starter-tutorial Best regards, Marcin Mrotek _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From austin at well-typed.com Wed May 6 12:25:54 2015 From: austin at well-typed.com (Austin Seipp) Date: Wed, 6 May 2015 07:25:54 -0500 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Wed, May 6, 2015 at 6:08 AM, Herbert Valerio Riedel wrote: > Hello *, > > As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension > currently relies on the system's C-compiler bundled `cpp` program to > provide a "traditional mode" c-preprocessor. > > This has caused several problems in the past, since parsing Haskell code > with a preprocessor mode designed for use with C's tokenizer has caused > already quite some problems[1] in the past. I'd like to see GHC 7.12 > adopt an implemntation of `-XCPP` that does not rely on the shaky > system-`cpp` foundation. To this end I've created a wiki page > > https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > > to describe the actual problems in more detail, and a couple of possible > ways forward. Ideally, we'd simply integrate `cpphs` into GHC > (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be > discussed and debated since affects the overall-license of the GHC > code-base, which may or may not be a problem to GHC's user-base (and > that's what I hope this discussion will help to find out). > > So please go ahead and read the Wiki page... and then speak your mind! Thanks for writing this up, btw! It's nice to put the mumblings we've had for a while down 'on paper'. > > Thanks, > HVR > > > [1]: ...does anybody remember the issues Haskell packages (& GHC) > encountered when Apple switched to the Clang tool-chain, thereby > causing code using `-XCPP` to suddenly break due to subtly > different `cpp`-semantics? There are two (major) differences I can list, although I can only provide some specific examples OTTOMH: 1) Clang is more strict wrt language specifications. For example, GCC is lenient and allows a space between a macro identifier and the parenthesis denoting a parameter list; so saying 'FOO (x, y)' is valid with GCC (where FOO is a macro), but not with Clang. Sometimes this trips up existing code, but I've mostly seen it in GHC itself. 2) The lexing rules for C and Haskell simply are not the same in general. For example, what should "FOO(a' + b')" parse to? Well, in Haskell, 'prime' is a valid component from an identifier and in this case the parse should be "a prime + b prime", but in C the ' character is identified as beginning the start of a single-character literal, and a strict preprocessor like Clang's will reject that. In practice, I think people have mostly just avoided arcane lexer behaviors that don't work, and the only reason this was never a problem was because GCC or some variant was always the 'standard' C compiler GHC could rely on. > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > -- Regards, Austin Seipp, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From the.dead.shall.rise at gmail.com Wed May 6 13:03:38 2015 From: the.dead.shall.rise at gmail.com (Mikhail Glushenkov) Date: Wed, 6 May 2015 15:03:38 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On 6 May 2015 at 14:25, Austin Seipp wrote: > 2) The lexing rules for C and Haskell simply are not the same in > general. One area where this is irritating is that it makes it impossible to use Haskell multiline strings together with CPP. From alan.zimm at gmail.com Wed May 6 13:05:01 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Wed, 6 May 2015 15:05:01 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: Perhaps it makes sense to scan hackage to find all the different CPP idioms that are actually used in Haskell code, if it is a small/well-defined set it may be worth writing a simple custom preprocessor. Alan On Wed, May 6, 2015 at 3:03 PM, Mikhail Glushenkov < the.dead.shall.rise at gmail.com> wrote: > On 6 May 2015 at 14:25, Austin Seipp wrote: > > 2) The lexing rules for C and Haskell simply are not the same in > > general. > > One area where this is irritating is that it makes it impossible to > use Haskell multiline strings together with CPP. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Wed May 6 13:06:24 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Wed, 6 May 2015 13:06:24 +0000 Subject: [Haskell-cafe] minor confusion over kinds.... Message-ID: lets try it the other way around > instance Foo' SNat1 where > type Bar' SNat1 = Z1 > bar' = SZ1 that works! (my language will be wrong here...but the jist is) So in some something of kind "*->*" is substitutable for a parameter of kind "k -> *" "Nat->*" is substitutable for a parameter of kind "k -> *" "*->*" is substitutable for a parameter of kind "* -> *" "Nat->*" is NOT substitutable for a parameter of kind "* -> *" Hmmmm So why would I ever want to define a type class of kind (* -> *) -> Constraint Instead of (k -> *) -> Constraint ? I think I don't completely understand what's going on. From: Nicholls, Mark Sent: 06 May 2015 1:02 PM To: haskell-cafe at haskell.org Subject: minor confusion over kinds.... And what "*" means as opposed to other things e.g. an explicit name "Nat" or a kind variable "k" > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} what I want is a typeclass with instances of type level Naturals here's the class, the parameter is of kind (* -> *) i.e. a is some sort of wrapper that maps from types to values > class Foo (a :: * -> *) where > type Bar a > bar :: a (Bar a) lets ignore DataKinds define Zero and Succ as distinct types uninhabited...but of kind "*" and "k -> *" > data Z1 > data S1 nat SNat1 :: * -> * > data SNat1 a where > SZ1 :: SNat1 Z1 > SS1 :: SNat1 a -> SNat1 (S1 a) off we go... > instance Foo SNat1 where > type Bar SNat1 = Z1 > bar = SZ1 now lets do it the datakind route > data Nat where > Z :: Nat > S :: Nat -> Nat ahhh...SNat is of kind "Nat -> *" > data SNat a where > SZ :: SNat 'Z > SS :: SNat a -> SNat ('S a) so I cant make it an instance of the same type class "The first argument of 'Foo' should have kind '* -> *', but 'SNat' has kind 'Nat -> *' In the instance declaration for 'Foo SNat'" > --instance Foo SNat where > -- type Bar SNat = 'Z > -- bar = SZ unless I redefine my class (which seems a bit silly) > class Foo' (a :: k -> *) where > type Bar' a :: k > bar' :: a (Bar' a) now it works. > instance Foo' SNat where > type Bar' SNat = 'Z > bar' = SZ clearly named kinds (?) are somehow distinct from unnames ones? CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From asr at eafit.edu.co Wed May 6 13:43:03 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 6 May 2015 08:43:03 -0500 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <201505061338.16090.jan.stolarek@p.lodz.pl> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> Message-ID: I want to emphasize that cpphs is actively maintained as it's pointed out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The Agda team has found some cpphs bugs which have been *quickly* fixed by cpphs's author, Malcolm Wallace. Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek. On 6 May 2015 at 06:38, Jan Stolarek wrote: > One thing to keep in mind is that while cpphs will solve some problems of system-cpp, it will also > bring problems of its own. I, for one, have run into problems with it when installing Agda. There > is a very long thread here: > > https://lists.chalmers.se/pipermail/agda/2014/006975.html > > and twice as more on my private inbox. We've reached no conclusion about the cause and the only > solution was to use system-cpp. > > Regarding licensing issues: perhaps we should simply ask Malcolm Wallace if he would consider > changing the license for the sake of GHC? Or perhaps he could grant a custom-tailored license to > the GHC project? After all, the project page [1] says: " If that's a problem for you, contact me > to make other arrangements." > > Janek > > [1] http://projects.haskell.org/cpphs/ > > Dnia ?roda, 6 maja 2015, Herbert Valerio Riedel napisa?: >> Hello *, >> >> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >> currently relies on the system's C-compiler bundled `cpp` program to >> provide a "traditional mode" c-preprocessor. >> >> This has caused several problems in the past, since parsing Haskell code >> with a preprocessor mode designed for use with C's tokenizer has caused >> already quite some problems[1] in the past. I'd like to see GHC 7.12 >> adopt an implemntation of `-XCPP` that does not rely on the shaky >> system-`cpp` foundation. To this end I've created a wiki page >> >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp >> >> to describe the actual problems in more detail, and a couple of possible >> ways forward. Ideally, we'd simply integrate `cpphs` into GHC >> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be >> discussed and debated since affects the overall-license of the GHC >> code-base, which may or may not be a problem to GHC's user-base (and >> that's what I hope this discussion will help to find out). >> >> So please go ahead and read the Wiki page... and then speak your mind! >> >> >> Thanks, >> HVR >> >> >> [1]: ...does anybody remember the issues Haskell packages (& GHC) >> encountered when Apple switched to the Clang tool-chain, thereby >> causing code using `-XCPP` to suddenly break due to subtly >> different `cpp`-semantics? >> >> _______________________________________________ >> Glasgow-haskell-users mailing list >> Glasgow-haskell-users at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > --- > Politechnika ??dzka > Lodz University of Technology > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? > prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > This email contains information intended solely for the use of the individual to whom it is addressed. > If you are not the intended recipient or if you have received this message in error, > please notify the sender and delete it from your system. > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -- Andr?s From karel.gardas at centrum.cz Wed May 6 13:56:24 2015 From: karel.gardas at centrum.cz (Karel Gardas) Date: Wed, 06 May 2015 15:56:24 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5i55gs.fsf@gmail.com> References: <87zj5i55gs.fsf@gmail.com> Message-ID: <554A1D88.2010604@centrum.cz> Herbert, what about to extend plan (1) to also include cpphs as a bundled option with all cpphs advantages except no more fork/exec as the bundle will be in a form of binary application and not library? Shall I add it? I would not like to make a mess from your page... Thanks, Karel From spam at scientician.net Wed May 6 14:21:02 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 06 May 2015 16:21:02 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On 06-05-2015 15:05, Alan & Kim Zimmerman wrote: > Perhaps it makes sense to scan hackage to find all the different CPP idioms > that are actually used in Haskell code, if it is a small/well-defined set > it may be worth writing a simple custom preprocessor. > +1, I'll wager that the vast majority of usages are just for version range checks. If there are packages that require more, they could just keep using the system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd want to see real evidence that that's actually worth the effort/complication. Regards, From nr at cs.tufts.edu Wed May 6 14:25:00 2015 From: nr at cs.tufts.edu (Norman Ramsey) Date: Wed, 06 May 2015 10:25:00 -0400 Subject: [Haskell-cafe] How to estimate number of downloads of GHC or Haskell Platform? Message-ID: <20150506142500.49F9478552C@labrador.cs.tufts.edu> For a review, I'm trying to get a rough estimate of how many times GHC or the Haskell Platform have been downloaded. Although I'm sure I've seen this information graphed over time at workshops, my web-search skills are not turning up anything. I'd be quite happy to get an estimate to within a factor of ten. Can anyone suggest any sources, or a good way to estimate this number? Norman From svenpanne at gmail.com Wed May 6 14:32:11 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 6 May 2015 16:32:11 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: 2015-05-06 16:21 GMT+02:00 Bardur Arantsson : > +1, I'll wager that the vast majority of usages are just for version > range checks. The OpenGL-related packages used macros to generate some binding magic (a "foreign import" plus some helper functions for each API entry), not just range checks. I had serious trouble when Apple switched to clang, so as a quick fix, the macro-expanded (via GCC's CPP) sources had been checked in. :-P Nowadays the binding is generated from the OpenGL XML registry file, so this is not an issue anymore. > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. Simply relying on the system CPP doesn't work due to the various differences between GCC's CPP and the one from clang, see e.g. https://github.com/haskell-opengl/OpenGLRaw/issues/18#issuecomment-31428380. Ignoring the problem doesn't make it go away... ;-) Note that we still need CPP to handle the various calling conventions on the different platforms when the FFI is used, so it's not only range checks, see e.g. https://github.com/haskell-opengl/OpenGLRaw/blob/master/OpenGLRaw.cabal#L588. From allbery.b at gmail.com Wed May 6 15:28:45 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 6 May 2015 11:28:45 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Wed, May 6, 2015 at 10:59 AM, Bardur Arantsson wrote: > (I'm not going to be doing any of the work, so this is just armchairing, > but this seems like an 80/20 solution would be warranted.) > Only if you're convinced it will remain 80/20 for the foreseeable future. I do not want to bet on Linux always being gcc (and dislike the One True Platform-ism that line of thought encourages). -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed May 6 15:33:35 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 6 May 2015 11:33:35 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87ioc5vi81.fsf@feelingofgreen.ru> References: <87zj5i55gs.fsf@gmail.com> <87ioc5vi81.fsf@feelingofgreen.ru> Message-ID: On Wed, May 6, 2015 at 11:27 AM, Kosyrev Serge <_deepfire at feelingofgreen.ru> wrote: > Why *shouldn't* TH fill that role? What can be done about it? For one, it's difficult to make it available in cross compilers (granted, work is being done on this) and not available on some platforms (ARM has been a problem, dunno if it currently is). For another, I don't think you can currently control things like imports or LANGUAGE pragmas --- and as TH is currently constructed it's not clear that you could do so, or that you could do so in a way that is sane for users. This is not to say that I like cpp --- I'd like it a lot more if it weren't actually using a C preprocessor that is not actually under our control or guaranteed to be compatible with Haskell --- but it does provide a "meta" in a different dimension than TH does. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Wed May 6 15:39:52 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 6 May 2015 11:39:52 -0400 Subject: [Haskell-cafe] How to define a type-level append? In-Reply-To: References: Message-ID: Hi Bas, Seems to be that ghc needs help to see that :++: is associative. http://lpaste.net/2511796689740759040 is one way to show that. Alternatively you could make append a class, which lets ghc figure out ((RepliesFor addrs cmd :++: (replies :++: replies2)) ~ (replies1 :++: replies2)) later on: when the actual elements of the lists are known I think ghc may be able to see that both sides of the ~ simplify to the same type. Regards, Adam On Wed, May 6, 2015 at 7:11 AM, Bas van Dijk wrote: > Hi, > > At the bottom I have a type-level programming related > question, but first some preliminaries: > > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE DataKinds #-} > > > > import GHC.TypeLits > > I've implemented a protocol where a client can send a packet > of orders to a server. An OrderPacket is either empty > (represented by the "NoOrders" constructor) or consists of > an Order and possibly more orders (represented by the: > "order :> orders" constructor). > > An Order is defined by a type-level list of numeric > addresses and a command. The semantics is that the server > should address the command to the list of addresses. > > When the client sends a packet of orders, the server has to > return a reply for each command for each address in order. I > lifted this expectation into the type signature so that when > the client sends an order the type-checker will complain if > it tries to pattern match on the wrong reply. > > The above is formalized with the following GADT for a packet > of orders (I left out some off-topic stuff): > > > data OrderPacket replies where > > NoOrders :: OrderPacket '[] > > (:>) :: !(Order addrs cmd) > > -> !(OrderPacket replies) > > -> OrderPacket > > (RepliesFor addrs cmd :++: replies) > > > > infixr 5 :> > > > > data Order (addrs :: [Nat]) command where > > Order :: (Command command) > > => !command -> Order addrs command > > > > class Command command where > > type Response command :: * > > -- I left out some encoding/decoding related methods. > > > > type family RepliesFor (addrs :: [Nat]) > > (cmd :: *) :: [*] where > > RepliesFor '[] cmd = '[] > > RepliesFor (addr ': addrs) cmd = > > Reply addr cmd ': RepliesFor addrs cmd > > > > type family (xs :: [*]) :++: (ys :: [*]) :: [*] where > > '[] :++: ys = ys > > (x ': xs) :++: ys = x ': (xs :++: ys) > > > > infixr 5 :++: > > > > data Reply (addr :: Nat) command = > > Response !(Maybe (Response command)) > > -- I left out some other stuff that can be in a reply. > > > > Now my problem, I would like to have the ability to append > two OrderPackets. I would say the following type properly > reflects what I want: > > > append :: OrderPacket replies1 > > -> OrderPacket replies2 > > -> OrderPacket (replies1 :++: replies2) > > How would I implement this? The following naive defintion > > > append NoOrders ys = ys > > append (x :> xs) ys = x :> append xs ys > > gives the following type error: > > src/Test.lhs:77:25: > Could not deduce ((RepliesFor addrs cmd > :++: (replies :++: replies2)) > ~ (replies1 :++: replies2)) > from the context > (replies1 ~ (RepliesFor addrs cmd :++: replies)) > bound by a pattern with constructor > :> :: forall (addrs :: [Nat]) cmd (replies :: [*]). > Order addrs cmd > -> OrderPacket replies > -> OrderPacket > (RepliesFor addrs cmd :++: replies), > in an equation for ?append? > at src/Test.lhs:77:11-17 > NB: ?:++:? is a type function, and may not be injective > Expected type: OrderPacket (replies1 :++: replies2) > Actual type: OrderPacket > (RepliesFor addrs cmd :++: > (replies :++: replies2)) > Relevant bindings include > ys :: OrderPacket replies2 (bound at src/Test.lhs:77:20) > xs :: OrderPacket replies (bound at src/Test.lhs:77:16) > x :: Order addrs cmd (bound at src/Test.lhs:77:11) > append :: OrderPacket replies1 > -> OrderPacket replies2 > -> OrderPacket (replies1 :++: replies2) > (bound at src/Test.lhs:76:3) > In the expression: x :> append xs ys > In an equation for ?append?: > append (x :> xs) ys = x :> append xs ys > > I suspect I need to adapt the type signature of "append" to suite the > definition. > > Cheers, > > Bas > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Wed May 6 16:06:03 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 6 May 2015 18:06:03 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: <554a05ae.86b4980a.0e11.2db3@mx.google.com> References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Just as an afterthought about the O(n) lookup issue - extensible records are dependently typed versions of old, well-known data structures, so you always have a trade off between lookup and appending. In Haskell it's relatively easy to implement dependently typed lists (Vinyl, HList, etc), or maps (?) (apparently, Extensible linked by Adam, but I admit I haven't looked into the code). Dependently typed arrays are trickier. I guess it could be, for example, hacked around a (Vector Dynamic), then using (fromJust . fromDynamic) when it's certain at compile time that a there's a value of a certain type hidden in there, but I'm not sure if anyone has actually implemented it. They would necessarily have O(n) append, though. Best regards, Marcin Mrotek From hvriedel at gmail.com Wed May 6 16:09:00 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Wed, 06 May 2015 18:09:00 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <20150506153605.GD1459@xobs-novena> (Stephen Paul Weber's message of "Wed, 6 May 2015 10:36:05 -0500") References: <87zj5i55gs.fsf@gmail.com> <20150506153605.GD1459@xobs-novena> Message-ID: <87h9rp663n.fsf@gmail.com> On 2015-05-06 at 17:36:05 +0200, Stephen Paul Weber wrote: >>As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension >>currently relies on the system's C-compiler bundled `cpp` program to >>provide a "traditional mode" c-preprocessor. > > Yes. This is one of my favourite things in GHC-land -- that an > existing, good-enough, standardised, and widely-deployed solution was > chosen over a NiH reinvention of preprocessing. This allows other > Haskell compilers to support CPP on basically any system (since cpp is > so standard) without much effort, or even if the compiler does not > support {-# LANGUAGE CPP -#} the user can easily run `cpp` over the > source files themselves before feeding the source into the compiler. > > Because it is a real `cpp` being used, the developmer must take care > to follow the CPP syntax in the file that will then be transformed > into Haskell by `cpp` in the same way that C, C++, and other > developers have to take extra care (especially around use of # and > end-of-line \) when using `cpp`, but this is the normal state of > affairs for a secondary preprocessor step. As a benefit, the source > code will be processable by standard `cpp` implementations available > for virtually every platform. > > In short, the current solution provides a very robust and portable way > to do pre-compile preprocessing, and I like it very much. The problem I have with that line of argument is that we're using the so-called 'traditional mode' of `cpp`[1] for which afaik there is no written down common specification different implementations commit to adhere to (well, that's because 'traditional mode' refers to some vague implementation-specific "pre-standard" cpp semantics). And how is the developer supposed to take care to follow the (traditional mode) CPP syntax, if he can't test it easily with all potentially used (traditional-mode) `cpp`s out there? This already has led to problems with Clang's cpp vs GCC's cpp. Moreover, I was under the impression that it's only a matter of time till `traditional mode` support may be dropped from C compiler toolchains. Otoh, we can't use an ISO C spec conforming c-preprocessor, as that would conflict even more heavily w/ Haskell's grammar to the point of being inpractical. [1]: https://gcc.gnu.org/onlinedocs/cpp/Traditional-Mode.html From v.dijk.bas at gmail.com Wed May 6 16:13:45 2015 From: v.dijk.bas at gmail.com (Bas van Dijk) Date: Wed, 6 May 2015 18:13:45 +0200 Subject: [Haskell-cafe] How to define a type-level append? In-Reply-To: References: Message-ID: Hi Adam, Both seem like good ideas. I will try which one works best and report back. Thanks! Bas On 6 May 2015 at 17:39, adam vogt wrote: > Hi Bas, > > Seems to be that ghc needs help to see that :++: is associative. > http://lpaste.net/2511796689740759040 is one way to show that. Alternatively > you could make append a class, which lets ghc figure out > > ((RepliesFor addrs cmd > :++: (replies :++: replies2)) > ~ (replies1 :++: replies2)) > > later on: when the actual elements of the lists are known I think ghc may be > able to see that both sides of the ~ simplify to the same type. > > Regards, > Adam > > On Wed, May 6, 2015 at 7:11 AM, Bas van Dijk wrote: >> >> Hi, >> >> At the bottom I have a type-level programming related >> question, but first some preliminaries: >> >> > {-# LANGUAGE GADTs #-} >> > {-# LANGUAGE TypeOperators #-} >> > {-# LANGUAGE TypeFamilies #-} >> > {-# LANGUAGE DataKinds #-} >> > >> > import GHC.TypeLits >> >> I've implemented a protocol where a client can send a packet >> of orders to a server. An OrderPacket is either empty >> (represented by the "NoOrders" constructor) or consists of >> an Order and possibly more orders (represented by the: >> "order :> orders" constructor). >> >> An Order is defined by a type-level list of numeric >> addresses and a command. The semantics is that the server >> should address the command to the list of addresses. >> >> When the client sends a packet of orders, the server has to >> return a reply for each command for each address in order. I >> lifted this expectation into the type signature so that when >> the client sends an order the type-checker will complain if >> it tries to pattern match on the wrong reply. >> >> The above is formalized with the following GADT for a packet >> of orders (I left out some off-topic stuff): >> >> > data OrderPacket replies where >> > NoOrders :: OrderPacket '[] >> > (:>) :: !(Order addrs cmd) >> > -> !(OrderPacket replies) >> > -> OrderPacket >> > (RepliesFor addrs cmd :++: replies) >> > >> > infixr 5 :> >> > >> > data Order (addrs :: [Nat]) command where >> > Order :: (Command command) >> > => !command -> Order addrs command >> > >> > class Command command where >> > type Response command :: * >> > -- I left out some encoding/decoding related methods. >> > >> > type family RepliesFor (addrs :: [Nat]) >> > (cmd :: *) :: [*] where >> > RepliesFor '[] cmd = '[] >> > RepliesFor (addr ': addrs) cmd = >> > Reply addr cmd ': RepliesFor addrs cmd >> > >> > type family (xs :: [*]) :++: (ys :: [*]) :: [*] where >> > '[] :++: ys = ys >> > (x ': xs) :++: ys = x ': (xs :++: ys) >> > >> > infixr 5 :++: >> > >> > data Reply (addr :: Nat) command = >> > Response !(Maybe (Response command)) >> > -- I left out some other stuff that can be in a reply. >> > >> >> Now my problem, I would like to have the ability to append >> two OrderPackets. I would say the following type properly >> reflects what I want: >> >> > append :: OrderPacket replies1 >> > -> OrderPacket replies2 >> > -> OrderPacket (replies1 :++: replies2) >> >> How would I implement this? The following naive defintion >> >> > append NoOrders ys = ys >> > append (x :> xs) ys = x :> append xs ys >> >> gives the following type error: >> >> src/Test.lhs:77:25: >> Could not deduce ((RepliesFor addrs cmd >> :++: (replies :++: replies2)) >> ~ (replies1 :++: replies2)) >> from the context >> (replies1 ~ (RepliesFor addrs cmd :++: replies)) >> bound by a pattern with constructor >> :> :: forall (addrs :: [Nat]) cmd (replies :: [*]). >> Order addrs cmd >> -> OrderPacket replies >> -> OrderPacket >> (RepliesFor addrs cmd :++: replies), >> in an equation for ?append? >> at src/Test.lhs:77:11-17 >> NB: ?:++:? is a type function, and may not be injective >> Expected type: OrderPacket (replies1 :++: replies2) >> Actual type: OrderPacket >> (RepliesFor addrs cmd :++: >> (replies :++: replies2)) >> Relevant bindings include >> ys :: OrderPacket replies2 (bound at src/Test.lhs:77:20) >> xs :: OrderPacket replies (bound at src/Test.lhs:77:16) >> x :: Order addrs cmd (bound at src/Test.lhs:77:11) >> append :: OrderPacket replies1 >> -> OrderPacket replies2 >> -> OrderPacket (replies1 :++: replies2) >> (bound at src/Test.lhs:76:3) >> In the expression: x :> append xs ys >> In an equation for ?append?: >> append (x :> xs) ys = x :> append xs ys >> >> I suspect I need to adapt the type signature of "append" to suite the >> definition. >> >> Cheers, >> >> Bas >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > From alexey.skladnoy at gmail.com Wed May 6 16:12:24 2015 From: alexey.skladnoy at gmail.com (Aleksey Khudyakov) Date: Wed, 6 May 2015 19:12:24 +0300 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> Message-ID: On 6 May 2015 at 00:03, Alberto G. Corona wrote: > Thanks all of you. > > So there is no trick that can make extensible records O(1) for field access, > like the native haskell records?. I didn?t know that all the extensible > records have O(n) or O(log n) at most. > In principle it's possible to get O(1) access for extensible records. It depends on how undelying data layout. It's obviously not possible to have O(1) if record is build from ordinary ADT but if if record internally is array it is possible. Of course downside is appending is O(n) in that case From marcosomarviera at gmail.com Wed May 6 16:35:29 2015 From: marcosomarviera at gmail.com (Marcos Viera) Date: Wed, 6 May 2015 13:35:29 -0300 Subject: [Haskell-cafe] Extensible states In-Reply-To: <55489262.9020307@ro-che.info> References: <55489262.9020307@ro-che.info> Message-ID: In the following paper we introduced an implementation that performs lookup in O(log n) and insertion in O(1) by moving some of the work to compile time. @INPROCEEDINGS { MVP13, AUTHOR = { Martinez, Bruno and Viera, Marcos and Pardo, Alberto }, TITLE = { Just Do It While Compiling!: Fast Extensible Records in Haskell }, BOOKTITLE = { Proceedings of the ACM SIGPLAN 2013 Workshop on Partial Evaluation and Program Manipulation }, SERIES = { PEPM '13 }, YEAR = { 2013 }, ISBN = { 978-1-4503-1842-6 }, LOCATION = { Rome, Italy }, PAGES = { 77--86 }, NUMPAGES = { 10 }, DOI = { 10.1145/2426890.2426908 }, ACMID = { 2426908 }, PUBLISHER = { ACM }, ADDRESS = { New York, NY, USA }, KEYWORDS = { balanced trees, extensible records, haskell, hlist, staged computation, type-level programming }, PDF = { http://www.fing.edu.uy/~mviera/papers/pepm13.pdf }, } Best, marcos On Tue, May 5, 2015 at 6:50 AM, Roman Cheplyaka wrote: > On 05/05/15 12:40, Alberto G. Corona wrote: > > Hi, > > > > Anyone used some of the extensible record packages to create a kind of > > extensible state monad? > > > > I mean something that besides having "get", "gets" and "put" would have > > some kind of "add" and "gets": > > > > add :: a -> State () > > gets :: State (Maybe a) > > > > or > > > > add :: LabelName -> a -> State () > > gets :: LabelName -> State (Maybe a) > > > > > > So that I can extend the state without using additional monad > > transformers. Monad transformers are very hard for beginners and > > scramble error messages > > > > I did the first option for MFlow, hplayground and Transient packages > > (setSData and getSData). But my solution uses a map indexed by type and > > this requires a lookup for each access. > > > > I would like to know if there is an alternative with no lookups. I?m not > > obsessed with speed but In some applications the speed may be > important.... > > > > Anyone? > > > If you care about the error message quality, you'd rather stay away from > extensible records. > > And if you care about speed, most (all?) extensible records give you > O(n) access, so you'd be actually better off with a simple (Hash)Map. > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Wed May 6 16:47:28 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Wed, 6 May 2015 12:47:28 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <20150506153605.GD1459@xobs-novena> References: <87zj5i55gs.fsf@gmail.com> <20150506153605.GD1459@xobs-novena> Message-ID: On Wed, May 6, 2015 at 11:36 AM, Stephen Paul Weber < singpolyma at singpolyma.net> wrote: > Yes. This is one of my favourite things in GHC-land -- that an existing, > good-enough, standardised, and widely-deployed solution was chosen over a > NiH reinvention of preprocessing I have to assume my irony detector is broken as well. Or maybe I should just assume that "all the world's Linux with gcc" is assumed to be forever true and forever reliable by "all right-thinking people" so let's just sweep the nonissue under the rug because it can oh so obviously never be a real issue.... Because I had to face this back a couple decades ago, when my employer ported an application written in a 4GL (database language) to SCO Unix. The 4GL assumed cpp was the ever reliable pcc one and broke very badly when SCO used one integrated into its lexer (making it even more tightly wedded to C syntax than clang's). Eventually we replaced its cpp with a wrapper that ran m4 and redid everything else in m4's syntax. Which is why I was always a bit worried about ghc relying on cpp, was unsurprised when clang caused issues, and am rather annoyed that there are people who believe that they can just ignore it because REAL users will always be on Linux with gcc and all them furriners using weird OSes like OS X and FreeBSD can safely be ignored with their not-the-One-True-OS-and-compiler platforms. Additional historical note that I assume True Believers will ignore as meaningless: X11 used to make the same assumption that cpp was always and forever guaranteed to be friendly to non-C and this still shows at times in things like xrdb resource databases. They did accept the inevitable and (mostly) stop abusing it that way, and are now moving away from imake which likewise assumes it's safe to use cpp on Makefiles. (And yes, I encounter the same inability to comprehend or accept change there.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From howard_b_golden at yahoo.com Wed May 6 16:53:08 2015 From: howard_b_golden at yahoo.com (Howard B. Golden) Date: Wed, 6 May 2015 16:53:08 +0000 (UTC) Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87a8xhvh48.fsf@feelingofgreen.ru> References: <87a8xhvh48.fsf@feelingofgreen.ru> Message-ID: <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> At the risk of antagonizing some (most? all?) of you, how about... -XCPP stands for the native CPP -XGNUCPP stands for GNU's GCC CPP -XClangCPP stands for Clang's CPP -XCPPHS stands for CPPHS ... with the hope that TH is the future? Howard From vogt.adam at gmail.com Wed May 6 17:32:48 2015 From: vogt.adam at gmail.com (adam vogt) Date: Wed, 6 May 2015 13:32:48 -0400 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: I think there are many cases where some standard data type (that is not a list) is paired with type-level lists: I've tried the (unboxed) array case with http://code.haskell.org/HList/Data/HList/broken/RecordU.hs (worked with ghc 7.8), but it didn't seem to be any faster in my tests: I have a feeling that the index into the array should not be calculated as 1+1+1+1: the author of extensible does something that looks better. CTRex https://github.com/atzeus/CTRex does that dynamic+hash map idea. Another example is https :// github.com / nikita-volkov /record using one data type for each length supported Just as an afterthought about the O(n) lookup issue - extensible records are dependently typed versions of old, well-known data structures, so you always have a trade off between lookup and appending. In Haskell it's relatively easy to implement dependently typed lists (Vinyl, HList, etc), or maps (?) (apparently, Extensible linked by Adam, but I admit I haven't looked into the code). Dependently typed arrays are trickier. I guess it could be, for example, hacked around a (Vector Dynamic), then using (fromJust . fromDynamic) when it's certain at compile time that a there's a value of a certain type hidden in there, but I'm not sure if anyone has actually implemented it. They would necessarily have O(n) append, though. Best regards, Marcin Mrotek -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Wed May 6 17:47:46 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 6 May 2015 19:47:46 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Okay, perhaps I'm too newbie to understand the big picture, but it seems to me you can get either: a) O(1) access to any, arbitrarily selected (at runtime) field b) O(1) append I guess option a) is better performance-wise, as appending is usually done less often than selecting (an O(1) slice is already possible with independently typed regular Haskell records) but dependently-typed-list-based implementation, or at the very least Vinyl (I haven't ever used HList) has the advantage of being dead simple in both implementation and usage. I mean, with Vinyl, you can write manual recursion over Rec's like: foo :: Rec ... -> Rec ... foo RNil = ... foo (r :& rs) = ... whenever GHC's typechecker gives up and goes on a strike; and I dare to say, with commonly used record sizes (have you ever used a record with more than, let's say, 10 fields?) the speed tradeoff is not noticeable. Don't get me wrong, I'm all in for cutting edge solutions like the one mentioned by Marcos, but I do think that rejecting the existing ones based on the non-constant time lookup is just premature optimisation. Best regards, Marcin Mrotek From marcin.jan.mrotek at gmail.com Wed May 6 17:49:37 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 6 May 2015 19:49:37 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: <55489262.9020307@ro-che.info> <554a05ae.86b4980a.0e11.2db3@mx.google.com> Message-ID: Sorry, I meant: *O(1) slicing is already possible with independently typed regular Haskell VECTORS Best regards, Marcin Mrotek From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Wed May 6 19:19:04 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Wed, 6 May 2015 20:19:04 +0100 Subject: [Haskell-cafe] MVars and locks Message-ID: <20150506191904.GC19164@weber> In the following section of the book "Parallel and Concurrent Programming in Haskell" http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook Simon Marlow explains that MVars can be used to implement something like locks on shared functional state: "To acquire the lock, we take the MVar, whereas, to update the variable and release the lock, we put the MVar." Am I right in thinking this only holds if we are careful to ensure both those operations happen in the given order? For example, if I take the MVar (lock) and I am about to put something back in (unlock) but someone else puts something in before I do, then the lock system becomes broken, doesn't it? So if we want to be sure we have a robust lock system we have to wrap up MVars in another abstraction? Tom From amindfv at gmail.com Wed May 6 19:33:37 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 6 May 2015 15:33:37 -0400 Subject: [Haskell-cafe] MVars and locks In-Reply-To: <20150506191904.GC19164@weber> References: <20150506191904.GC19164@weber> Message-ID: swapMVar and mofifyMVar are guaranteed to be atomic iirc Tom El May 6, 2015, a las 15:19, Tom Ellis escribi?: > In the following section of the book "Parallel and Concurrent Programming in > Haskell" > > http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook > > Simon Marlow explains that MVars can be used to implement something like > locks on shared functional state: "To acquire the lock, we take the MVar, > whereas, to update the variable and release the lock, we put the MVar." > > Am I right in thinking this only holds if we are careful to ensure both > those operations happen in the given order? > > For example, if I take the MVar (lock) and I am about to put something back > in (unlock) but someone else puts something in before I do, then the lock > system becomes broken, doesn't it? So if we want to be sure we have a > robust lock system we have to wrap up MVars in another abstraction? > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From fryguybob at gmail.com Wed May 6 19:34:47 2015 From: fryguybob at gmail.com (Ryan Yates) Date: Wed, 6 May 2015 15:34:47 -0400 Subject: [Haskell-cafe] MVars and locks In-Reply-To: <20150506191904.GC19164@weber> References: <20150506191904.GC19164@weber> Message-ID: When you are using an MVar as a lock, you will not want anyone to put something into the MVar without already being the *one* taking from the lock in the first place. You can think of the value in the MVar as a token indicating that you are in the critical section that no other thread can be in unless they hold the token. On Wed, May 6, 2015 at 3:19 PM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > In the following section of the book "Parallel and Concurrent Programming > in > Haskell" > > > http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook > > Simon Marlow explains that MVars can be used to implement something like > locks on shared functional state: "To acquire the lock, we take the MVar, > whereas, to update the variable and release the lock, we put the MVar." > > Am I right in thinking this only holds if we are careful to ensure both > those operations happen in the given order? > > For example, if I take the MVar (lock) and I am about to put something back > in (unlock) but someone else puts something in before I do, then the lock > system becomes broken, doesn't it? So if we want to be sure we have a > robust lock system we have to wrap up MVars in another abstraction? > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From marcin.jan.mrotek at gmail.com Wed May 6 19:46:20 2015 From: marcin.jan.mrotek at gmail.com (Marcin Mrotek) Date: Wed, 6 May 2015 21:46:20 +0200 Subject: [Haskell-cafe] MVars and locks In-Reply-To: References: <20150506191904.GC19164@weber> Message-ID: I hope I'm not derailing, but unless you have a good reason not to do so, please use STM instead of MVars. Best regards, Marcin Mrotek From jan.stolarek at p.lodz.pl Wed May 6 19:55:56 2015 From: jan.stolarek at p.lodz.pl (Jan Stolarek) Date: Wed, 6 May 2015 21:55:56 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> Message-ID: <201505062155.56858.jan.stolarek@p.lodz.pl> > I want to emphasize that cpphs is actively maintained as it's pointed > out in https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCp. The > Agda team has found some cpphs bugs which have been *quickly* fixed by > cpphs's author, Malcolm Wallace. Yes. It was not my intention to imply in any way that cpphs suffers from maintanance issues. > Unfortunately I have not been able to track down the problem mentioned by Janek Stolarek. Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale settings although we were unable to track down the cause. I also recall someone else reported being affected by the same problem. So, until that problem is solved I would say it is a blocker as it would essentialy make development of GHC impossible for some people. Janek > > On 6 May 2015 at 06:38, Jan Stolarek wrote: > > One thing to keep in mind is that while cpphs will solve some problems of > > system-cpp, it will also bring problems of its own. I, for one, have run > > into problems with it when installing Agda. There is a very long thread > > here: > > > > https://lists.chalmers.se/pipermail/agda/2014/006975.html > > > > and twice as more on my private inbox. We've reached no conclusion about > > the cause and the only solution was to use system-cpp. > > > > Regarding licensing issues: perhaps we should simply ask Malcolm Wallace > > if he would consider changing the license for the sake of GHC? Or perhaps > > he could grant a custom-tailored license to the GHC project? After all, > > the project page [1] says: " If that's a problem for you, contact me to > > make other arrangements." > > > > Janek > > > > [1] http://projects.haskell.org/cpphs/ > > > > Dnia ?roda, 6 maja 2015, Herbert Valerio Riedel napisa?: > >> Hello *, > >> > >> As you may be aware, GHC's `{-# LANGUAGE CPP #-}` language extension > >> currently relies on the system's C-compiler bundled `cpp` program to > >> provide a "traditional mode" c-preprocessor. > >> > >> This has caused several problems in the past, since parsing Haskell code > >> with a preprocessor mode designed for use with C's tokenizer has caused > >> already quite some problems[1] in the past. I'd like to see GHC 7.12 > >> adopt an implemntation of `-XCPP` that does not rely on the shaky > >> system-`cpp` foundation. To this end I've created a wiki page > >> > >> https://ghc.haskell.org/trac/ghc/wiki/Proposal/NativeCpp > >> > >> to describe the actual problems in more detail, and a couple of possible > >> ways forward. Ideally, we'd simply integrate `cpphs` into GHC > >> (i.e. "plan 2"). However, due to `cpp`s non-BSD3 license this should be > >> discussed and debated since affects the overall-license of the GHC > >> code-base, which may or may not be a problem to GHC's user-base (and > >> that's what I hope this discussion will help to find out). > >> > >> So please go ahead and read the Wiki page... and then speak your mind! > >> > >> > >> Thanks, > >> HVR > >> > >> > >> [1]: ...does anybody remember the issues Haskell packages (& GHC) > >> encountered when Apple switched to the Clang tool-chain, thereby > >> causing code using `-XCPP` to suddenly break due to subtly > >> different `cpp`-semantics? > >> > >> _______________________________________________ > >> Glasgow-haskell-users mailing list > >> Glasgow-haskell-users at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users > > > > --- > > Politechnika ??dzka > > Lodz University of Technology > > > > Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. > > Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez > > pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. > > > > This email contains information intended solely for the use of the > > individual to whom it is addressed. If you are not the intended recipient > > or if you have received this message in error, please notify the sender > > and delete it from your system. > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs --- Politechnika ??dzka Lodz University of Technology Tre?? tej wiadomo?ci zawiera informacje przeznaczone tylko dla adresata. Je?eli nie jeste?cie Pa?stwo jej adresatem, b?d? otrzymali?cie j? przez pomy?k? prosimy o powiadomienie o tym nadawcy oraz trwa?e jej usuni?cie. This email contains information intended solely for the use of the individual to whom it is addressed. If you are not the intended recipient or if you have received this message in error, please notify the sender and delete it from your system. From johannes.waldmann at htwk-leipzig.de Wed May 6 20:18:30 2015 From: johannes.waldmann at htwk-leipzig.de (Johannes Waldmann) Date: Wed, 06 May 2015 22:18:30 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal Message-ID: <554A7716.30008@htwk-leipzig.de> There is maybe another option: do what csharp does. Define a reduced "preprocessor" (for conditional compilation, but without macro expansion) as part of the language. (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx ) They must have have had good reasons for doing it this way. - J.W. PS: I was trying to add a proper reference (to the language spec) but this seems hard. It is Section 9.5 of ECMA-334. For viewing the newer specs, it seems you need to have MS-Word or VS installed. See also http://stackoverflow.com/questions/13467103/ From qdunkan at gmail.com Wed May 6 20:23:52 2015 From: qdunkan at gmail.com (Evan Laforge) Date: Wed, 6 May 2015 13:23:52 -0700 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554A7716.30008@htwk-leipzig.de> References: <554A7716.30008@htwk-leipzig.de> Message-ID: On Wed, May 6, 2015 at 1:18 PM, Johannes Waldmann wrote: > There is maybe another option: do what csharp does. > > Define a reduced "preprocessor" (for conditional compilation, > but without macro expansion) as part of the language. > (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx ) Rust is also doing this, but they have their own syntax, not CPP. I think they'll save themselves some hassle this way. From kane at kane.cx Wed May 6 20:27:53 2015 From: kane at kane.cx (David Kraeutmann) Date: Wed, 06 May 2015 22:27:53 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554A7716.30008@htwk-leipzig.de> References: <554A7716.30008@htwk-leipzig.de> Message-ID: <554A7949.8040800@kane.cx> I like this idea. If we need macro expansion, we can do that (and should be doing it) more formally and safer using TH. Ideally conditional compilation should be also done using TH, but it might be overkill for some use cases. On 5/6/2015 10:18 PM, Johannes Waldmann wrote: > There is maybe another option: do what csharp does. > > Define a reduced "preprocessor" (for conditional compilation, > but without macro expansion) as part of the language. > (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx ) > > They must have have had good reasons for doing it this way. > > - J.W. > > PS: I was trying to add a proper reference (to the language spec) > but this seems hard. It is Section 9.5 of ECMA-334. > For viewing the newer specs, it seems you need to have MS-Word or > VS installed. See also http://stackoverflow.com/questions/13467103/ > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4271 bytes Desc: S/MIME Cryptographic Signature URL: From amindfv at gmail.com Wed May 6 20:49:16 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Wed, 6 May 2015 16:49:16 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554A7949.8040800@kane.cx> References: <554A7716.30008@htwk-leipzig.de> <554A7949.8040800@kane.cx> Message-ID: <2CDE1006-5A95-4796-84E8-5B4B1709EE4F@gmail.com> My 2? would be that being backwards-compatible is more important than TH integration (if that's even possible). Even if we do the rust/c# way, I think we should use existing syntax. Cpp should really feel like a necessary evil, not like a central part of the language. Inelegance is a virtue. Tom El May 6, 2015, a las 16:27, David Kraeutmann escribi?: > I like this idea. If we need macro expansion, we can do that (and should > be doing it) more formally and safer using TH. > Ideally conditional compilation should be also done using TH, but it > might be overkill for some use cases. > > On 5/6/2015 10:18 PM, Johannes Waldmann wrote: >> There is maybe another option: do what csharp does. >> >> Define a reduced "preprocessor" (for conditional compilation, >> but without macro expansion) as part of the language. >> (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx ) >> >> They must have have had good reasons for doing it this way. >> >> - J.W. >> >> PS: I was trying to add a proper reference (to the language spec) >> but this seems hard. It is Section 9.5 of ECMA-334. >> For viewing the newer specs, it seems you need to have MS-Word or >> VS installed. See also http://stackoverflow.com/questions/13467103/ >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hyarion at iinet.net.au Wed May 6 20:58:53 2015 From: hyarion at iinet.net.au (Ben) Date: Thu, 07 May 2015 06:58:53 +1000 Subject: [Haskell-cafe] minor confusion over kinds.... In-Reply-To: References: Message-ID: <284044c4-e441-4720-bfe5-e5cf60ea1d81@email.android.com> It sounds a bit like you're under the impression that * is some sort of wildcard for kinds, when you talk about "named kinds vs unnamed kinds". That's not correct; * IS a "named kind", and its name is *. Nat is distinct from * in exactly the same way that Bool is distinct from (). Kind variables are exactly what you want, if you need to be able to handle both * -> * and Nat -> *. The reasons for not always using (k -> *) -> Constraint rather than (* -> *) -> Constraint are the same as the reason for not making everything polymorphic at the type level; sometimes you need the assumption that your k really is *, and sometimes you just don't need the polymorphism and prefer to keep it simple (especially as kind variables require extensions). On 6 May 2015 11:06:24 pm AEST, "Nicholls, Mark" wrote: >lets try it the other way around > >> instance Foo' SNat1 where >> type Bar' SNat1 = Z1 >> bar' = SZ1 > >that works! > >(my language will be wrong here...but the jist is) > >So in some something of kind >"*->*" is substitutable for a parameter of kind "k -> *" >"Nat->*" is substitutable for a parameter of kind "k -> *" >"*->*" is substitutable for a parameter of kind "* -> *" >"Nat->*" is NOT substitutable for a parameter of kind "* -> *" > >Hmmmm > >So why would I ever want to define a type class of kind >(* -> *) -> Constraint >Instead of >(k -> *) -> Constraint > >? > >I think I don't completely understand what's going on. > >From: Nicholls, Mark >Sent: 06 May 2015 1:02 PM >To: haskell-cafe at haskell.org >Subject: minor confusion over kinds.... > >And what "*" means as opposed to other things e.g. an explicit name >"Nat" or a kind variable "k" > >> {-# LANGUAGE DataKinds #-} >> {-# LANGUAGE ExplicitForAll #-} >> {-# LANGUAGE FlexibleContexts #-} >> {-# LANGUAGE FlexibleInstances #-} >> {-# LANGUAGE GADTs #-} >> {-# LANGUAGE MultiParamTypeClasses #-} >> {-# LANGUAGE PolyKinds #-} >> {-# LANGUAGE StandaloneDeriving #-} >> {-# LANGUAGE TypeFamilies #-} >> {-# LANGUAGE TypeOperators #-} >> {-# LANGUAGE UndecidableInstances #-} > >what I want is a typeclass with instances of type level Naturals > >here's the class, the parameter is of kind (* -> *) i.e. a is some sort >of wrapper that maps from types to values > >> class Foo (a :: * -> *) where >> type Bar a >> bar :: a (Bar a) > > >lets ignore DataKinds define Zero and Succ as distinct types > >uninhabited...but of kind "*" and "k -> *" > >> data Z1 >> data S1 nat > >SNat1 :: * -> * > >> data SNat1 a where >> SZ1 :: SNat1 Z1 >> SS1 :: SNat1 a -> SNat1 (S1 a) > >off we go... > >> instance Foo SNat1 where >> type Bar SNat1 = Z1 >> bar = SZ1 > > >now lets do it the datakind route > >> data Nat where >> Z :: Nat >> S :: Nat -> Nat > >ahhh...SNat is of kind "Nat -> *" > >> data SNat a where >> SZ :: SNat 'Z >> SS :: SNat a -> SNat ('S a) > >so I cant make it an instance of the same type class > >"The first argument of 'Foo' should have kind '* -> *', > but 'SNat' has kind 'Nat -> *' > In the instance declaration for 'Foo SNat'" > > >> --instance Foo SNat where >> -- type Bar SNat = 'Z >> -- bar = SZ > >unless I redefine my class (which seems a bit silly) > >> class Foo' (a :: k -> *) where >> type Bar' a :: k >> bar' :: a (Bar' a) > >now it works. > >> instance Foo' SNat where >> type Bar' SNat = 'Z >> bar' = SZ > >clearly named kinds (?) are somehow distinct from unnames ones? >CONFIDENTIALITY NOTICE > >This e-mail (and any attached files) is confidential and protected by >copyright (and other intellectual property rights). If you are not the >intended recipient please e-mail the sender and then delete the email >and any attached files immediately. Any further use or dissemination is >prohibited. > >While MTV Networks Europe has taken steps to ensure that this email and >any attachments are virus free, it is your responsibility to ensure >that this message and any attachments are virus free and do not affect >your systems / data. > >Communicating by email is not 100% secure and carries risks such as >delay, data corruption, non-delivery, wrongful interception and >unauthorised amendment. If you communicate with us by e-mail, you >acknowledge and assume these risks, and you agree to take appropriate >measures to minimise these risks when e-mailing us. > >MTV Networks International, MTV Networks UK & Ireland, Greenhouse, >Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions >International, Be Viacom, Viacom International Media Networks and VIMN >and Comedy Central are all trading names of MTV Networks Europe. MTV >Networks Europe is a partnership between MTV Networks Europe Inc. and >Viacom Networks Europe Inc. Address for service in Great Britain is >17-29 Hawley Crescent, London, NW1 8TT. > > >------------------------------------------------------------------------ > >_______________________________________________ >Haskell-Cafe mailing list >Haskell-Cafe at haskell.org >http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From svenpanne at gmail.com Wed May 6 21:07:42 2015 From: svenpanne at gmail.com (Sven Panne) Date: Wed, 6 May 2015 23:07:42 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554A7716.30008@htwk-leipzig.de> References: <554A7716.30008@htwk-leipzig.de> Message-ID: 2015-05-06 22:18 GMT+02:00 Johannes Waldmann : > There is maybe another option: do what csharp does. > > Define a reduced "preprocessor" (for conditional compilation, > but without macro expansion) as part of the language. > (cf. https://msdn.microsoft.com/en-us/library/ed8yd1ha.aspx ) I'd like to repeat that this is *not* a full solution IMHO, everybody doing cross-platform FFI bindings needs macro expansion to handle the differences in calling conventions. Of course this can be done by duplicating all "foreign imports" etc. for every calling convention involved, but this is not really a solution to actual needs. > They must have have had good reasons for doing it this way. "Doing things differently" has always been a tradition for certain companies... ;-) More seriously: We don't want to break hundreds of packages on Hackage, the only thing we really need is a well-defined CPP-like preprocessor, so integrating e.g. cpphs somehow seems to be the right way IMHO. If it's not cpphs, I wouldn't mind, the main point is that it's the same on all platforms and handles basically *all* things CPP can. TH is nice, but I'm not sure if it can handle 100% of the CPP use cases, and remember: There are Haskell implementations out there which don't support TH. From asr at eafit.edu.co Wed May 6 21:47:50 2015 From: asr at eafit.edu.co (=?UTF-8?B?QW5kcsOpcyBTaWNhcmQtUmFtw61yZXo=?=) Date: Wed, 6 May 2015 16:47:50 -0500 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <201505062155.56858.jan.stolarek@p.lodz.pl> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <201505062155.56858.jan.stolarek@p.lodz.pl> Message-ID: Hi Janek, On 6 May 2015 at 14:55, Jan Stolarek wrote: > Yes, and that's what gets me worried. I suppose the problem was somehow related to my locale > settings although we were unable to track down the cause. I also recall someone else reported > being affected by the same problem. AFIK, the only cpphs-Agda open problem is your problem. I would like to know if anyone else has some problem. If so, I propose to move the discussion to the Agda developers list (agda-dev at lists.chalmers.se). Best, -- Andr?s From nicola.gigante at gmail.com Thu May 7 06:42:52 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Thu, 7 May 2015 08:42:52 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <554A7716.30008@htwk-leipzig.de> Message-ID: Il giorno 06/mag/2015, alle ore 23:07, Sven Panne ha scritto: > > More seriously: We don't want to break hundreds of packages on > Hackage, the only thing we really need is a well-defined CPP-like > preprocessor, so integrating e.g. cpphs somehow seems to be the right > way IMHO. If it's not cpphs, I wouldn't mind, the main point is that > it's the same on all platforms and handles basically *all* things CPP > can. > Hi all, I'm following the discussion from the outside but I'm wondering if you have considered the following idea. From what I understand the current problem with using the system's cpp is inconsistency between different compilers, is it? Then why don't you _import_ the clang's preprocessor into GHC source tree and use that? As you probably know clang is not only a compiler, but a set of libraries to handle C/C++ code. AFAIK linking only the lexer module (which is responsible for the preprocessor) and its direct dependencies, which at the end amount to libLLVMCore and the C++ standard library, shouldn't be too much size overhead (ymmv). The license is also ok, since it's a BSD-something. To also address the issue of how the preprocessor handles Haskell tokens in macros, if you import the source someone could make a patch to add an option to make the preprocessor less strict (but I'm sure to have seen already something to opt for a lax semantics when the preprocessor is used standalone, need to check that). If done well and promised to be maintained, I think the patch could also be accepted mainstream (it's not the first time an LLVM project accepts GHC specific patches, see the support for its call convention in the code generator). Greetings, Nicola From hvriedel at gmail.com Thu May 7 07:38:02 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 07 May 2015 09:38:02 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: (Nicola Gigante's message of "Thu, 7 May 2015 08:42:52 +0200") References: <554A7716.30008@htwk-leipzig.de> Message-ID: <87wq0k96sl.fsf@gnu.org> On 2015-05-07 at 08:42:52 +0200, Nicola Gigante wrote: [...] >> More seriously: We don't want to break hundreds of packages on >> Hackage [...] > I'm following the discussion from the outside but I'm wondering if you have considered the following idea. > > From what I understand the current problem with using the > system's cpp is inconsistency between different compilers, is > it? Yes... and historically, large amounts of *existing* code on Hackage were written against GCC cpp's traditional-mode, and when Apple pushed a large amount of users/developers to use the Clang toolchain, packages started becoming compatible w/ Clang's cpp (and for the record, Clang-cpp's lack of a "proper" traditional-mode has not only caused problems for GHC, see e.g. https://wiki.freebsd.org/PortsAndClang/CppIssues) > Then why don't you _import_ the clang's preprocessor into > GHC source tree and use that? That's an interesting thought. I've added your suggestion to the wiki proposal-page as a sub-variant of "plan 1" (or does it rather constitute a new plan of its own?) However, without effectively convincing clang's cpp implementation to emulate more of gcc's -traditional mode, this would most likely break old package versions available on Hackage that still work perfectly fine now w/ gcc-cpp (but not clang-cpp), as clang-cpp divergence from gcc-cpp (which was till then the defacto-standard for how -XCPP was expected to behave) is the reason we're having this discussion now in the first place. > As you probably know clang is not only a compiler, but a set of > libraries to handle C/C++ code. AFAIK linking only the lexer module > (which is responsible for the preprocessor) and its direct > dependencies, which at the end amount to libLLVMCore and the C++ > standard library, shouldn't be too much size overhead (ymmv). The > license is also ok, since it's a BSD-something. > > To also address the issue of how the preprocessor handles > Haskell tokens in macros, if you import the source someone > could make a patch to add an option to make the > preprocessor less strict (but I'm sure to have seen already > something to opt for a lax semantics when the preprocessor is > used standalone, need to check that). If done well and > promised to be maintained, I think the patch could also be > accepted mainstream (it's not the first time an LLVM project > accepts GHC specific patches, see the support for its call > convention in the code generator). Personally, I'm much more motivated to work on improving Haskell-code than to maintain a 3rd party C/C++-based preprocessor component. So I'm afraid that unless we find this "someone" who is willing to provide the willpower and time to bend Clang's preprocessor library to GHC's needs (which foremost would mean to maximize compatibility w/ *existing* code on Hackage using -XCPP, assuming that's a good heuristic for also maximizing compatibility w/ code *not* on Hackage) And judging from past discussions such as http://comments.gmane.org/gmane.comp.compilers.clang.scm/67381 I'm skeptical that Clang's cpp (whose token-based parsing seems to be in conflict with character-based parsing which is more suited for traditional-mode non-C semantics) Cheers, hvr From hvriedel at gmail.com Thu May 7 07:47:20 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Thu, 07 May 2015 09:47:20 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> (Howard B. Golden's message of "Wed, 6 May 2015 16:53:08 +0000 (UTC)") References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> Message-ID: <87sib896d3.fsf@gnu.org> On 2015-05-06 at 18:53:08 +0200, Howard B. Golden wrote: > At the risk of antagonizing some (most? all?) of you, how about... > > -XCPP stands for the native CPP > -XGNUCPP stands for GNU's GCC CPP > -XClangCPP stands for Clang's CPP > -XCPPHS stands for CPPHS Assuming this was a serious suggestion, the benefit is that you could clearly mark what CPP you want to develop against, but OTOH, we'd lose backward compat w/ Haskell compilers only knowing about the old -XCPP but not the other new variants of the language-pragma. Moreover, there can now be packages that require clang-cpp, while others require gcc-cpp, and I don't think it can be assumed that both are available on every GHC installation. So it could cause packages to fail compiling simply because the respective CPP-flavor is missing. On the bright side, this would maybe give us the opportunity to coin the new term "CPP Hell" =) Cheers, hvr From voldermort at hotmail.com Thu May 7 09:45:17 2015 From: voldermort at hotmail.com (Harry .) Date: Thu, 7 May 2015 09:45:17 +0000 Subject: [Haskell-cafe] release timing In-Reply-To: <45ee4958d71043a5ae35e046f1cdb527@DB4PR30MB030.064d.mgd.msft.net> References: , <45ee4958d71043a5ae35e046f1cdb527@DB4PR30MB030.064d.mgd.msft.net> Message-ID: Simon PJ wrote ... > > | It would be nice to see #8224 in as well, but doesn't look like that's > | going to be fixed any time soon! Have GHC HQ ever considered asking > | Intel if they'd be willing to lend a hand? > > What makes you think that Intel would help with #8224? (It's about the IO manager.) The title is about the IO manager :-) The diagnosis ends with performance issues that appear tied to CPU design, something that Intel ought to know something about. > Also, GHC is an open source project. You don't have to wait for GHC HQ to do anything --- please go ahead and ask anyone you think could help! While it's not unheard of for a corporation to assist an open source project, particularly with issues specific to their products, the request would have a lot more credibility if it came from GHC HQ than a random GHC user. I also have no idea who in Intel should be contacted for such things. But in the spirit of your suggestion I'm cross-posting this to haskell-cafe to reach a wider audience. Does anyone out there know of a contact in Intel who might be able/willing to help with CPU performance issues? From alexander.vershilov at gmail.com Thu May 7 12:20:44 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Thu, 7 May 2015 15:20:44 +0300 Subject: [Haskell-cafe] MVars and locks In-Reply-To: <20150506191904.GC19164@weber> References: <20150506191904.GC19164@weber> Message-ID: One of the good ways of thinking about MVars is to think about it either like lock with value, or channel with one position. And divide API into two parts. In former case use operations: withMVar, modifyMVar, swapMVar, readMVar (ghc>=7.8). This could be used for locking or keeping mutable shared state. In latter: takeMVar, putMVar, readMVar. This could be used for message communication. In any of this case you are safe from the situations mentioned above, however if you use both, then you are in the grey area, and have to consider all scenarios. About your question: yes another process could put value inside MVar and your process will be locked unless somebody will read a value. -- Alexander On 6 May 2015 at 22:19, Tom Ellis wrote: > In the following section of the book "Parallel and Concurrent Programming in > Haskell" > > http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook > > Simon Marlow explains that MVars can be used to implement something like > locks on shared functional state: "To acquire the lock, we take the MVar, > whereas, to update the variable and release the lock, we put the MVar." > > Am I right in thinking this only holds if we are careful to ensure both > those operations happen in the given order? > > For example, if I take the MVar (lock) and I am about to put something back > in (unlock) but someone else puts something in before I do, then the lock > system becomes broken, doesn't it? So if we want to be sure we have a > robust lock system we have to wrap up MVars in another abstraction? > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Alexander From takenobu.hs at gmail.com Thu May 7 12:53:13 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Thu, 7 May 2015 21:53:13 +0900 Subject: [Haskell-cafe] MVars and locks In-Reply-To: <20150506191904.GC19164@weber> References: <20150506191904.GC19164@weber> Message-ID: Hi Tom, Additional information. MVar is low cost, fast and fairness operation. It's fantastic! Although MVar is delicate about "order" including sync and async exceptions. "order" means two levels. One is single MVar's order (putMVar, takeMVar). The other is inter-MVars order, such as the dining philosophers problem. If you need robust systems more than performance critical systems. It's better to use STM(TVar). TVar is almost order free. It's amazing:-) So here is few related illustration:) "MVar" section http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf Enjoy, Takenobu 2015-05-07 4:19 GMT+09:00 Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk>: > In the following section of the book "Parallel and Concurrent Programming > in > Haskell" > > > http://chimera.labs.oreilly.com/books/1230000000929/ch07.html#sec_conc-phonebook > > Simon Marlow explains that MVars can be used to implement something like > locks on shared functional state: "To acquire the lock, we take the MVar, > whereas, to update the variable and release the lock, we put the MVar." > > Am I right in thinking this only holds if we are careful to ensure both > those operations happen in the given order? > > For example, if I take the MVar (lock) and I am about to put something back > in (unlock) but someone else puts something in before I do, then the lock > system becomes broken, doesn't it? So if we want to be sure we have a > robust lock system we have to wrap up MVars in another abstraction? > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From onepoint at starurchin.org Thu May 7 13:30:00 2015 From: onepoint at starurchin.org (Jeremy Henty) Date: Thu, 7 May 2015 14:30:00 +0100 Subject: [Haskell-cafe] Cannot run GHC-7.10.1 tests In-Reply-To: <20150430213310.GB3723@omphalos.singularity> References: <20150428214821.GE13478@omphalos.singularity> <20150429194157.GA3723@omphalos.singularity> <201504301255.26306.bh@intevation.de> <20150430213310.GB3723@omphalos.singularity> Message-ID: <20150507133000.GA10177@omphalos.singularity> Jeremy Henty (ie. me) wrote: > > Bernhard Herzog wrote: > > On 29.04.2015, Jeremy Henty wrote: > > > But since you suggested it, I tried running all the test commands from > > > within the ghc-7.10.1/testsuite directory and they all failed as > > > follows: > > > > > > mk/boilerplate.mk:168: mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk: No such file or directory > > > ./mk/ghc-config "/data/build.d/6.8/ghc-7.10.1/inplace/bin/ghc-stage2" > > > >"mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk"; if [ $? != 0 ]; then > > rm -f "mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk"; exit 1; fi > > > /bin/sh: ./mk/ghc-config: cannot execute binary file > > > make: *** [mk/ghcconfig_data_build.d_6.8_ghc-7.10.1_inplace_bin_ghc-stage2.mk] Error 1 > > > > > > Just tried this myself. I get very similar errors. The reason is, > > AFAICT, that the testsuite tarball contains some build-artifacts, > > particularly some binaries. A "make clean" in the testsuite > > directory before running the tests helps. > > Thanks, that worked! I get a few unexpected failures from "make > fast". Should I be concerned? *cough* *bump* Any thoughts on this? The wiki suggested that I should expect no errors from "make fast" so this is a little surprising. Should I install regardless or investigate further? (There were 11 errors which is a pretty small fraction of the total.) Regards, Jeremy Henty From felipe.lessa at gmail.com Thu May 7 14:15:49 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 07 May 2015 11:15:49 -0300 Subject: [Haskell-cafe] MVars and locks In-Reply-To: References: <20150506191904.GC19164@weber> Message-ID: <554B7395.50209@gmail.com> On 07-05-2015 09:53, Takenobu Tani wrote: > So here is few related illustration:) > "MVar" section > http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf Great slides, thanks for sharing! :) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From hvr at gnu.org Thu May 7 19:54:51 2015 From: hvr at gnu.org (Herbert Valerio Riedel) Date: Thu, 07 May 2015 21:54:51 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <201505061338.16090.jan.stolarek@p.lodz.pl> (Jan Stolarek's message of "Wed, 6 May 2015 13:38:16 +0200") References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> Message-ID: <87h9ro5fjo.fsf@gnu.org> On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: [...] > Regarding licensing issues: perhaps we should simply ask Malcolm > Wallace if he would consider changing the license for the sake of GHC? > Or perhaps he could grant a custom-tailored license to the GHC > project? After all, the project page [1] says: " If that's a problem > for you, contact me to make other arrangements." Fyi, Neil talked to him[1]: | I talked to Malcolm. His contention is that it doesn't actually change | the license of the ghc package. As such, it's just a single extra | license to add to a directory full of licenses, which is no big deal. [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 From malcolm.wallace at me.com Thu May 7 20:41:22 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Thu, 07 May 2015 21:41:22 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87h9ro5fjo.fsf@gnu.org> References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> Message-ID: I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. Regards, Malcolm On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > [...] > >> Regarding licensing issues: perhaps we should simply ask Malcolm >> Wallace if he would consider changing the license for the sake of GHC? >> Or perhaps he could grant a custom-tailored license to the GHC >> project? After all, the project page [1] says: " If that's a problem >> for you, contact me to make other arrangements." > > Fyi, Neil talked to him[1]: > > | I talked to Malcolm. His contention is that it doesn't actually change > | the license of the ghc package. As such, it's just a single extra > | license to add to a directory full of licenses, which is no big deal. > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 From bertram.felgenhauer at googlemail.com Thu May 7 21:12:08 2015 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Thu, 7 May 2015 23:12:08 +0200 Subject: [Haskell-cafe] ANN: Important lambabot update (5.0.2.1 release) In-Reply-To: <20150503142754.GB1771@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> References: <20150503142754.GB1771@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Message-ID: <20150507211208.GA30594@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Hi, > Generally, lambdabot relies on SafeHaskell and not running user-supplied > IO actions for safety. This is unlikely to be bullet-proof, so it's > advisable to sandbox mueval. However, the @check command violated this > basic principle, and allowed running arbitrary IO actions. This was deliberately vague. The point is that @check took an arbitrary value of type Property, and ran it. That type is based on IO, and there are actually direct ways of incorporating an IO action into a Property: * ioProperty (alias morallyDubiousIOProperty) * whenFail, whenFail' In the end, rather than trying to control whether these functions are imported (which would be a fool's errand, because Test.QuickCheck is a Safe module, and can be reexported from other modules), I came up with the QuickCheck-safe design whose SProperty type does not embed IO anywhere. Cheers, Bertram From tomas.carnecky at gmail.com Thu May 7 21:15:47 2015 From: tomas.carnecky at gmail.com (Tomas Carnecky) Date: Thu, 7 May 2015 23:15:47 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> Message-ID: That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: > I also note that in this discussion, so far not a single person has said > that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: > http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ok at cs.otago.ac.nz Thu May 7 23:06:30 2015 From: ok at cs.otago.ac.nz (Richard A. O'Keefe) Date: Fri, 8 May 2015 11:06:30 +1200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87sib896d3.fsf@gnu.org> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> Message-ID: <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> This is *so* reminiscent of why fpp exists. (http://www.netlib.org/fortran/fdfpp.tgz) People used to use cpp with Fortran, but it really didn't fit Fortran lexical structure very well, and cpps were different. So... I think it's important that there be *one* "cpp" used by Haskell. fpp is under 4 kSLOC of C, and surely Haskell can do a lot better. From semen at trygub.com Thu May 7 23:29:26 2015 From: semen at trygub.com (Semen Trygubenko / =?utf-8?B?0KHQtdC80LXQvSDQotGA0LjQs9GD0LHQtdC9?= =?utf-8?B?0LrQvg==?=) Date: Fri, 8 May 2015 00:29:26 +0100 Subject: [Haskell-cafe] Haskell Weekly News: Issue 328 In-Reply-To: <20150423225841.GA8001@inanna.trygub.com> References: <20150326222444.GA91822@inanna.trygub.com> <20150409225936.GA1070@inanna.trygub.com> <20150423225841.GA8001@inanna.trygub.com> Message-ID: <20150507232926.GA3288@inanna.trygub.com> Calls for Participation School of Haskell 2.0 Open-source version of School of Haskell is going to be released soon! Michael Sloan explains that the aim is to remove any obstacles that historically discouraged people from contributing to School of Haskell through making it open-source, Creative-Commons-licensed and GitHub-hosted and more usable by allowing websites to include editable and runnable Haskell code with ease. He outlines the plans for the editor and markdown rendering services and asks for feedback and more ideas. https://www.fpcomplete.com/blog/2015/05/school-of-haskell-2 http://www.reddit.com/r/haskell/comments/34uc8y/school_of_haskell_20/ Talks Functional Programming @ Amplidata Koen De Keyser gave a talk about Amplidata and their introduction of OCaml as an alternative to Python/C++ in 2010 and transition from OCaml to Haskell in 2014. He argues that going strongly-typed and functional meant moving bugs from test/run time to compile time, gaining expressiveness and reducing boiler-plate, and switching to Haskell meant joining larger community, gaining access to commercial support, adding multi-threaded runtime / garbage collector and enforcing separation of side effects from pure functions (though ramp-up time was significant and "tools are nowhere near Java / .NET / C++ level"). http://people.cs.kuleuven.be/~tom.schrijvers/Research/talks/lhug4b.pdf Discussion People using Haskell in production: what is your build/deployment setup? Jameshfisher asks a number of build/deployment questions on Reddit, as he is starting a "real" Haskell project. Community responses suggest that deploying Haskell is no different from deploying anything else. Haskell-specific parts frequently feature Cabal, Stackage and Shake. http://www.reddit.com/r/haskell/comments/34m4bq/people_using_haskell_in_production_what_is_your/ How to Replace Failure by a Heap of Successes Edward Kmett writes a blog post on writing parsing combinators. He explains gains and losses of switching from State monad to Update monad in parsers, and argues that limited structure of updates can be exploited to yield a more efficient Applicative for parsing and help unclutter parser implementation through better handling of the issue of parse leftovers. https://www.fpcomplete.com/user/edwardk/heap-of-successes http://www.reddit.com/r/haskell/comments/34kouv/edward_kmett_how_to_replace_failure_by_a_heap_of/ Smarter validation Roman Cheplyaka explores different ways of handling and communicating errors in Haskell ? Either Monad, Validation Applicative, and SmartValidation Applicative. Either halts on first error, Validation Applicative reports all errors, whereas SmartValidation applicative reports first N errors and stops doing work when N errors were gathered. Roman wants to hear how other people are approaching "first N errors" problem. https://ro-che.info/articles/2015-05-02-smarter-validation Haskell Web Server in a 5MB Docker Image Tim Dysinger solves the problem of redirection of all Amazon Elastic Load Balancer HTTP traffic to HTTPS in Haskell, in one hour and 97 lines of code, and produces a 1.22 MB exe. He argues that Haskell's performance can compete with natively compiled systems languages like Go, Rust and even hand-written C, and that Haskell allows to communicate intent in code with precision. https://www.fpcomplete.com/blog/2015/05/haskell-web-server-in-5mb https://github.com/fpco/rdr2tls Quotes of the Week "I like safePerformIO = Just . don't" (sinelaw) http://www.reddit.com/r/haskell/comments/34kl93/just_stumbled_on_to_the_acmeeverything_library/cqwrxfm "Interactive Haddocks sounds like a dream." (NihilistDandy) http://www.reddit.com/r/haskell/comments/34uc8y/school_of_haskell_20/cqy8sau "Being able to have runnable code on standalone blogs is huge!" (roche) http://www.reddit.com/r/haskell/comments/34uc8y/school_of_haskell_20/cqyab7z "If you want to have a type system related heart attack, the acme-stringly-typed library provides it." (tsahyt) http://www.reddit.com/r/haskell/comments/34kl93/just_stumbled_on_to_the_acmeeverything_library/cqvv9td https://hackage.haskell.org/package/acme-stringly-typed -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From ben at groovie.org Fri May 8 00:12:42 2015 From: ben at groovie.org (Ben Bangert) Date: Thu, 7 May 2015 17:12:42 -0700 Subject: [Haskell-cafe] Efficient memory use for tens of thousands of connections Message-ID: I'm currently evaluating memory overhead for a variety of simple Websocket based echo server to get a gauge of minimal memory penalty per connection along with SSL overhead per connection. I've created two websocket servers in Haskell: https://github.com/bbangert/ssl-ram-testing/tree/master/Haskell One using Yesod + jaspers Websockets lib, the other with Yesod + Mishael Snoyman's native websocket lib. I was curious what options I might be missing that would ensure a more efficient use of memory, at the moment the non-SSL seems to use about 48kb per connection, while using Haskell's TLS via warp-tls introduces a huge amount of overhead (along with odd handshake issues). Here's what my results look like: No SSL Program started. Tester started. Tester finished connecting. Waiting: 360 Last Memory Increase: 2 WARNING: Program hasn't stopped increasing. Started with: 2633728 Ended with: 50896896 kB per connection: 47.13 SSL Program started. Tester started. yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record mac",True,BadRecordMac)) WARNING: Failed to connect all clients Tester finished connecting. Waiting: 360 Last Memory Increase: 4 WARNING: Program hasn't stopped increasing. Started with: 3170304 Ended with: 454221824 kB per connection: 444.03 SSL Overhead per Conn: 396.90 I wait up to 6 minutes for memory to level out, it never does with or without SSL. Is this expected behavior? If not, what options am I missing? The ssl-ram-testing repo includes full directions on how to reproduce this and run this test. Cheers, Ben -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at groovie.org Fri May 8 00:15:32 2015 From: ben at groovie.org (Ben Bangert) Date: Thu, 7 May 2015 17:15:32 -0700 Subject: [Haskell-cafe] Efficient memory use for tens of thousands of connections In-Reply-To: References: Message-ID: Forgot to clarify, I setup both projects with cabal using GHC 7.10 with Stackage nightly from 5/6/15 (per the README's), running under Ubuntu 14.04. On Thu, May 7, 2015 at 5:12 PM, Ben Bangert wrote: > I'm currently evaluating memory overhead for a variety of simple Websocket > based echo server to get a gauge of minimal memory penalty per connection > along with SSL overhead per connection. > > I've created two websocket servers in Haskell: > https://github.com/bbangert/ssl-ram-testing/tree/master/Haskell > > One using Yesod + jaspers Websockets lib, the other with Yesod + Mishael > Snoyman's native websocket lib. I was curious what options I might be > missing that would ensure a more efficient use of memory, at the moment the > non-SSL seems to use about 48kb per connection, while using Haskell's TLS > via warp-tls introduces a huge amount of overhead (along with odd handshake > issues). > > Here's what my results look like: > No SSL > Program started. > Tester started. > Tester finished connecting. > Waiting: 360 Last Memory Increase: 2 > WARNING: Program hasn't stopped increasing. > Started with: 2633728 > Ended with: 50896896 > kB per connection: 47.13 > > > SSL > Program started. > Tester started. > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > yesod-customws-tls: HandshakeFailed (Error_Protocol ("bad record > mac",True,BadRecordMac)) > WARNING: Failed to connect all clients > Tester finished connecting. > Waiting: 360 Last Memory Increase: 4 > WARNING: Program hasn't stopped increasing. > Started with: 3170304 > Ended with: 454221824 > kB per connection: 444.03 > > SSL Overhead per Conn: 396.90 > > I wait up to 6 minutes for memory to level out, it never does with or > without SSL. Is this expected behavior? If not, what options am I missing? > > The ssl-ram-testing repo includes full directions on how to reproduce this > and run this test. > > Cheers, > Ben > -------------- next part -------------- An HTML attachment was scrubbed... URL: From winterkoninkje at gmail.com Fri May 8 03:45:48 2015 From: winterkoninkje at gmail.com (wren romano) Date: Thu, 7 May 2015 23:45:48 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Wed, May 6, 2015 at 9:05 AM, Alan & Kim Zimmerman wrote: > Perhaps it makes sense to scan hackage to find all the different CPP idioms > that are actually used in Haskell code, if it is a small/well-defined set it > may be worth writing a simple custom preprocessor. Conditional imports are far and away the most commonly used idiom. Second most common, I'd say, is specifying GHC-specific vs compiler-generic implementations of top-level functions (e.g., using GHC.Exts.build or not). For both of these it's sufficient to have the #if construction plus everything needed for the conditional expressions. However, while the #if construction covers the vast majority of use cases, it doesn't cover all of them. Macros are also important. For example, a number of low-level libraries will use macros for things like having assertions which are either compiled as runtime checks, or as nothing, depending on a Cabal flag. Of course, there are plenty of other places where we want to use macros in low-level code, either to force inlining, or to have conditional compilation of (non-top-level) expressions that show up over and over. That these idioms aren't more common is just because there aren't more people working on such low-level code. In theory TH should be able to handle this stuff, but TH is a verbose sledgehammer for these sorts of problems, and using TH means restricting yourself to being GHC-only. -- Live well, ~wren From fumiexcel at gmail.com Fri May 8 05:33:37 2015 From: fumiexcel at gmail.com (Fumiaki Kinoshita) Date: Fri, 8 May 2015 14:33:37 +0900 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: Message-ID: Except the performance, my extensible[0] library provides native lens support (label names are also lenses!) and quite easy to use. Let me show an example: {-# LANGUAGE TypeOperators, DataKinds, TemplateHaskell, FlexibleContexts #-} import Data.Extensible import Control.Lens import Control.Monad.State mkField "foo bar baz" statefulStuff :: State (Record '["foo" :> Int, "bar" :> Int, "baz" :> Float]) () statefulStuff = do v <- use foo bar += v baz .= 42 main = print $ execState statefulStuff $ foo @= 10 <: bar @= 0 <: baz @= 0 <: Nil I could use Vector Any internally for O(1) lookup, but seems trade-off between lookup and update. 2015-05-05 18:40 GMT+09:00 Alberto G. Corona : > Hi, > > Anyone used some of the extensible record packages to create a kind of > extensible state monad? > > I mean something that besides having "get", "gets" and "put" would have > some kind of "add" and "gets": > > add :: a -> State () > gets :: State (Maybe a) > > or > > add :: LabelName -> a -> State () > gets :: LabelName -> State (Maybe a) > > > So that I can extend the state without using additional monad > transformers. Monad transformers are very hard for beginners and scramble > error messages > > I did the first option for MFlow, hplayground and Transient packages > (setSData and getSData). But my solution uses a map indexed by type and > this requires a lookup for each access. > > I would like to know if there is an alternative with no lookups. I?m not > obsessed with speed but In some applications the speed may be important.... > > Anyone? > -- > Alberto. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From malcolm.wallace at me.com Fri May 8 06:07:56 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 08 May 2015 07:07:56 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> Message-ID: <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> On 8 May 2015, at 00:06, Richard A. O'Keefe wrote: > I think it's important that there be *one* > "cpp" used by Haskell. fpp is under 4 kSLOC > of C, and surely Haskell can do a lot better. FWIW, cpphs is about 1600 LoC today. Regards, Malcolm From malcolm.wallace at me.com Fri May 8 06:10:22 2015 From: malcolm.wallace at me.com (Malcolm Wallace) Date: Fri, 08 May 2015 07:10:22 +0100 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <201505061338.16090.jan.stolarek@p.lodz.pl> <87h9ro5fjo.fsf@gnu.org> Message-ID: <567D3794-E088-45A1-8687-A877D47F59C1@me.com> Exactly. My post was an attempt to elicit response from anyone to whom it matters. There is no point in worrying about hypothetical licensing problems - let's hear about the real ones. Regards, Malcolm On 7 May 2015, at 22:15, Tomas Carnecky wrote: > That doesn't mean those people don't exist. Maybe they do but are too afraid to speak up (due to corporate policy or whatever). > > On Thu, May 7, 2015 at 10:41 PM, Malcolm Wallace wrote: > I also note that in this discussion, so far not a single person has said that the cpphs licence would actually be a problem for them. > > Regards, > Malcolm > > On 7 May 2015, at 20:54, Herbert Valerio Riedel wrote: > > > On 2015-05-06 at 13:38:16 +0200, Jan Stolarek wrote: > > > > [...] > > > >> Regarding licensing issues: perhaps we should simply ask Malcolm > >> Wallace if he would consider changing the license for the sake of GHC? > >> Or perhaps he could grant a custom-tailored license to the GHC > >> project? After all, the project page [1] says: " If that's a problem > >> for you, contact me to make other arrangements." > > > > Fyi, Neil talked to him[1]: > > > > | I talked to Malcolm. His contention is that it doesn't actually change > > | the license of the ghc package. As such, it's just a single extra > > | license to add to a directory full of licenses, which is no big deal. > > > > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1e5n3 > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From mail at joachim-breitner.de Fri May 8 08:07:53 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 08 May 2015 10:07:53 +0200 Subject: [Haskell-cafe] status of deb.haskell.org? In-Reply-To: <1428423317104-5768430.post@n5.nabble.com> References: <1428423317104-5768430.post@n5.nabble.com> Message-ID: <1431072473.1853.7.camel@joachim-breitner.de> Hi Jeremy Am Dienstag, den 07.04.2015, 09:15 -0700 schrieb Jeremy: > The haskell status page says that deb.haskell.org has been down since > mid-February. Are there any plans to bring it back up? I?ve suggested to can this service, for its usefulness-to-effort-ratio wasn?t very good. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From hvriedel at gmail.com Fri May 8 09:02:09 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 08 May 2015 11:02:09 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554C6AD6.2090103@jacobs-university.de> (Christian Maeder's message of "Fri, 8 May 2015 09:50:46 +0200") References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> Message-ID: <87zj5f1lym.fsf@gmail.com> Hello Christian, (I've re-CC'ed haskell-cafe, assuming this wasn't deliberate) On 2015-05-08 at 09:50:46 +0200, Christian Maeder wrote: > using cpphs is the right way to go! > > Rewriting it from scratch may be a good exercise but is (essentially) a > waste of time. > > However, always asking Malcolm to get source changes into cpphs would > be annoying. > > Therefore it would be great if the sources were just part of the ghc > sources (under git). > > Another "problem" might be the dependency "polyparse" that is currently > not part of the core libraries. A scheme was actually discussed privately to address this: We certainly don't want to expose cpphs/polyparse (and text!) as new packages in GHC's global pkg-db. Which we'd end up, if we handled cpphs as the other exposed boot libraries. Therefore we'd only use the few relevant modules from cpphs/polyparse as "other-modules" (i.e. internal hidden dependencies -- i.e. we wouldn't use cpphs/polyparse's .cabal files) compiled into GHC, but not exposed. We'd either create a new Git submodule to hold our "fork" of cpphs/polyparse, or just add it somewhere inside ghc.git > (I guess that replacing polyparse by something else would also be a nice > exercise.) > > So (for me) the only question is, if Malcolm is willing to transfer > control over cpphs to the haskell-community (or ghc head) - of course > with due acknowledgements! I don't think this will be necessary, as we don't need the cpphs-upstream to mirror each modifications immediately. The benefit of the scheme described above is that we'd be somewhat decoupled from cpphs' upstream, and can freely experiment in our "fork", and can sync up with Malcolm from time to time to merge improvements in both directions. -- hvr From andrew at operationaldynamics.com Fri May 8 09:19:04 2015 From: andrew at operationaldynamics.com (Andrew Cowie) Date: Fri, 08 May 2015 09:19:04 +0000 Subject: [Haskell-cafe] status of deb.haskell.org? In-Reply-To: <1431072473.1853.7.camel@joachim-breitner.de> References: <1428423317104-5768430.post@n5.nabble.com> <1431072473.1853.7.camel@joachim-breitner.de> Message-ID: That's a shame. Do you have a recommendation for where people should source up to date GHC packages for Debian from? AfC On Fri, 8 May 2015 18:07 Joachim Breitner wrote: I?ve suggested to can this service, for its usefulness-to-effort-ratio wasn?t very good. -------------- next part -------------- An HTML attachment was scrubbed... URL: From metaniklas at gmail.com Fri May 8 09:28:08 2015 From: metaniklas at gmail.com (Niklas Larsson) Date: Fri, 8 May 2015 11:28:08 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87zj5f1lym.fsf@gmail.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> Message-ID: <554c81a6.021d980a.468e.72fd@mx.google.com> If the intention is to use cpphs as a library, won't the license affect every program built with the GHC API? That seems to be a high price to pay. ----- Ursprungligt meddelande ----- Fr?n: "Herbert Valerio Riedel" Skickat: ?2015-?05-?08 11:02 Till: "Christian Maeder" Kopia: "Malcolm Wallace" ; "glasgow-haskell-users at haskell.org" ; "libraries at haskell.org" ; "ghc-devs at haskell.org" ; "haskell-cafe" ?mne: Re: [Haskell-cafe] RFC: "Native -XCPP" Proposal Hello Christian, (I've re-CC'ed haskell-cafe, assuming this wasn't deliberate) On 2015-05-08 at 09:50:46 +0200, Christian Maeder wrote: > using cpphs is the right way to go! > > Rewriting it from scratch may be a good exercise but is (essentially) a > waste of time. > > However, always asking Malcolm to get source changes into cpphs would > be annoying. > > Therefore it would be great if the sources were just part of the ghc > sources (under git). > > Another "problem" might be the dependency "polyparse" that is currently > not part of the core libraries. A scheme was actually discussed privately to address this: We certainly don't want to expose cpphs/polyparse (and text!) as new packages in GHC's global pkg-db. Which we'd end up, if we handled cpphs as the other exposed boot libraries. Therefore we'd only use the few relevant modules from cpphs/polyparse as "other-modules" (i.e. internal hidden dependencies -- i.e. we wouldn't use cpphs/polyparse's .cabal files) compiled into GHC, but not exposed. We'd either create a new Git submodule to hold our "fork" of cpphs/polyparse, or just add it somewhere inside ghc.git > (I guess that replacing polyparse by something else would also be a nice > exercise.) > > So (for me) the only question is, if Malcolm is willing to transfer > control over cpphs to the haskell-community (or ghc head) - of course > with due acknowledgements! I don't think this will be necessary, as we don't need the cpphs-upstream to mirror each modifications immediately. The benefit of the scheme described above is that we'd be somewhat decoupled from cpphs' upstream, and can freely experiment in our "fork", and can sync up with Malcolm from time to time to merge improvements in both directions. -- hvr _______________________________________________ ghc-devs mailing list ghc-devs at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs -------------- next part -------------- An HTML attachment was scrubbed... URL: From hvriedel at gmail.com Fri May 8 09:39:24 2015 From: hvriedel at gmail.com (Herbert Valerio Riedel) Date: Fri, 08 May 2015 11:39:24 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <554c81a6.021d980a.468e.72fd@mx.google.com> (Niklas Larsson's message of "Fri, 8 May 2015 11:28:08 +0200") References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> Message-ID: <87vbg31k8j.fsf@gmail.com> Hello, On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: > If the intention is to use cpphs as a library, won't the license > affect every program built with the GHC API? That seems to be a high > price to pay. Yes, every program linking the `ghc` package would be affected by LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: | - As a practical consequence of the //LGPL with static-linking-exception// | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** | (i.e. the LGPL+SLE covered modules) of the GHC code-base, | **then there is no requirement to ship (or make available) any source code** | together with the binaries, even if other parts of the GHC code-base | were modified. However, don't forget we already have this issue w/ integer-gmp, and with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) In that context, the suggestion was made[1] to handle the cpphs-code like the GMP code, i.e. allow a compile-time configuration in the GHC build-system to build a cpphs-free (and/or GMP-free) GHC for those parties that need to avoid any LGPL-ish code whatsoever in their toolchain. Would that address this concern? [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb From mboes at tweag.net Fri May 8 10:10:33 2015 From: mboes at tweag.net (Mathieu Boespflug) Date: Fri, 8 May 2015 12:10:33 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <87vbg31k8j.fsf@gmail.com> References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: [Gah, wrong From: email address given the list subscriptions, sorry for the duplicates.] I'm unclear why cpphs needs to be made a dependency of the GHC API and included as a lib. Could you elaborate? (in the wiki page possibly) Currently, GHC uses the system preprocessor, as a separate process. Couldn't we for GHC 7.12 keep to exactly that, save for the fact that by default GHC would call the cpphs binary for preprocessing, and have the cpphs binary be available in GHC's install dir somewhere? fork()/execvce() is cheap. Certainly cheaper than the cost of compiling a single Haskell module. Can't we keep to this separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep most license tainting concerns that way. On 8 May 2015 at 11:39, Herbert Valerio Riedel wrote: > Hello, > > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: >> If the intention is to use cpphs as a library, won't the license >> affect every program built with the GHC API? That seems to be a high >> price to pay. > > Yes, every program linking the `ghc` package would be affected by > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: > > | - As a practical consequence of the //LGPL with static-linking-exception// > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, > | **then there is no requirement to ship (or make available) any source code** > | together with the binaries, even if other parts of the GHC code-base > | were modified. > > However, don't forget we already have this issue w/ integer-gmp, and > with that the LGPL is in full effect (i.e. w/o a static-linkage-exception!) > > In that context, the suggestion was made[1] to handle the cpphs-code > like the GMP code, i.e. allow a compile-time configuration in the GHC > build-system to build a cpphs-free (and/or GMP-free) GHC for those > parties that need to avoid any LGPL-ish code whatsoever in their > toolchain. > > Would that address this concern? > > > [1]: http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From mail at joachim-breitner.de Fri May 8 10:25:07 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Fri, 08 May 2015 12:25:07 +0200 Subject: [Haskell-cafe] status of deb.haskell.org? In-Reply-To: References: <1428423317104-5768430.post@n5.nabble.com> <1431072473.1853.7.camel@joachim-breitner.de> Message-ID: <1431080707.1853.26.camel@joachim-breitner.de> Hi, Am Freitag, den 08.05.2015, 09:19 +0000 schrieb Andrew Cowie: > That's a shame. Do you have a recommendation for where people should > source up to date GHC packages for Debian from? with up to date, do you mean daily builds of GHC HEAD, or builds of stable GHC releases? I have heard that people would install the ubuntu packages created for https://github.com/hvr/multi-ghc-travis on Debian. If that does not work, you could use the Debian source packages from there and rebuild them locally. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From 6yearold at gmail.com Fri May 8 11:20:51 2015 From: 6yearold at gmail.com (Gleb Popov) Date: Fri, 8 May 2015 14:20:51 +0300 Subject: [Haskell-cafe] Automatic liftIO or how to write this shorter? Message-ID: Hello haskell-cafe@ I'm writing a GUI app in Haskell and bindings to the widget toolkit i'm using in parallel. These bindings are very simple and all its functions have return type (IO something). So far so good, i wrote the following code to create an config window: createConfigUI root = do box <- Box.add root -- first field addToPackEnd box =<< do f <- Fr.add box setPartText f Nothing "E-mail" setPartContent f Nothing =<< do box <- Box.add box addToPackEnd box =<< do e <- Ent.add box Ent.singleLineSet e True -- Here onEvent "changed,user" e $ do reactOnUserInput e objectShow e return e objectShow box return box objectShow f return f -- next field addToPackEnd box =<< do ... Initially, i was quite satisfied with flipped bind use for creating UI elements and arranging them. Nested do scopes allow copypasting code without renaming variables and also provide some visual representation on widget hierarchy. But at some point i need to return some stuff from some inner do block into outmost. For example, at the line with comment "Here" i defined let setText t = entrySet e t and wanted to return it from whole createConfigUI action. Moreover, createConfigUI have much more fields, for each of them i want to do the same. My initial thought was to wrap everything with runWriter and just call tell setText wherever i want to gather all setter functions into a list, but i can't do this because i would need to put liftIO before every IO action all over the place. If only there was i way to turn an (IO a) into (MonadIO m => m a), it would be easy. Another solution is to make my bindings return (MonadIO m => m a). This would be equal effort of plugging liftIO's everywhere, but at least it would be hidden from user of bindings. I'd gone this way, but looked at gtk bindings first and found that (IO a) is used there. So, my questions are: 1. What would you recommend in my situation? Is it possible yield values from inner do blocks into outer without much hassle? 2. If there is nothing wrong with switching bindings from (IO a) to MonadIO typeclass, why not to do this for gtk, wxWidgets and nearly every FFI binding? Thanks in advance. -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri May 8 12:07:07 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 May 2015 08:07:07 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: Indeed. This is also how we use gcc and the llvm tooling. If we want the cpp tooling to be available as a library, that's a whole nother set of needs. Gmp lgpl I can brush under the rug at work because there's the various integer simple options, this gets a bit more squirrelly otherwise. Maybe it'd be simpler for two people to sit down for a weekend, one only narrating the cpphs code, the other only listening and paraphrasing it into a new program. Copyright on text only covers literal copying. Nontrivial rephrasing of everything plus some rejiggering of non local structure is not prevented by copyright law, and I doubt there are any patents in play. On Friday, May 8, 2015, Mathieu Boespflug wrote: > [Gah, wrong From: email address given the list subscriptions, sorry > for the duplicates.] > > I'm unclear why cpphs needs to be made a dependency of the GHC API and > included as a lib. Could you elaborate? (in the wiki page possibly) > > Currently, GHC uses the system preprocessor, as a separate process. > Couldn't we for GHC 7.12 keep to exactly that, save for the fact that > by default GHC would call the cpphs binary for preprocessing, and have > the cpphs binary be available in GHC's install dir somewhere? > > fork()/execvce() is cheap. Certainly cheaper than the cost of > compiling a single Haskell module. Can't we keep to this > separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep > most license tainting concerns that way. > > > On 8 May 2015 at 11:39, Herbert Valerio Riedel > wrote: > > Hello, > > > > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: > >> If the intention is to use cpphs as a library, won't the license > >> affect every program built with the GHC API? That seems to be a high > >> price to pay. > > > > Yes, every program linking the `ghc` package would be affected by > > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: > > > > | - As a practical consequence of the //LGPL with > static-linking-exception// > > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** > > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, > > | **then there is no requirement to ship (or make available) any > source code** > > | together with the binaries, even if other parts of the GHC code-base > > | were modified. > > > > However, don't forget we already have this issue w/ integer-gmp, and > > with that the LGPL is in full effect (i.e. w/o a > static-linkage-exception!) > > > > In that context, the suggestion was made[1] to handle the cpphs-code > > like the GMP code, i.e. allow a compile-time configuration in the GHC > > build-system to build a cpphs-free (and/or GMP-free) GHC for those > > parties that need to avoid any LGPL-ish code whatsoever in their > > toolchain. > > > > Would that address this concern? > > > > > > [1]: > http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri May 8 15:41:11 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 8 May 2015 11:41:11 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87a8xhvh48.fsf@feelingofgreen.ru> <895651832.1251542.1430931188127.JavaMail.yahoo@mail.yahoo.com> <87sib896d3.fsf@gnu.org> <8860F6E7-BF3D-4D6F-8506-7154DA264AF6@cs.otago.ac.nz> <649116C5-21A5-4351-9CF5-FDB6BA178EB4@me.com> <554C6AD6.2090103@jacobs-university.de> <87zj5f1lym.fsf@gmail.com> <554c81a6.021d980a.468e.72fd@mx.google.com> <87vbg31k8j.fsf@gmail.com> Message-ID: To clarify my point more concretely: Adding cpphs the cli tool to ghc build process / bin dist has no more licensing implications than does using gcc as a compiler / assembler. Ie NONE Using cpphs as a library is Another discussion. But I don't think it's the one we're having today. On Friday, May 8, 2015, Carter Schonwald wrote: > Indeed. This is also how we use gcc and the llvm tooling. > > If we want the cpp tooling to be available as a library, that's a whole > nother set of needs. > > Gmp lgpl I can brush under the rug at work because there's the various > integer simple options, this gets a bit more squirrelly otherwise. > > Maybe it'd be simpler for two people to sit down for a weekend, one only > narrating the cpphs code, the other only listening and paraphrasing it into > a new program. Copyright on text only covers literal copying. Nontrivial > rephrasing of everything plus some rejiggering of non local structure is > not prevented by copyright law, and I doubt there are any patents in play. > > > > On Friday, May 8, 2015, Mathieu Boespflug > wrote: > >> [Gah, wrong From: email address given the list subscriptions, sorry >> for the duplicates.] >> >> I'm unclear why cpphs needs to be made a dependency of the GHC API and >> included as a lib. Could you elaborate? (in the wiki page possibly) >> >> Currently, GHC uses the system preprocessor, as a separate process. >> Couldn't we for GHC 7.12 keep to exactly that, save for the fact that >> by default GHC would call the cpphs binary for preprocessing, and have >> the cpphs binary be available in GHC's install dir somewhere? >> >> fork()/execvce() is cheap. Certainly cheaper than the cost of >> compiling a single Haskell module. Can't we keep to this >> separate-(and-pluggable)-preprocessor-executable scheme? We'd sidestep >> most license tainting concerns that way. >> >> >> On 8 May 2015 at 11:39, Herbert Valerio Riedel >> wrote: >> > Hello, >> > >> > On 2015-05-08 at 11:28:08 +0200, Niklas Larsson wrote: >> >> If the intention is to use cpphs as a library, won't the license >> >> affect every program built with the GHC API? That seems to be a high >> >> price to pay. >> > >> > Yes, every program linking the `ghc` package would be affected by >> > LGPL+SLE albeit in a contained way, as it's mentioned on the Wiki page: >> > >> > | - As a practical consequence of the //LGPL with >> static-linking-exception// >> > | (LGPL+SLE), **if no modifications are made to the `cpphs`-parts** >> > | (i.e. the LGPL+SLE covered modules) of the GHC code-base, >> > | **then there is no requirement to ship (or make available) any >> source code** >> > | together with the binaries, even if other parts of the GHC code-base >> > | were modified. >> > >> > However, don't forget we already have this issue w/ integer-gmp, and >> > with that the LGPL is in full effect (i.e. w/o a >> static-linkage-exception!) >> > >> > In that context, the suggestion was made[1] to handle the cpphs-code >> > like the GMP code, i.e. allow a compile-time configuration in the GHC >> > build-system to build a cpphs-free (and/or GMP-free) GHC for those >> > parties that need to avoid any LGPL-ish code whatsoever in their >> > toolchain. >> > >> > Would that address this concern? >> > >> > >> > [1]: >> http://www.reddit.com/r/haskell/comments/351pur/rfc_native_xcpp_for_ghc_proposal/cr1cdhb >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dan.doel at gmail.com Fri May 8 16:12:28 2015 From: dan.doel at gmail.com (Dan Doel) Date: Fri, 8 May 2015 12:12:28 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: vector generates a considerable amount of code using CPP macros. And with regard to other mails, I'm not too eager (personally) to port that to template Haskell, even though I'm no fan of CPP. The code generation being done is so dumb that CPP is pretty much perfect for it, and TH would probably just be more work (and it's certainly more work to write it again now that it's already written). On Wed, May 6, 2015 at 10:21 AM, Bardur Arantsson wrote: > On 06-05-2015 15:05, Alan & Kim Zimmerman wrote: > > Perhaps it makes sense to scan hackage to find all the different CPP > idioms > > that are actually used in Haskell code, if it is a small/well-defined set > > it may be worth writing a simple custom preprocessor. > > > > +1, I'll wager that the vast majority of usages are just for version > range checks. > > If there are packages that require more, they could just keep using the > system-cpp or, I, guess cpphs if it gets baked into GHC. Like you, I'd > want to see real evidence that that's actually worth the > effort/complication. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gershomb at gmail.com Fri May 8 17:13:06 2015 From: gershomb at gmail.com (Gershom B) Date: Fri, 8 May 2015 13:13:06 -0400 Subject: [Haskell-cafe] How to estimate number of downloads of GHC or Haskell Platform? In-Reply-To: <20150506142500.49F9478552C@labrador.cs.tufts.edu> References: <20150506142500.49F9478552C@labrador.cs.tufts.edu> Message-ID: The ubuntu popularity contest (from people who opt-in to report their package installs) has 11963 installs of GHC. (http://popcon.ubuntu.com/) I don?t know the right factor to scale that to ?total installs across ubuntu? or better yet ?total installs across various linux distros? but I would be curious to know. We may want to keep better and more uniform logs than we do (infrastructure volunteers welcome!). However, a crude grep on what we do have (going back through March 17) yields?91857 hits to urls prefixed "platform/download/2014.2.0.0/" So one can scale that out over a longer period of time if necessary. I?m sure that this is a low estimate as there is some interaction with our CDNs. The downloads page itself on haskell.org, over that same 52 day period, has 29456 hits (suggesting to me that many people probably hit the /platform page and access the installers from elsewhere than the haskell.org/downloads?page itself). I don?t have statistics available for the minimal installers hosted elsewhere, including MinGHC and GHC for OS X (and in fact one disadvantage of the latter being hosted on github is that download statistics are impossible). Perhaps fpcomplete, which hosts MinGHC, could provide statistics for that. Hope that helps. ?gershom On May 6, 2015 at 10:25:10 AM, Norman Ramsey (nr at cs.tufts.edu) wrote: > For a review, I'm trying to get a rough estimate of how many times GHC > or the Haskell Platform have been downloaded. Although I'm sure I've > seen this information graphed over time at workshops, my web-search > skills are not turning up anything. I'd be quite happy to get an > estimate to within a factor of ten. > > Can anyone suggest any sources, or a good way to estimate this number? > > > Norman > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From mwm at mired.org Fri May 8 20:10:51 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 8 May 2015 15:10:51 -0500 Subject: [Haskell-cafe] Using ClassyPrelude to handle either Text or ByteString Message-ID: Ok, I can't seem to figure out how to make this work, and since I'm using ClassyPrelude (from classy-prelude, latest version on hackage as of yesterday), I think cafe is a better place to ask than beginners. Sorry if this should have gone there. I want to read in a list of files, concatenate them, and then run the resulting data through a "process" function. So far, no problem. Given an opts record that contains the list of files and some control for the process function, this expression works: hPut stdout =<< process opts . concat <$> mapM (readFile . fpFromString) (files opts) (BTW, recommendations on cleaning that up gratefully accepted) However, I'd like to be able to read them all as either Text or ByteString, depending on options being passed to me. This doesn't work so well. If I give process a type of Text -> Text or ByteString->ByteString, everything works fine with no other changes. However, any attempt to make it polymorphic fails with ambiguous type warnings. I've tried a slew of things, and found a few that work. But none of them are what I'd call good, much less elegant. Is there a good way to do this? -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Fri May 8 21:54:41 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Sat, 9 May 2015 00:54:41 +0300 Subject: [Haskell-cafe] Automatic liftIO or how to write this shorter? In-Reply-To: References: Message-ID: Hi, Gleb. Assuming that you already in IO, and don't want to use lift or liftIO to lift actions into another stack level, you can choose one of the following: 1. Create a module with lifted operations for all operations in the framework. Then by the cost of some boilerplate code you'll have a framework that could be used in any MonadBaseControl. 2. Another way is to introduce concurrent primitives that will allow you to 'log' events. Here is an incomplete sketch: data ConfigUI = CUI { setText :: Text -> IO (), setAnotherText :: Text -> IO () } defCUI = ... newtype LogRef a = LV (IORef (Endo a)) newLog :: IO (LogRef a) newLog = LV <$> newIORef id writeLog :: LogRef a -> (a -> a) -> IO () writeLog (LV r) f = modifyIORef r (\x -> x <> Endo f) applyLog :: LogRef a -> a -> IO a applyLog (LV r) f = ($) <$> fmap appEndo (readIORef r) <*> pure f withLog :: a -> (LogRef a -> IO b) -> IO (a,b) withLog f v = newLog >>= \l -> f l >>= liftM2 (,) (applyLog lg v) configureConfigUI = do (cui, a) <- withLog defCUI $ \lg -> do .... writeLog (\x -> x{setText = entrySet e}) There is a big window for solutions that are using mutable references to log events in IO monad. Each with it's own pros and cons. Hope it helps -- Alexander On 8 May 2015 at 14:20, Gleb Popov <6yearold at gmail.com> wrote: > Hello haskell-cafe@ > > I'm writing a GUI app in Haskell and bindings to the widget toolkit i'm > using in parallel. These bindings are very simple and all its functions have > return type (IO something). > > So far so good, i wrote the following code to create an config window: > > createConfigUI root = do > box <- Box.add root > > -- first field > addToPackEnd box =<< do > f <- Fr.add box > setPartText f Nothing "E-mail" > setPartContent f Nothing =<< do > box <- Box.add box > > addToPackEnd box =<< do > e <- Ent.add box > Ent.singleLineSet e True > -- Here > onEvent "changed,user" e $ do > reactOnUserInput e > objectShow e > return e > > objectShow box > return box > > objectShow f > return f > > -- next field > addToPackEnd box =<< do > ... > > Initially, i was quite satisfied with flipped bind use for creating UI > elements and arranging them. Nested do scopes allow copypasting code without > renaming variables and also provide some visual representation on widget > hierarchy. > > But at some point i need to return some stuff from some inner do block into > outmost. For example, at the line with comment "Here" i defined > > let setText t = entrySet e t > > and wanted to return it from whole createConfigUI action. Moreover, > createConfigUI have much more fields, for each of them i want to do the > same. > > My initial thought was to wrap everything with runWriter and just call > > tell setText > > wherever i want to gather all setter functions into a list, but i can't do > this because i would need to put liftIO before every IO action all over the > place. > > If only there was i way to turn an (IO a) into (MonadIO m => m a), it would > be easy. > > Another solution is to make my bindings return (MonadIO m => m a). This > would be equal effort of plugging liftIO's everywhere, but at least it would > be hidden from user of bindings. I'd gone this way, but looked at gtk > bindings first and found that (IO a) is used there. > > So, my questions are: > > 1. What would you recommend in my situation? Is it possible yield values > from inner do blocks into outer without much hassle? > 2. If there is nothing wrong with switching bindings from (IO a) to MonadIO > typeclass, why not to do this for gtk, wxWidgets and nearly every FFI > binding? > > Thanks in advance. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Alexander From winterkoninkje at gmail.com Fri May 8 22:20:25 2015 From: winterkoninkje at gmail.com (wren romano) Date: Fri, 8 May 2015 18:20:25 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Fri, May 8, 2015 at 12:12 PM, Dan Doel wrote: > vector generates a considerable amount of code using CPP macros. > > And with regard to other mails, I'm not too eager (personally) to port that > to template Haskell, even though I'm no fan of CPP. The code generation > being done is so dumb that CPP is pretty much perfect for it, and TH would > probably just be more work (and it's certainly more work to write it again > now that it's already written). Incidentally, if we really want to pursue the "get rid of CPP by building it into the GHC distro"... In recent years there've been a number of papers on "variational lambda-calculi"[1] which essentially serve to embed flag-based preprocessor conditionals directly into the language itself. One major benefit of this approach is that the compiler can then typecheck *all* variations of the code, rather than only checking whichever particular variation we happen to be compiling at the time. This is extremely useful for avoiding bitrot in the preprocessor conditionals. ...If we were to try and obviate the dependency on CPP, variational typing seems like a far more solid approach than simply reinventing the preprocessing wheel yet again. (The downside, of course, is making the Haskell spec significantly more complex.) [1] e.g., -- Live well, ~wren From emertens at gmail.com Fri May 8 22:48:58 2015 From: emertens at gmail.com (Eric Mertens) Date: Fri, 8 May 2015 15:48:58 -0700 Subject: [Haskell-cafe] Using ClassyPrelude to handle either Text or ByteString In-Reply-To: References: Message-ID: First, we can clean that code: do xs <- mapM (readFile . fpFromString) (files opts) hPut stdout (process opts (concat xs)) You won't be able to make the decision of which type process should work at inside of process because this decision will also affect which implementation of readFile is used. What you will need to do is inspect the 'opts' in the function above and execute it at a type as determined by the options. example opts | isTextMode opts = aboveFunctionAsText opts | isByteStringMode opts = aboveFunctionAsByteString opts If you'd like to unify these into a single implementation as above you'll need to provide some kind of extra information to resolve the type ambiguity. This would have a type like: aboveFunctionWithProxy :: IsSequence a => proxy a -> Options -> IO () exampleUsingProxies opts | isTextMode opts = aboveFunctionWithProxy (Proxy :: Proxy Text) opts | isByteStringMode opts = aboveFunctionWithProxy (Proxy :: Proxy ByteString) opts The proxy parameter could then need to be linked to the type of the internal xs parameter above using either scoped type variables or a helper function similar to 'asTypeOf' with with a different type! On Fri, May 8, 2015 at 1:10 PM, Mike Meyer wrote: > Ok, I can't seem to figure out how to make this work, and since I'm using > ClassyPrelude (from classy-prelude, latest version on hackage as of > yesterday), I think cafe is a better place to ask than beginners. Sorry if > this should have gone there. > > I want to read in a list of files, concatenate them, and then run the > resulting data through a "process" function. So far, no problem. Given an > opts record that contains the list of files and some control for the > process function, this expression works: > > hPut stdout =<< process opts . concat > <$> mapM (readFile . fpFromString) (files opts) > > (BTW, recommendations on cleaning that up gratefully accepted) > > However, I'd like to be able to read them all as either Text or > ByteString, depending on options being passed to me. This doesn't work so > well. If I give process a type of Text -> Text or ByteString->ByteString, > everything works fine with no other changes. However, any attempt to make > it polymorphic fails with ambiguous type warnings. > > I've tried a slew of things, and found a few that work. But none of them > are what I'd call good, much less elegant. Is there a good way to do this? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Eric Mertens -------------- next part -------------- An HTML attachment was scrubbed... URL: From donn at avvanta.com Fri May 8 23:40:28 2015 From: donn at avvanta.com (Donn Cave) Date: Fri, 8 May 2015 16:40:28 -0700 (PDT) Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: <20150508234028.C7ADC276CE1@mail.avvanta.com> Quoth wren romano , ... > Incidentally, if we really want to pursue the "get rid of CPP by > building it into the GHC distro"... > > In recent years there've been a number of papers on "variational > lambda-calculi"[1] which essentially serve to embed flag-based > preprocessor conditionals directly into the language itself. One major > benefit of this approach is that the compiler can then typecheck *all* > variations of the code, rather than only checking whichever particular > variation we happen to be compiling at the time. This is extremely > useful for avoiding bitrot in the preprocessor conditionals. But fatal if compilation is conditional on something that affects the ability to type check, am I right? Such as different compilers or versions of same compiler. Donn From allbery.b at gmail.com Fri May 8 23:56:41 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Fri, 8 May 2015 19:56:41 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: <20150508234028.C7ADC276CE1@mail.avvanta.com> References: <87zj5i55gs.fsf@gmail.com> <20150508234028.C7ADC276CE1@mail.avvanta.com> Message-ID: On Fri, May 8, 2015 at 7:40 PM, Donn Cave wrote: > But fatal if compilation is conditional on something that affects the > ability to type check, am I right? Such as different compilers or > versions of same compiler. > Not per the abstract (paper itself seems to be paywalled). They had an earlier work with that issue, the linked one is about how to be robust in the face of such conditionals. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat May 9 13:59:48 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 09 May 2015 15:59:48 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: On Sat, 09 May 2015 00:20:25 +0200, wren romano wrote: > In recent years there've been a number of papers on "variational > lambda-calculi"[1] which essentially serve to embed flag-based > preprocessor conditionals directly into the language itself. : > [1] e.g., > Or, without paying: http://web.engr.oregonstate.edu/~walkiner/papers/icfp12-variational-type-errors.pdf Best regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ From allbery.b at gmail.com Sat May 9 14:05:09 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Sat, 9 May 2015 10:05:09 -0400 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> <20150508234028.C7ADC276CE1@mail.avvanta.com> Message-ID: On Fri, May 8, 2015 at 7:56 PM, Brandon Allbery wrote: > On Fri, May 8, 2015 at 7:40 PM, Donn Cave wrote: > >> But fatal if compilation is conditional on something that affects the >> ability to type check, am I right? Such as different compilers or >> versions of same compiler. >> > > Not per the abstract (paper itself seems to be paywalled). They had an > earlier work with that issue, the linked one is about how to be robust in > the face of such conditionals. > There's also the question about handling changes in syntax, e.g. LambdaCase throws parse errors in older compilers. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Sat May 9 18:00:14 2015 From: michael at snoyman.com (Michael Snoyman) Date: Sat, 09 May 2015 18:00:14 +0000 Subject: [Haskell-cafe] How to estimate number of downloads of GHC or Haskell Platform? In-Reply-To: References: <20150506142500.49F9478552C@labrador.cs.tufts.edu> Message-ID: Sure, I'd be happy to. Note that we've only been tracking the downloads for a few weeks. Columns are the week, download counts, and byte counts. GHC 7.8.4, 64-bit: 1Apr 06, 2015302,879,486,2062Apr 13, 201519911,212,936,5803Apr 20, 20156,14389,234,097,0004Apr 27, 20152,09664,599,329,3435May 04, 20151,16320,024,120,772 GHC 7.8.3, 32-bit: 1Apr 06, 20151,28850,439,004,9092Apr 13, 20151,65751,241,906,6873Apr 20, 2015571,412,117,2514Apr 27, 20153933,265,847,2625May 04, 201525618,158,870 GHC 7.8.4, 32-bit: 1Apr 06, 2015152,571,3692Apr 13, 2015451,614,425,6433Apr 20, 201570818,985,387,4194Apr 27, 201538213,855,185,5375May 04, 20151403,848,468,524 There are approximately 2000 total downloads for 7.10 in this period as well. On Fri, May 8, 2015 at 8:14 PM Gershom B wrote: > The ubuntu popularity contest (from people who opt-in to report their > package installs) has 11963 installs of GHC. (http://popcon.ubuntu.com/) > I don?t know the right factor to scale that to ?total installs across > ubuntu? or better yet ?total installs across various linux distros? but I > would be curious to know. > > We may want to keep better and more uniform logs than we do > (infrastructure volunteers welcome!). However, a crude grep on what we do > have (going back through March 17) yields 91857 hits to urls prefixed > "platform/download/2014.2.0.0/" So one can scale that out over a longer > period of time if necessary. I?m sure that this is a low estimate as there > is some interaction with our CDNs. > > The downloads page itself on haskell.org, over that same 52 day period, > has 29456 hits (suggesting to me that many people probably hit the > /platform page and access the installers from elsewhere than the > haskell.org/downloads page itself). > > I don?t have statistics available for the minimal installers hosted > elsewhere, including MinGHC and GHC for OS X (and in fact one disadvantage > of the latter being hosted on github is that download statistics are > impossible). Perhaps fpcomplete, which hosts MinGHC, could provide > statistics for that. > > Hope that helps. > > ?gershom > > On May 6, 2015 at 10:25:10 AM, Norman Ramsey (nr at cs.tufts.edu) wrote: > > For a review, I'm trying to get a rough estimate of how many times GHC > > or the Haskell Platform have been downloaded. Although I'm sure I've > > seen this information graphed over time at workshops, my web-search > > skills are not turning up anything. I'd be quite happy to get an > > estimate to within a factor of ten. > > > > Can anyone suggest any sources, or a good way to estimate this number? > > > > > > Norman > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alpmestan at gmail.com Sun May 10 12:38:13 2015 From: alpmestan at gmail.com (Alp Mestanogullari) Date: Sun, 10 May 2015 14:38:13 +0200 Subject: [Haskell-cafe] [ANN] servant 0.4.0 released (+new website) Message-ID: Hello everyone, We're happy to announce the releases of: - servant 0.4.0 - servant-server 0.4.0 - servant-client 0.4.0 - servant-jquery 0.4.0 - servant-docs 0.4.0 - servant-blaze 0.4.0 - servant-lucid 0.4.0 to Hackage. As well as a new website, same URL as before: http://haskell-servant.github.io/ -- which features a tutorial that's much more informative than the getting started we had for the previous version. The tutorial is available at http://haskell-servant.github.io/tutorial The highlights for this release are: - Multiple content-types support (with servant-blaze and servant-lucid offering a way to encode data for the HTML content type) - Handlers in other monads than `EitherT` - Response headers support - Safe links to endpoints - Saner types for aborting early in request handlers (the `Left` branch in `EitherT`) For more details about the new features, please read the release post: http://haskell-servant.github.io/posts/2015-05-10-servant-0.4-released.html Cheers -- Alp Mestanogullari -------------- next part -------------- An HTML attachment was scrubbed... URL: From 6yearold at gmail.com Sun May 10 14:41:06 2015 From: 6yearold at gmail.com (Gleb Popov) Date: Sun, 10 May 2015 17:41:06 +0300 Subject: [Haskell-cafe] Automatic liftIO or how to write this shorter? In-Reply-To: References: Message-ID: On Sat, May 9, 2015 at 12:54 AM, Alexander V Vershilov < alexander.vershilov at gmail.com> wrote: > Hi, Gleb. > > Assuming that you already in IO, and don't want to use lift or liftIO > to lift actions into another stack level, you can choose one of the > following: > > 1. Create a module with lifted operations for all operations in the > framework. Then by the cost of some boilerplate code you'll have > a framework that could be used in any MonadBaseControl. > I'd go this way for bindings library itself, but i'm wonder why bindings to other toolkits use plain IO. > 2. Another way is to introduce concurrent primitives that will allow > you to 'log' events. Here is an incomplete sketch: > > data ConfigUI = CUI { setText :: Text -> IO (), setAnotherText :: > Text -> IO () } > > defCUI = ... > > newtype LogRef a = LV (IORef (Endo a)) > > newLog :: IO (LogRef a) > newLog = LV <$> newIORef id > > writeLog :: LogRef a -> (a -> a) -> IO () > writeLog (LV r) f = modifyIORef r (\x -> x <> Endo f) > > applyLog :: LogRef a -> a -> IO a > applyLog (LV r) f = ($) <$> fmap appEndo (readIORef r) <*> pure f > > withLog :: a -> (LogRef a -> IO b) -> IO (a,b) > withLog f v = newLog >>= \l -> f l >>= liftM2 (,) (applyLog lg v) > > configureConfigUI = do > (cui, a) <- withLog defCUI $ \lg -> do > .... > writeLog (\x -> x{setText = entrySet e}) > This is, basically, a reimplementation of Writer monad functionality using mutable variables in IO. I've also come up with this, but was hoping to somehow reuse existing Writer monad. > There is a big window for solutions that are using mutable references > to log events in IO monad. Each with it's own pros and cons. > > Hope it helps > > -- > Alexander > > On 8 May 2015 at 14:20, Gleb Popov <6yearold at gmail.com> wrote: > > Hello haskell-cafe@ > > > > I'm writing a GUI app in Haskell and bindings to the widget toolkit i'm > > using in parallel. These bindings are very simple and all its functions > have > > return type (IO something). > > > > So far so good, i wrote the following code to create an config window: > > > > createConfigUI root = do > > box <- Box.add root > > > > -- first field > > addToPackEnd box =<< do > > f <- Fr.add box > > setPartText f Nothing "E-mail" > > setPartContent f Nothing =<< do > > box <- Box.add box > > > > addToPackEnd box =<< do > > e <- Ent.add box > > Ent.singleLineSet e True > > -- Here > > onEvent "changed,user" e $ do > > reactOnUserInput e > > objectShow e > > return e > > > > objectShow box > > return box > > > > objectShow f > > return f > > > > -- next field > > addToPackEnd box =<< do > > ... > > > > Initially, i was quite satisfied with flipped bind use for creating UI > > elements and arranging them. Nested do scopes allow copypasting code > without > > renaming variables and also provide some visual representation on widget > > hierarchy. > > > > But at some point i need to return some stuff from some inner do block > into > > outmost. For example, at the line with comment "Here" i defined > > > > let setText t = entrySet e t > > > > and wanted to return it from whole createConfigUI action. Moreover, > > createConfigUI have much more fields, for each of them i want to do the > > same. > > > > My initial thought was to wrap everything with runWriter and just call > > > > tell setText > > > > wherever i want to gather all setter functions into a list, but i can't > do > > this because i would need to put liftIO before every IO action all over > the > > place. > > > > If only there was i way to turn an (IO a) into (MonadIO m => m a), it > would > > be easy. > > > > Another solution is to make my bindings return (MonadIO m => m a). This > > would be equal effort of plugging liftIO's everywhere, but at least it > would > > be hidden from user of bindings. I'd gone this way, but looked at gtk > > bindings first and found that (IO a) is used there. > > > > So, my questions are: > > > > 1. What would you recommend in my situation? Is it possible yield values > > from inner do blocks into outer without much hassle? > > 2. If there is nothing wrong with switching bindings from (IO a) to > MonadIO > > typeclass, why not to do this for gtk, wxWidgets and nearly every FFI > > binding? > > > > Thanks in advance. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > -- > Alexander > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alexander.vershilov at gmail.com Sun May 10 15:57:26 2015 From: alexander.vershilov at gmail.com (Alexander V Vershilov) Date: Sun, 10 May 2015 18:57:26 +0300 Subject: [Haskell-cafe] Automatic liftIO or how to write this shorter? In-Reply-To: References: Message-ID: Hello, Gleb. On 10 May 2015 at 17:41, Gleb Popov <6yearold at gmail.com> wrote: > > > On Sat, May 9, 2015 at 12:54 AM, Alexander V Vershilov > wrote: >> >> Hi, Gleb. >> >> Assuming that you already in IO, and don't want to use lift or liftIO >> to lift actions into another stack level, you can choose one of the >> following: >> >> 1. Create a module with lifted operations for all operations in the >> framework. Then by the cost of some boilerplate code you'll have >> a framework that could be used in any MonadBaseControl. > > > I'd go this way for bindings library itself, but i'm wonder why bindings to > other toolkits use plain IO. Quite possiblly this will be good solution here. I can't speak for all developers, but I can imagine following reasons: a. laziness, c2hs or hsc2hs provides a way to create bindings in IO, so you have those for free and in many cases you are not interested in generalization. b. bindings author wants to keep 2 layers anyway, one for bindings itself in IO and another - safe highlevel wrapper with a number of utility functions, that make bindings easy to use in functional way. Then generalization is not required c. developer think that using monad-control is too scary to use (not applicable to generalization to MonadIO) d. bindings have incorrect MonadBaseControl instance (very rare situation, that could happen if you use forkIO and your state depends on the process where you are running action, or compicated resource handling). (not applicable to generalization to MonadIO) Indeed there can be other reasons > >> >> 2. Another way is to introduce concurrent primitives that will allow >> you to 'log' events. Here is an incomplete sketch: >> >> data ConfigUI = CUI { setText :: Text -> IO (), setAnotherText :: >> Text -> IO () } >> >> defCUI = ... >> >> newtype LogRef a = LV (IORef (Endo a)) >> >> newLog :: IO (LogRef a) >> newLog = LV <$> newIORef id >> >> writeLog :: LogRef a -> (a -> a) -> IO () >> writeLog (LV r) f = modifyIORef r (\x -> x <> Endo f) >> >> applyLog :: LogRef a -> a -> IO a >> applyLog (LV r) f = ($) <$> fmap appEndo (readIORef r) <*> pure f >> >> withLog :: a -> (LogRef a -> IO b) -> IO (a,b) >> withLog f v = newLog >>= \l -> f l >>= liftM2 (,) (applyLog lg v) >> >> configureConfigUI = do >> (cui, a) <- withLog defCUI $ \lg -> do >> .... >> writeLog (\x -> x{setText = entrySet e}) > > > This is, basically, a reimplementation of Writer monad functionality using > mutable variables in IO. I've also come up with this, but was hoping to > somehow reuse existing Writer monad. Yes it is, except the fact that you can reimplement stack of writers using single IO layer. But it gives you an ability to implement configuration in a composable way without changing bindings, or writing wrappers, so I had to mention this path. >> >> There is a big window for solutions that are using mutable references >> to log events in IO monad. Each with it's own pros and cons. >> >> Hope it helps >> >> -- >> Alexander >> >> On 8 May 2015 at 14:20, Gleb Popov <6yearold at gmail.com> wrote: >> > Hello haskell-cafe@ >> > >> > I'm writing a GUI app in Haskell and bindings to the widget toolkit i'm >> > using in parallel. These bindings are very simple and all its functions >> > have >> > return type (IO something). >> > >> > So far so good, i wrote the following code to create an config window: >> > >> > createConfigUI root = do >> > box <- Box.add root >> > >> > -- first field >> > addToPackEnd box =<< do >> > f <- Fr.add box >> > setPartText f Nothing "E-mail" >> > setPartContent f Nothing =<< do >> > box <- Box.add box >> > >> > addToPackEnd box =<< do >> > e <- Ent.add box >> > Ent.singleLineSet e True >> > -- Here >> > onEvent "changed,user" e $ do >> > reactOnUserInput e >> > objectShow e >> > return e >> > >> > objectShow box >> > return box >> > >> > objectShow f >> > return f >> > >> > -- next field >> > addToPackEnd box =<< do >> > ... >> > >> > Initially, i was quite satisfied with flipped bind use for creating UI >> > elements and arranging them. Nested do scopes allow copypasting code >> > without >> > renaming variables and also provide some visual representation on widget >> > hierarchy. >> > >> > But at some point i need to return some stuff from some inner do block >> > into >> > outmost. For example, at the line with comment "Here" i defined >> > >> > let setText t = entrySet e t >> > >> > and wanted to return it from whole createConfigUI action. Moreover, >> > createConfigUI have much more fields, for each of them i want to do the >> > same. >> > >> > My initial thought was to wrap everything with runWriter and just call >> > >> > tell setText >> > >> > wherever i want to gather all setter functions into a list, but i can't >> > do >> > this because i would need to put liftIO before every IO action all over >> > the >> > place. >> > >> > If only there was i way to turn an (IO a) into (MonadIO m => m a), it >> > would >> > be easy. >> > >> > Another solution is to make my bindings return (MonadIO m => m a). This >> > would be equal effort of plugging liftIO's everywhere, but at least it >> > would >> > be hidden from user of bindings. I'd gone this way, but looked at gtk >> > bindings first and found that (IO a) is used there. >> > >> > So, my questions are: >> > >> > 1. What would you recommend in my situation? Is it possible yield values >> > from inner do blocks into outer without much hassle? >> > 2. If there is nothing wrong with switching bindings from (IO a) to >> > MonadIO >> > typeclass, why not to do this for gtk, wxWidgets and nearly every FFI >> > binding? >> > >> > Thanks in advance. >> > >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > >> >> >> >> -- >> Alexander > > -- Alexander From mike at proclivis.com Sun May 10 15:58:16 2015 From: mike at proclivis.com (Proclivis) Date: Sun, 10 May 2015 09:58:16 -0600 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> Message-ID: <045561E9-F219-4E18-9CD7-71C08FD06D20@proclivis.com> Thanks guys, I looks like there are basically 2 ways to do this: 1) Build a structure of ForeignPtr with finalizers that will be freed whenever the GCC feels like it 2) Nest allocations and the will free at the end of IO I noticed that in Real World Haskell the example of #1 has a ForeignPtr and ByteString in a data constructor, and both are bang noted as strict. Is this required before passing the data to a C-call to ensure it is evaluated or just a choice with the usual implications, such that with or without the evaluation of the C-call is well behaved? Mike Sent from my iPad > On May 5, 2015, at 10:10 AM, Michael Steele wrote: > > Michael, > > It looks like memory cleanup is being ignored in the example you linked to. newCString and mallocArray do not automatically free memory. > > When building nested structures simply in order to pass them to a few C functions, I like to use with* and alloca* functions whenever possible. > > The following (untested) example temporarily marshals a C structure containing 2 pointers to null-terminated strings, and passes that to a supplied action. 4-byte pointers and ints are assumed: > > > data Person = Person String String Int > > withPerson :: Person -> (Ptr Person -> IO r) -> IO r > > withPerson (Person fn ln age) f = > > -- Haskell's layout rules allow you to line these all up vertically. > > -- Just place all your allocations before the first 'do'. > > withCString fn $ \pfn -> > > withCString ln $ \pln -> > > allocaBytes 12 $ \ptr -> do > > pokeByteOff ptr 0 pfn > > pokeByteOff ptr 4 pln > > pokeByteOff ptr 8 age > > f ptr > > In cases where you can't know ahead of time when the memory should be freed, you an use ForeignPtr. I think Real World Haskell gives an example of a nested structure marshaled in this way. By storing the ForeignPtr in a data object that gets carried around, you can guarantee that finalizes get called by the garbage collector only after you are done using them. > > I hope that helps. > > -- Michael Steele > >> On Tue, May 5, 2015 at 6:22 AM, Michael Jones wrote: >> Alexey, >> >> That is an interesting insight. I suppose there are C API like that. >> >> In my case, the FFI calls ioctl, which calls i2cdev_ioctl, which calls i2cdev_ioctl_rdwr. >> >> The only function that can assume anything about the structure is i2cdev_ioctl_rdwr, which as you can see below copies the data, but does not free it. >> >> So in this particular case, I need the FFI to free it. >> >> On the other hand, I could write a wrapper in C that frees the structure if that is the way FFI is supposed to be used. >> >> Does anyone know if there is a FFI solution that would not require a wrapper? >> >> Mike >> >> static noinline int i2cdev_ioctl_rdrw(struct i2c_client *client, >> unsigned long arg) >> { >> struct i2c_rdwr_ioctl_data rdwr_arg; >> struct i2c_msg *rdwr_pa; >> u8 __user **data_ptrs; >> int i, res; >> >> if (copy_from_user(&rdwr_arg, >> (struct i2c_rdwr_ioctl_data __user *)arg, >> sizeof(rdwr_arg))) >> return -EFAULT; >> >> >> >> On May 4, 2015, at 10:40 PM, Alexey Shmalko wrote: >> >> > Hi! >> > >> > Disclaimer: I haven't worked much with FFI, so I'd like someone >> > confirmed my words. >> > >> > Seems that allocated memory in your example is supposed to be freed >> > from inside C. It's not a memory leak. >> > >> > If I understand correctly documentation [1], malloc/free are just a >> > simple wrappers around C's malloc/free. It's mallocForeignPtr that >> > sets finalizer. >> > >> > Best regards, >> > Alexey Shmalko >> > >> > [1]: https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ffi-ghc.html >> > >> > On Tue, May 5, 2015 at 6:45 AM, Proclivis wrote: >> >> I should have mentioned GHC 7.8.3 Ubuntu 64bit >> >> >> >> Sent from my iPad >> >> >> >>> On May 4, 2015, at 9:42 PM, Proclivis wrote: >> >>> >> >>> FFI Gurus, >> >>> >> >>> I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. >> >>> >> >>> The example at this link uses the same technique, so it will serve as an example. >> >>> >> >>> https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc >> >>> >> >>> Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. >> >>> >> >>> But, there is no explicit free, nor a finalizer. >> >>> >> >>> Will the memory be freed when the Ptr of the Storable is freed? >> >>> >> >>> If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? >> >>> >> >>> Mike >> >>> >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > -- > -- Michael Steele -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Sun May 10 18:33:42 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Sun, 10 May 2015 20:33:42 +0200 Subject: [Haskell-cafe] Extensible states In-Reply-To: References: Message-ID: hmmm.. A form of "extensible state" constructed with an state monad with a Map indexed by the type of the data using "typeOf" could have advantages over extensible records. It makes the "transport" of data and the addition of more kinds of data less cumbersome. Among other things it encourages good programming practices like the use of newtypes. It is just a matter of defining two primitives: with getData :: (MonadState TheMap m,Typeable a) => m (Maybe a) and setData :: (MonadState TheMap m, Typeable a) => a -> m () and perhaps a third : delData. 2015-05-08 7:33 GMT+02:00 Fumiaki Kinoshita : > Except the performance, my extensible[0] library provides native lens > support (label names are also lenses!) and quite easy to use. Let me show > an example: > > {-# LANGUAGE TypeOperators, DataKinds, TemplateHaskell, FlexibleContexts > #-} > import Data.Extensible > import Control.Lens > import Control.Monad.State > > mkField "foo bar baz" > > statefulStuff :: State (Record '["foo" :> Int, "bar" :> Int, "baz" :> > Float]) () > statefulStuff = do > v <- use foo > bar += v > baz .= 42 > > main = print $ execState statefulStuff > $ foo @= 10 <: bar @= 0 <: baz @= 0 <: Nil > > I could use Vector Any internally for O(1) lookup, but seems trade-off > between lookup and update. > > 2015-05-05 18:40 GMT+09:00 Alberto G. Corona : > >> Hi, >> >> Anyone used some of the extensible record packages to create a kind of >> extensible state monad? >> >> I mean something that besides having "get", "gets" and "put" would have >> some kind of "add" and "gets": >> >> add :: a -> State () >> gets :: State (Maybe a) >> >> or >> >> add :: LabelName -> a -> State () >> gets :: LabelName -> State (Maybe a) >> >> >> So that I can extend the state without using additional monad >> transformers. Monad transformers are very hard for beginners and scramble >> error messages >> >> I did the first option for MFlow, hplayground and Transient packages >> (setSData and getSData). But my solution uses a map indexed by type and >> this requires a lookup for each access. >> >> I would like to know if there is an alternative with no lookups. I?m not >> obsessed with speed but In some applications the speed may be important.... >> >> Anyone? >> -- >> Alberto. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From publicityifl at gmail.com Sun May 10 20:02:43 2015 From: publicityifl at gmail.com (publicityifl at gmail.com) Date: Sun, 10 May 2015 13:02:43 -0700 (PDT) Subject: [Haskell-cafe] First Call for Papers for IFL 2015 Message-ID: <554fb963.2853b40a.5b6d.1149@mx.google.com> Hello, Please, find below the first call for papers for IFL 2015. Please forward these to anyone you think may be interested. Apologies for any duplicates you may receive. best regards, Jurriaan Hage Publicity Chair of IFL --- IFL 2015 - Call for papers 27th SYMPOSIUM ON IMPLEMENTATION AND APPLICATION OF FUNCTIONAL LANGUAGES - IFL 2015 University of Koblenz-Landau, Koblenz, Germany In cooperation with ACM SIGPLAN September 14-16, 2015 http://ifl2015.wikidot.com/ Scope The goal of the IFL symposia is to bring together researchers actively engaged in the implementation and application of functional and function-based programming languages. IFL 2015 will be a venue for researchers to present and discuss new ideas and concepts, work in progress, and publication-ripe results related to the implementation and application of functional languages and function-based programming. Peer-review Following the IFL tradition, IFL 2015 will use a post-symposium review process to produce the formal proceedings. All participants of IFL2015 are invited to submit either a draft paper or an extended abstract describing work to be presented at the symposium. At no time may work submitted to IFL be simultaneously submitted to other venues; submissions must adhere to ACM SIGPLAN's republication policy: http://www.sigplan.org/Resources/Policies/Republication The submissions will be screened by the program committee chair to make sure they are within the scope of IFL, and will appear in the draft proceedings distributed at the symposium. Submissions appearing in the draft proceedings are not peer-reviewed publications. Hence, publications that appear only in the draft proceedings do not count as publication for the ACM SIGPLAN republication policy. After the symposium, authors will be given the opportunity to incorporate the feedback from discussions at the symposium and will be invited to submit a revised full article for the formal review process. From the revised submissions, the program committee will select papers for the formal proceedings considering their correctness, novelty, originality, relevance, significance, and clarity. Important dates August 10: Submission deadline draft papers August 12: Notification of acceptance for presentation August 14: Early registration deadline August 21: Late registration deadline September 7: Submission deadline for pre-symposium proceedings September 14-16: IFL Symposium December 1: Submission deadline for post-symposium proceedings January 15, 2016: Notification of acceptance for post-symposium proceedings March 1, 2016: Camera-ready version for post-symposium proceedings Submission details Prospective authors are encouraged to submit papers or extended abstracts to be published in the draft proceedings and to present them at the symposium. All contributions must be written in English. Papers must adhere to the standard ACM two columns conference format. For the pre-symposium proceedings we adopt a 'weak' page limit of 12 pages. For the post-symposium proceedings the page limit of 12 pages is firm. A suitable document template for LaTeX can be found at: http://www.acm.org/sigs/sigplan/authorInformation.htm Authors submit through EasyChair: https://easychair.org/conferences/?conf=ifl2015 Topics IFL welcomes submissions describing practical and theoretical work as well as submissions describing applications and tools in the context of functional programming. If you are not sure whether your work is appropriate for IFL 2015, please contact the PC chair at rlaemmel at acm.org. Topics of interest include, but are not limited to: - language concepts - type systems, type checking, type inferencing - compilation techniques - staged compilation - run-time function specialization - run-time code generation - partial evaluation - (abstract) interpretation - metaprogramming - generic programming - automatic program generation - array processing - concurrent/parallel programming - concurrent/parallel program execution - embedded systems - web applications - (embedded) domain specific languages - security - novel memory management techniques - run-time profiling performance measurements - debugging and tracing - virtual/abstract machine architectures - validation, verification of functional programs - tools and programming techniques - (industrial) applications Peter Landin Prize The Peter Landin Prize is awarded to the best paper presented at the symposium every year. The honored article is selected by the program committee based on the submissions received for the formal review process. The prize carries a cash award equivalent to 150 Euros. Programme committee Chair: Ralf L??mmel, University of Koblenz-Landau, Germany - Malgorzata Biernacka, University of Wroclaw, Poland - Laura M. Castro, University of A Coru??a, Spain - Martin Erwig, Oregon State University, USA - Dan Ghica, University of Birmingham, UK - Andrew Gill, University of Kansas, USA - Stephan Herhut, Google, USA - Zhenjiang Hu, National Institute of Informatics (NII), Japan - Mauro Jaskelioff, CIFASIS/Universidad Nacional de Rosario, Argentina - Fr??d??ric Jouault, ESEO, France - Oleg Kiselyov, Tohoku University, Japan - Lindsey Kuper, Indiana University, USA - Rita Loogen, Philipps-Universit??t Marburg, Germany - Akimasa Morihata, University of Tokyo, Japan - Atsushi Ohori, Tohoku University, Japan - Bruno C. D. S. Oliveira, The University of Hong Kong, Hong Kong - Frank Piessens, Katholieke Universiteit Leuven, Belgium - Norman Ramsey, Tufts University, USA - Matthew Roberts, Macquarie University, Australia - Manfred Schmidt-Schauss, Goethe-University Frankfurt, Germany - Simon Thompson, University of Kent, UK - Stephanie Weirich, University of Pennsylvania, USA - Steve Zdancewic, University of Pennsylvania , USA Venue The 27th IFL will be held in association with the Faculty of Computer Science, University of Koblenz-Landau, Campus Koblenz. Koblenz is well connected by train to several international airports. For instance, Koblenz can be reached from Frankfurt by high-speed train ICE within an hour. The modern Koblenz campus is close to the city center and can be reached by foot, bus, or cab. See the website for more information on the venue. From clintonmead at gmail.com Mon May 11 00:36:43 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Mon, 11 May 2015 10:36:43 +1000 Subject: [Haskell-cafe] Is this functional reactive programming Message-ID: What I want to be able to do is something like this: do x <- newSTRef 2 y <- newSTRef 3 z <- letSTRef (x + y) r1 <- readSTRef z writeSTRef x 5 r2 <- readSTRef z return (r1, r2) This should return (6,15) The "letSTRef" is what's new. The value it returns can change based on the parts that make up it's function changing. I understand this syntax above isn't going to work (I'd have to use applicative at least I'd imagine) but my main question is that does something like this exist? Is it functional reactive programming or is it something else? I don't want to be reinventing the wheel if this type of idea is already implemented but I haven't recognised it. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Mon May 11 03:58:55 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Mon, 11 May 2015 10:58:55 +0700 Subject: [Haskell-cafe] Is this functional reactive programming In-Reply-To: References: Message-ID: On Mon, May 11, 2015 at 7:36 AM, Clinton Mead wrote: > The "letSTRef" is what's new. The value it returns can change based on the > parts that make up it's function changing. Certainly that sounds very close to FRP, which propounds the concept of _time-varying_ values. I understand this syntax above isn't going to work (I'd have to use > applicative at least I'd imagine) but my main question is that does > something like this exist? > Let's assume you want to adopt the classic effectful approach to FRP. Now when you write: x <- newSTRef 2 y <- newSTRef 3 z <- letSTRef (x + y) you're really working in a pure fragment. Moreover, letSTRef, while attractive, is sort of on the wrong track. Suppose we have two time-varying values mouseX and mouseY. They are both at least applicative values, i.e. f Int for some applicative, possibly even monadic, functor f. They are also primitive, like the way a Haskell Int is primitive and involves hardware-wired details, meaning you'll do the actual implement at a lower level than the following: We have a Euclidean distance function dist :: Int -> Int -> Int. To track the distance of the mouse pointer from the origin, we'd write liftA2 dist mouseX mouseY :: f Int, thus deriving another time-varying Int. Does this help clarify? -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From rasen.dubi at gmail.com Mon May 11 06:47:18 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Mon, 11 May 2015 06:47:18 +0000 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: <045561E9-F219-4E18-9CD7-71C08FD06D20@proclivis.com> References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> <045561E9-F219-4E18-9CD7-71C08FD06D20@proclivis.com> Message-ID: First note: it's not GCC, but Haskell's GC. Second, I believe it's not necessary to put strict annotations because all function parameters are evaluated before calling FFI function. It's just a general good practice to make all data fields strict unless there are reasons to do otherwise. On Sun, May 10, 2015, 18:58 Proclivis wrote: > Thanks guys, > > I looks like there are basically 2 ways to do this: > > 1) Build a structure of ForeignPtr with finalizers that will be freed > whenever the GCC feels like it > 2) Nest allocations and the will free at the end of IO > > I noticed that in Real World Haskell the example of #1 has a ForeignPtr > and ByteString in a data constructor, and both are bang noted as strict. Is > this required before passing the data to a C-call to ensure it is evaluated > or just a choice with the usual implications, such that with or without the > evaluation of the C-call is well behaved? > > Mike > > Sent from my iPad > > On May 5, 2015, at 10:10 AM, Michael Steele > wrote: > > Michael, > > It looks like memory cleanup is being ignored in the example you linked > to. newCString and mallocArray do not automatically free memory. > > When building nested structures simply in order to pass them to a few C > functions, I like to use with* and alloca* functions whenever possible. > > The following (untested) example temporarily marshals a C structure > containing 2 pointers to null-terminated strings, and passes that to a > supplied action. 4-byte pointers and ints are assumed: > > > data Person = Person String String Int > > withPerson :: Person -> (Ptr Person -> IO r) -> IO r > > withPerson (Person fn ln age) f = > > -- Haskell's layout rules allow you to line these all up vertically. > > -- Just place all your allocations before the first 'do'. > > withCString fn $ \pfn -> > > withCString ln $ \pln -> > > allocaBytes 12 $ \ptr -> do > > pokeByteOff ptr 0 pfn > > pokeByteOff ptr 4 pln > > pokeByteOff ptr 8 age > > f ptr > > In cases where you can't know ahead of time when the memory should be > freed, you an use ForeignPtr. I think Real World Haskell gives an example > of a nested structure marshaled in this way. By storing the ForeignPtr in a > data object that gets carried around, you can guarantee that finalizes get > called by the garbage collector only after you are done using them. > > I hope that helps. > > -- Michael Steele > > On Tue, May 5, 2015 at 6:22 AM, Michael Jones wrote: > >> Alexey, >> >> That is an interesting insight. I suppose there are C API like that. >> >> In my case, the FFI calls ioctl, which calls i2cdev_ioctl, which calls >> i2cdev_ioctl_rdwr. >> >> The only function that can assume anything about the structure is >> i2cdev_ioctl_rdwr, which as you can see below copies the data, but does not >> free it. >> >> So in this particular case, I need the FFI to free it. >> >> On the other hand, I could write a wrapper in C that frees the structure >> if that is the way FFI is supposed to be used. >> >> Does anyone know if there is a FFI solution that would not require a >> wrapper? >> >> Mike >> >> static noinline int i2cdev_ioctl_rdrw(struct i2c_client *client, >> unsigned long arg) >> { >> struct i2c_rdwr_ioctl_data rdwr_arg; >> struct i2c_msg *rdwr_pa; >> u8 __user **data_ptrs; >> int i, res; >> >> if (copy_from_user(&rdwr_arg, >> (struct i2c_rdwr_ioctl_data __user *)arg, >> sizeof(rdwr_arg))) >> return -EFAULT; >> >> >> >> On May 4, 2015, at 10:40 PM, Alexey Shmalko wrote: >> >> > Hi! >> > >> > Disclaimer: I haven't worked much with FFI, so I'd like someone >> > confirmed my words. >> > >> > Seems that allocated memory in your example is supposed to be freed >> > from inside C. It's not a memory leak. >> > >> > If I understand correctly documentation [1], malloc/free are just a >> > simple wrappers around C's malloc/free. It's mallocForeignPtr that >> > sets finalizer. >> > >> > Best regards, >> > Alexey Shmalko >> > >> > [1]: >> https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ffi-ghc.html >> > >> > On Tue, May 5, 2015 at 6:45 AM, Proclivis wrote: >> >> I should have mentioned GHC 7.8.3 Ubuntu 64bit >> >> >> >> Sent from my iPad >> >> >> >>> On May 4, 2015, at 9:42 PM, Proclivis wrote: >> >>> >> >>> FFI Gurus, >> >>> >> >>> I created a c2hs FFI of a nested C structure, where struct A has a >> pointer to a struct B. To do so, I used a malloc, but I am unsure if the >> memory will be freed when the resulting Ptr is freed. >> >>> >> >>> The example at this link uses the same technique, so it will serve as >> an example. >> >>> >> >>> >> https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc >> >>> >> >>> Line 48 and 51 do the malloc and assign the pointer in the struct, >> from inside a Storable poke implementation. >> >>> >> >>> But, there is no explicit free, nor a finalizer. >> >>> >> >>> Will the memory be freed when the Ptr of the Storable is freed? >> >>> >> >>> If it is, it implies that some magic keeps track of mallocs inside a >> poke, and creates finalizers. Or, this example leaks. If it leaks, how do I >> create a finalizer from inside a poke implementation? >> >>> >> >>> Mike >> >>> >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > -- Michael Steele > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From daniel.trstenjak at gmail.com Mon May 11 08:31:03 2015 From: daniel.trstenjak at gmail.com (Daniel Trstenjak) Date: Mon, 11 May 2015 10:31:03 +0200 Subject: [Haskell-cafe] RFC: "Native -XCPP" Proposal In-Reply-To: References: <87zj5i55gs.fsf@gmail.com> Message-ID: <20150511083103.GA4434@machine> Hi Wren, > Incidentally, if we really want to pursue the "get rid of CPP by > building it into the GHC distro"... > > In recent years there've been a number of papers on "variational > lambda-calculi"[1] which essentially serve to embed flag-based > preprocessor conditionals directly into the language itself. One major > benefit of this approach is that the compiler can then typecheck *all* > variations of the code, rather than only checking whichever particular > variation we happen to be compiling at the time. This is extremely > useful for avoiding bitrot in the preprocessor conditionals. > > ...If we were to try and obviate the dependency on CPP, variational > typing seems like a far more solid approach than simply reinventing > the preprocessing wheel yet again. (The downside, of course, is making > the Haskell spec significantly more complex.) I think even more beneficial than type checking all cases is the easier support for any Haskell tooling operating with the Haskell source if all cases are part of the AST. Greetings, Daniel From fhofmann at techfak.uni-bielefeld.de Mon May 11 10:24:57 2015 From: fhofmann at techfak.uni-bielefeld.de (Florian Hofmann) Date: Mon, 11 May 2015 12:24:57 +0200 Subject: [Haskell-cafe] Automated Differentiation of Matrices (again) Message-ID: In [1](this) email thread Edward Kmett and Dominic Steinitz discuss the state of interoperability of `ad` and `hmatric` (or `repa`) with Edward hinting that the 4.0 line of `ad` might improve on the situation. Could someone elaborate on the state of affairs two years later? Florian [1]: https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107561.html -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Mon May 11 10:33:48 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Mon, 11 May 2015 10:33:48 +0000 Subject: [Haskell-cafe] using scoped type variables in proofs... Message-ID: Hello, I have written the below proof as an exercise. I want to explicitly annotate the proof with type variables.....but I cant get a line to work... > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P > data Nat where > Z :: Nat > S :: Nat -> Nat > data SNat (a :: Nat) where > SZ :: SNat 'Z > SS :: SNat a -> SNat ('S a) here a nice plus > type family (n :: Nat) :+ (m :: Nat) :: Nat > type instance Z :+ m = m > type instance (S n) :+ m = S (n :+ m) lets try to do > data val1 :== val2 where > Refl :: val :== val If I prove its abelian then we get it... the "proof" works if we remove the type annotation but I want the annotation to convince myself I know whats going on. > theoremPlusAbelian :: SNat a -> SNat b -> (a :+ b) :== (b :+ a) > theoremPlusAbelian (SZ :: SNat a) (SZ :: SNat b) = > -- forall 0 and 0 > (Refl :: (a :+ b) :== (b :+ a)) > theoremPlusAbelian ((SS a) :: SNat a) (SZ :: SNat b) = > -- forall a + 1 and 0 > case theoremPlusAbelian (a :: (a ~ 'S a1) => SNat a1) (SZ :: SNat b) of > (Refl :: (a1 :+ b) :== (b :+ a1)) -> > (Refl :: (a :+ b) :== (b :+ a)) > theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = > -- forall 0 and a + 1 > case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of > (Refl :: (a :+ b1) :== (b1 :+ a)) -> > (Refl :: (a :+ b) :== (b :+ a)) > -- cant seem to prove this... > theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = > -- forall a+1 and b+1 > -- 1st prove (a + 1) + b = b + (a + 1)...from above > case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => SNat b1) of THE COMMENTED LINE FAILS. Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) from the context (a ~ 'S a1) bound by a pattern with constructor SS :: forall (a :: Nat). SNat a -> SNat ('S a), in an equation for 'theoremPlusAbelian' at Cafe2.lhs:57:24-27 or from (b ~ 'S a2) bound by a pattern with constructor SS :: forall (a :: Nat). SNat a -> SNat ('S a), in an equation for 'theoremPlusAbelian' at Cafe2.lhs:57:45-48 NB: ':+' is a type function, and may not be injective The type variable 'b1' is ambiguous Expected type: (a :+ a2) :== (a2 :+ a) Actual type: (a :+ b1) :== (b1 :+ a) Relevant bindings include b :: SNat a2 (bound at Cafe2.lhs:57:48) a :: SNat a1 (bound at Cafe2.lhs:57:27) In the pattern: Refl :: (a :+ b1) :== (b1 :+ a) In a case alternative: (Refl :: (a :+ b1) :== (b1 :+ a)) -> case theoremPlusAbelian a (SS b) of { Refl -> case theoremPlusAbelian a b of { Refl -> Refl } } In the expression: case theoremPlusAbelian ((SS a) :: SNat a) (b :: b ~ S b1 => SNat b1) of { (Refl :: (a :+ b1) :== (b1 :+ a)) -> case theoremPlusAbelian a (SS b) of { Refl -> case theoremPlusAbelian a b of { Refl -> ... } } } > -- (Refl :: (a :+ b1) :== (b1 :+ a)) -> > Refl -> > -- now prove a + (b + 1) = (b + 1) + a...from above > case theoremPlusAbelian a (SS b) of > Refl -> > -- now prove a + b = b + a > case theoremPlusAbelian a b of > -- which seems to have proved a + b = b + a > Refl -> Refl CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon May 11 11:58:09 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 11 May 2015 14:58:09 +0300 Subject: [Haskell-cafe] using scoped type variables in proofs... In-Reply-To: References: Message-ID: <55509951.8050300@ro-che.info> GHC tells you that b1 is ambiguous, so that should tell you that it isn't getting bound in the case expression as you'd think. The reason is that type variables only get bound at value bindings; but you attached the signature to an expression. To fix it, move the annotation to the pattern like this: theoremPlusAbelian ((SS a) :: (SNat a)) ((SS (b :: SNat b1)) :: (SNat b)) = On 11/05/15 13:33, Nicholls, Mark wrote: > Hello, > > > > I have written the below proof as an exercise. > > > > I want to explicitly annotate the proof with type variables ..but I cant > get a line to work > > > >> {-# LANGUAGE DataKinds #-} > >> {-# LANGUAGE ExplicitForAll #-} > >> {-# LANGUAGE FlexibleContexts #-} > >> {-# LANGUAGE FlexibleInstances #-} > >> {-# LANGUAGE GADTs #-} > >> {-# LANGUAGE MultiParamTypeClasses #-} > >> {-# LANGUAGE PolyKinds #-} > >> {-# LANGUAGE StandaloneDeriving #-} > >> {-# LANGUAGE TypeFamilies #-} > >> {-# LANGUAGE TypeOperators #-} > >> {-# LANGUAGE UndecidableInstances #-} > >> {-# LANGUAGE ScopedTypeVariables #-} > > > >> import Prelude hiding (head, tail, (++), (+), replicate) > >> import qualified Prelude as P > > > >> data Nat where > >> Z :: Nat > >> S :: Nat -> Nat > > > >> data SNat (a :: Nat) where > >> SZ :: SNat 'Z > >> SS :: SNat a -> SNat ('S a) > > > > here a nice plus > > > >> type family (n :: Nat) :+ (m :: Nat) :: Nat > >> type instance Z :+ m = m > >> type instance (S n) :+ m = S (n :+ m) > > > > lets try to do > > > >> data val1 :== val2 where > >> Refl :: val :== val > > > > If I prove its abelian then we get it... > > > > the "proof" works if we remove the type annotation > > but I want the annotation to convince myself I know whats going on. > > > > > >> theoremPlusAbelian :: SNat a -> SNat b -> (a :+ b) :== (b :+ a) > >> theoremPlusAbelian (SZ :: SNat a) (SZ :: SNat b) = > >> -- forall 0 and 0 > >> (Refl :: (a :+ b) :== (b :+ a)) > >> theoremPlusAbelian ((SS a) :: SNat a) (SZ :: SNat b) = > >> -- forall a + 1 and 0 > >> case theoremPlusAbelian (a :: (a ~ 'S a1) => SNat a1) (SZ :: SNat b) of > >> (Refl :: (a1 :+ b) :== (b :+ a1)) -> > >> (Refl :: (a :+ b) :== (b :+ a)) > >> theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = > >> -- forall 0 and a + 1 > >> case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of > >> (Refl :: (a :+ b1) :== (b1 :+ a)) -> > >> (Refl :: (a :+ b) :== (b :+ a)) > >> -- cant seem to prove this... > >> theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = > >> -- forall a+1 and b+1 > >> -- 1st prove (a + 1) + b = b + (a + 1)...from above > >> case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => > SNat b1) of > > > > THE COMMENTED LINE FAILS. > > > > Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) > > from the context (a ~ 'S a1) > > bound by a pattern with constructor > > SS :: forall (a :: Nat). SNat a -> SNat ('S a), > > in an equation for ?theoremPlusAbelian? > > at Cafe2.lhs:57:24-27 > > or from (b ~ 'S a2) > > bound by a pattern with constructor > > SS :: forall (a :: Nat). SNat a -> SNat ('S a), > > in an equation for ?theoremPlusAbelian? > > at Cafe2.lhs:57:45-48 > > NB: ?:+? is a type function, and may not be injective > > The type variable ?b1? is ambiguous > > Expected type: (a :+ a2) :== (a2 :+ a) > > Actual type: (a :+ b1) :== (b1 :+ a) > > Relevant bindings include > > b :: SNat a2 (bound at Cafe2.lhs:57:48) > > a :: SNat a1 (bound at Cafe2.lhs:57:27) > > In the pattern: Refl :: (a :+ b1) :== (b1 :+ a) > > In a case alternative: > > (Refl :: (a :+ b1) :== (b1 :+ a)) > > -> case theoremPlusAbelian a (SS b) of { > > Refl -> case theoremPlusAbelian a b of { Refl -> Refl } } > > In the expression: > > case > > theoremPlusAbelian ((SS a) :: SNat a) (b :: b ~ S b1 => SNat b1) > > of { > > (Refl :: (a :+ b1) :== (b1 :+ a)) > > -> case theoremPlusAbelian a (SS b) of { > > Refl -> case theoremPlusAbelian a b of { Refl -> ... } } } > > > > > > > >> -- (Refl :: (a :+ b1) :== (b1 :+ a)) -> > >> Refl -> > >> -- now prove a + (b + 1) = (b + 1) + a...from above > >> case theoremPlusAbelian a (SS b) of > >> Refl -> > >> -- now prove a + b = b + a > >> case theoremPlusAbelian a b of > >> -- which seems to have proved a + b = b + a > >> Refl -> Refl > > > > > > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by > copyright (and other intellectual property rights). If you are not the > intended recipient please e-mail the sender and then delete the email > and any attached files immediately. Any further use or dissemination is > prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and > any attachments are virus free, it is your responsibility to ensure that > this message and any attachments are virus free and do not affect your > systems / data. > > Communicating by email is not 100% secure and carries risks such as > delay, data corruption, non-delivery, wrongful interception and > unauthorised amendment. If you communicate with us by e-mail, you > acknowledge and assume these risks, and you agree to take appropriate > measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, > Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions > International, Be Viacom, Viacom International Media Networks and VIMN > and Comedy Central are all trading names of MTV Networks Europe. MTV > Networks Europe is a partnership between MTV Networks Europe Inc. and > Viacom Networks Europe Inc. Address for service in Great Britain is > 17-29 Hawley Crescent, London, NW1 8TT. > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nicholls.mark at vimn.com Mon May 11 12:43:33 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Mon, 11 May 2015 12:43:33 +0000 Subject: [Haskell-cafe] using scoped type variables in proofs... In-Reply-To: <55509951.8050300@ro-che.info> References: <55509951.8050300@ro-che.info> Message-ID: That worked!.... But doesn?t seem to be true of all the previous cases! i.e. The b1 here is bound quite happily > theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = > -- forall 0 and a + 1 > case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of > (Refl :: (a :+ b1) :== (b1 :+ a)) -> > (Refl :: (a :+ b) :== (b :+ a)) yet > theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = > -- forall a+1 and b+1 > -- 1st prove (a + 1) + b = b + (a + 1)...from above > case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => SNat b1) of > (Refl :: (a :+ b1) :== (b1 :+ a)) -> Complains There seems little difference? >GHC tells you that b1 is ambiguous, so that should tell you that it isn't getting >bound in the case expression as you'd think. > >The reason is that type variables only get bound at value bindings; but you >attached the signature to an expression. > >To fix it, move the annotation to the pattern like this: > >theoremPlusAbelian ((SS a) :: (SNat a)) ((SS (b :: SNat b1)) :: (SNat b)) = > > >On 11/05/15 13:33, Nicholls, Mark wrote: >> Hello, >> >> >> >> I have written the below proof as an exercise. >> >> >> >> I want to explicitly annotate the proof with type variables ..but I >> cant get a line to work >> >> >> >>> {-# LANGUAGE DataKinds #-} >> >>> {-# LANGUAGE ExplicitForAll #-} >> >>> {-# LANGUAGE FlexibleContexts #-} >> >>> {-# LANGUAGE FlexibleInstances #-} >> >>> {-# LANGUAGE GADTs #-} >> >>> {-# LANGUAGE MultiParamTypeClasses #-} >> >>> {-# LANGUAGE PolyKinds #-} >> >>> {-# LANGUAGE StandaloneDeriving #-} >> >>> {-# LANGUAGE TypeFamilies #-} >> >>> {-# LANGUAGE TypeOperators #-} >> >>> {-# LANGUAGE UndecidableInstances #-} >> >>> {-# LANGUAGE ScopedTypeVariables #-} >> >> >> >>> import Prelude hiding (head, tail, (++), (+), replicate) >> >>> import qualified Prelude as P >> >> >> >>> data Nat where >> >>> Z :: Nat >> >>> S :: Nat -> Nat >> >> >> >>> data SNat (a :: Nat) where >> >>> SZ :: SNat 'Z >> >>> SS :: SNat a -> SNat ('S a) >> >> >> >> here a nice plus >> >> >> >>> type family (n :: Nat) :+ (m :: Nat) :: Nat >> >>> type instance Z :+ m = m >> >>> type instance (S n) :+ m = S (n :+ m) >> >> >> >> lets try to do >> >> >> >>> data val1 :== val2 where >> >>> Refl :: val :== val >> >> >> >> If I prove its abelian then we get it... >> >> >> >> the "proof" works if we remove the type annotation >> >> but I want the annotation to convince myself I know whats going on. >> >> >> >> >> >>> theoremPlusAbelian :: SNat a -> SNat b -> (a :+ b) :== (b :+ a) >> >>> theoremPlusAbelian (SZ :: SNat a) (SZ :: SNat b) = >> >>> -- forall 0 and 0 >> >>> (Refl :: (a :+ b) :== (b :+ a)) >> >>> theoremPlusAbelian ((SS a) :: SNat a) (SZ :: SNat b) = >> >>> -- forall a + 1 and 0 >> >>> case theoremPlusAbelian (a :: (a ~ 'S a1) => SNat a1) (SZ :: SNat >>> b) of >> >>> (Refl :: (a1 :+ b) :== (b :+ a1)) -> >> >>> (Refl :: (a :+ b) :== (b :+ a)) >> >>> theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = >> >>> -- forall 0 and a + 1 >> >>> case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat >>> b1) of >> >>> (Refl :: (a :+ b1) :== (b1 :+ a)) -> >> >>> (Refl :: (a :+ b) :== (b :+ a)) >> >>> -- cant seem to prove this... >> >>> theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = >> >>> -- forall a+1 and b+1 >> >>> -- 1st prove (a + 1) + b = b + (a + 1)...from above >> >>> case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => >> SNat b1) of >> >> >> >> THE COMMENTED LINE FAILS. >> >> >> >> Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) >> >> from the context (a ~ 'S a1) >> >> bound by a pattern with constructor >> >> SS :: forall (a :: Nat). SNat a -> SNat ('S a), >> >> in an equation for ?theoremPlusAbelian? >> >> at Cafe2.lhs:57:24-27 >> >> or from (b ~ 'S a2) >> >> bound by a pattern with constructor >> >> SS :: forall (a :: Nat). SNat a -> SNat ('S a), >> >> in an equation for ?theoremPlusAbelian? >> >> at Cafe2.lhs:57:45-48 >> >> NB: ?:+? is a type function, and may not be injective >> >> The type variable ?b1? is ambiguous >> >> Expected type: (a :+ a2) :== (a2 :+ a) >> >> Actual type: (a :+ b1) :== (b1 :+ a) >> >> Relevant bindings include >> >> b :: SNat a2 (bound at Cafe2.lhs:57:48) >> >> a :: SNat a1 (bound at Cafe2.lhs:57:27) >> >> In the pattern: Refl :: (a :+ b1) :== (b1 :+ a) >> >> In a case alternative: >> >> (Refl :: (a :+ b1) :== (b1 :+ a)) >> >> -> case theoremPlusAbelian a (SS b) of { >> >> Refl -> case theoremPlusAbelian a b of { Refl -> Refl } >> } >> >> In the expression: >> >> case >> >> theoremPlusAbelian ((SS a) :: SNat a) (b :: b ~ S b1 => SNat >> b1) >> >> of { >> >> (Refl :: (a :+ b1) :== (b1 :+ a)) >> >> -> case theoremPlusAbelian a (SS b) of { >> >> Refl -> case theoremPlusAbelian a b of { Refl -> ... } >> } } >> >> >> >> >> >> >> >>> -- (Refl :: (a :+ b1) :== (b1 :+ a)) -> >> >>> Refl -> >> >>> -- now prove a + (b + 1) = (b + 1) + a...from above >> >>> case theoremPlusAbelian a (SS b) of >> >>> Refl -> >> >>> -- now prove a + b = b + a >> >>> case theoremPlusAbelian a b of >> >>> -- which seems to have proved a + b = b + a >> >>> Refl -> Refl >> >> >> >> >> >> >> >> >> >> CONFIDENTIALITY NOTICE >> >> This e-mail (and any attached files) is confidential and protected by >> copyright (and other intellectual property rights). If you are not the >> intended recipient please e-mail the sender and then delete the email >> and any attached files immediately. Any further use or dissemination >> is prohibited. >> >> While MTV Networks Europe has taken steps to ensure that this email >> and any attachments are virus free, it is your responsibility to >> ensure that this message and any attachments are virus free and do not >> affect your systems / data. >> >> Communicating by email is not 100% secure and carries risks such as >> delay, data corruption, non-delivery, wrongful interception and >> unauthorised amendment. If you communicate with us by e-mail, you >> acknowledge and assume these risks, and you agree to take appropriate >> measures to minimise these risks when e-mailing us. >> >> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, >> Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions >> International, Be Viacom, Viacom International Media Networks and VIMN >> and Comedy Central are all trading names of MTV Networks Europe. MTV >> Networks Europe is a partnership between MTV Networks Europe Inc. and >> Viacom Networks Europe Inc. Address for service in Great Britain is >> 17-29 Hawley Crescent, London, NW1 8TT. >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. From taraathan at gmail.com Mon May 11 12:50:24 2015 From: taraathan at gmail.com (Tara Athan) Date: Mon, 11 May 2015 08:50:24 -0400 Subject: [Haskell-cafe] Multiway tree vs rose tree Message-ID: <5550A590.8060802@gmail.com> Hi - I am new to this list, and the only archive I could find is the Mailman archive, which is next to impossible to search. So this may be a topic that has been previously discussed, I don't know... The documentation at https://hackage.haskell.org/package/containers-0.3.0.0/docs/Data-Tree.html says that a rose tree is another name for multiway tree. But this is not true according to my understanding of the accepted definition in the CS literature (see e.g. http://doc.utwente.nl/66626/1/db-utwente-0000003528.pdf) Rose trees do not have labels at the nodes, only at the leaves (aka tips). There is another page https://wiki.haskell.org/Algebraic_data_type#Rose_tree that also uses this divergent definition. To further propagate this problem, the Wikipedia page https://en.wikipedia.org/wiki/Rose_tree uses these Haskell wiki pages as the definitive source. Tara From ivan.miljenovic at gmail.com Mon May 11 13:53:49 2015 From: ivan.miljenovic at gmail.com (Ivan Lazar Miljenovic) Date: Mon, 11 May 2015 23:53:49 +1000 Subject: [Haskell-cafe] Multiway tree vs rose tree In-Reply-To: <5550A590.8060802@gmail.com> References: <5550A590.8060802@gmail.com> Message-ID: On 11 May 2015 at 22:50, Tara Athan wrote: > Hi - I am new to this list, and the only archive I could find is the Mailman > archive, which is next to impossible to search. So this may be a topic that > has been previously discussed, I don't know... > > The documentation at > https://hackage.haskell.org/package/containers-0.3.0.0/docs/Data-Tree.html > says that a rose tree is another name for multiway tree. But this is not > true according to my understanding of the accepted definition in the CS > literature (see e.g. > http://doc.utwente.nl/66626/1/db-utwente-0000003528.pdf) > Rose trees do not have labels at the nodes, only at the leaves (aka tips). There are various different definitions of tree structures (I once started a literature review of this, but never finished it). Note that if you allow values in all nodes, you can always represent a tree where only leaves have values of type `a' as an arbitrary tree with nodes of type `Maybe a' (but you can't statically enforce this, at least with the definition in Data.Tree: for that, you would have to generalise the tree structure even more to have a distinct type variable just for the leaf nodes with a new constructor, thus complicating usage of the data structure). -- Ivan Lazar Miljenovic Ivan.Miljenovic at gmail.com http://IvanMiljenovic.wordpress.com From taraathan at gmail.com Mon May 11 15:09:22 2015 From: taraathan at gmail.com (Tara Athan) Date: Mon, 11 May 2015 11:09:22 -0400 Subject: [Haskell-cafe] Multiway tree vs rose tree In-Reply-To: References: <5550A590.8060802@gmail.com> Message-ID: <5550C622.8010207@gmail.com> Perhaps I need to clarify my remark. I am not in way suggesting that the code in Data-Tree.html be changed. I am suggesting that the documentation of the source and wiki pages be changed so that the structure is referred to (correctly) as a multiway tree, but not (incorrectly) as a rose tree. As to naming of trees, every published paper I have found so far that uses the term "rose tree" is consistent with the original definition from Meerten, who is the one who coined the name in the first place, to indicate a quite specialized tree that only has values at the tips, not the nodes. It is only in Haskell-related literature that it is stated that rose tree is the same as multiway tree. Since there is a perfectly good name for multiway tree, I don't see why there would be any need to have another name for it - why not let the name "rose tree" be used for what it was originally intended. BTW, I have a stake in this, as I am working on a case where I need (a generalization of ) rose trees, not multiway trees, and I ran across this different usage of "rose tree" during the literature search. (Generalized) rose trees are interesting in their own right because they are (or are isomorphic to, depending on your perspective) the free monad. When the functor used to generate the free monad is List, then it becomes a rose tree. Tara On 5/11/15 9:53 AM, Ivan Lazar Miljenovic wrote: > On 11 May 2015 at 22:50, Tara Athan wrote: >> Hi - I am new to this list, and the only archive I could find is the Mailman >> archive, which is next to impossible to search. So this may be a topic that >> has been previously discussed, I don't know... >> >> The documentation at >> https://hackage.haskell.org/package/containers-0.3.0.0/docs/Data-Tree.html >> says that a rose tree is another name for multiway tree. But this is not >> true according to my understanding of the accepted definition in the CS >> literature (see e.g. >> http://doc.utwente.nl/66626/1/db-utwente-0000003528.pdf) >> Rose trees do not have labels at the nodes, only at the leaves (aka tips). > There are various different definitions of tree structures (I once > started a literature review of this, but never finished it). Note > that if you allow values in all nodes, you can always represent a tree > where only leaves have values of type `a' as an arbitrary tree with > nodes of type `Maybe a' (but you can't statically enforce this, at > least with the definition in Data.Tree: for that, you would have to > generalise the tree structure even more to have a distinct type > variable just for the leaf nodes with a new constructor, thus > complicating usage of the data structure). > > From mike at proclivis.com Mon May 11 15:25:34 2015 From: mike at proclivis.com (Michael Jones) Date: Mon, 11 May 2015 09:25:34 -0600 Subject: [Haskell-cafe] FFI nested structs - malloc - free In-Reply-To: References: <4B005C46-BD05-4159-8224-46A3BE137D62@proclivis.com> <045561E9-F219-4E18-9CD7-71C08FD06D20@proclivis.com> Message-ID: <68B51F36-9870-4572-B5A4-79F9953B13CA@proclivis.com> GCC, well that is funny. The iPad looks like it made a spelling fix. Guess I have to reread what I type before sending :-) I?ll go off and try to implement from this and see how it goes. At least the principles are clear. I just have to look at how to do this in the context of a Storable instance. Thanks On May 11, 2015, at 12:47 AM, Alexey Shmalko wrote: > First note: it's not GCC, but Haskell's GC. > > Second, I believe it's not necessary to put strict annotations because all function parameters are evaluated before calling FFI function. It's just a general good practice to make all data fields strict unless there are reasons to do otherwise. > > On Sun, May 10, 2015, 18:58 Proclivis wrote: > Thanks guys, > > I looks like there are basically 2 ways to do this: > > 1) Build a structure of ForeignPtr with finalizers that will be freed whenever the GCC feels like it > 2) Nest allocations and the will free at the end of IO > > I noticed that in Real World Haskell the example of #1 has a ForeignPtr and ByteString in a data constructor, and both are bang noted as strict. Is this required before passing the data to a C-call to ensure it is evaluated or just a choice with the usual implications, such that with or without the evaluation of the C-call is well behaved? > > Mike > > Sent from my iPad > > On May 5, 2015, at 10:10 AM, Michael Steele wrote: > >> Michael, >> >> It looks like memory cleanup is being ignored in the example you linked to. newCString and mallocArray do not automatically free memory. >> >> When building nested structures simply in order to pass them to a few C functions, I like to use with* and alloca* functions whenever possible. >> >> The following (untested) example temporarily marshals a C structure containing 2 pointers to null-terminated strings, and passes that to a supplied action. 4-byte pointers and ints are assumed: >> >> > data Person = Person String String Int >> > withPerson :: Person -> (Ptr Person -> IO r) -> IO r >> > withPerson (Person fn ln age) f = >> > -- Haskell's layout rules allow you to line these all up vertically. >> > -- Just place all your allocations before the first 'do'. >> > withCString fn $ \pfn -> >> > withCString ln $ \pln -> >> > allocaBytes 12 $ \ptr -> do >> > pokeByteOff ptr 0 pfn >> > pokeByteOff ptr 4 pln >> > pokeByteOff ptr 8 age >> > f ptr >> >> In cases where you can't know ahead of time when the memory should be freed, you an use ForeignPtr. I think Real World Haskell gives an example of a nested structure marshaled in this way. By storing the ForeignPtr in a data object that gets carried around, you can guarantee that finalizes get called by the garbage collector only after you are done using them. >> >> I hope that helps. >> >> -- Michael Steele >> >> On Tue, May 5, 2015 at 6:22 AM, Michael Jones wrote: >> Alexey, >> >> That is an interesting insight. I suppose there are C API like that. >> >> In my case, the FFI calls ioctl, which calls i2cdev_ioctl, which calls i2cdev_ioctl_rdwr. >> >> The only function that can assume anything about the structure is i2cdev_ioctl_rdwr, which as you can see below copies the data, but does not free it. >> >> So in this particular case, I need the FFI to free it. >> >> On the other hand, I could write a wrapper in C that frees the structure if that is the way FFI is supposed to be used. >> >> Does anyone know if there is a FFI solution that would not require a wrapper? >> >> Mike >> >> static noinline int i2cdev_ioctl_rdrw(struct i2c_client *client, >> unsigned long arg) >> { >> struct i2c_rdwr_ioctl_data rdwr_arg; >> struct i2c_msg *rdwr_pa; >> u8 __user **data_ptrs; >> int i, res; >> >> if (copy_from_user(&rdwr_arg, >> (struct i2c_rdwr_ioctl_data __user *)arg, >> sizeof(rdwr_arg))) >> return -EFAULT; >> >> >> >> On May 4, 2015, at 10:40 PM, Alexey Shmalko wrote: >> >> > Hi! >> > >> > Disclaimer: I haven't worked much with FFI, so I'd like someone >> > confirmed my words. >> > >> > Seems that allocated memory in your example is supposed to be freed >> > from inside C. It's not a memory leak. >> > >> > If I understand correctly documentation [1], malloc/free are just a >> > simple wrappers around C's malloc/free. It's mallocForeignPtr that >> > sets finalizer. >> > >> > Best regards, >> > Alexey Shmalko >> > >> > [1]: https://downloads.haskell.org/~ghc/7.8.3/docs/html/users_guide/ffi-ghc.html >> > >> > On Tue, May 5, 2015 at 6:45 AM, Proclivis wrote: >> >> I should have mentioned GHC 7.8.3 Ubuntu 64bit >> >> >> >> Sent from my iPad >> >> >> >>> On May 4, 2015, at 9:42 PM, Proclivis wrote: >> >>> >> >>> FFI Gurus, >> >>> >> >>> I created a c2hs FFI of a nested C structure, where struct A has a pointer to a struct B. To do so, I used a malloc, but I am unsure if the memory will be freed when the resulting Ptr is freed. >> >>> >> >>> The example at this link uses the same technique, so it will serve as an example. >> >>> >> >>> https://github.com/ifesdjeen/haskell-ffi-tutorial/blob/master/src/Example.hsc >> >>> >> >>> Line 48 and 51 do the malloc and assign the pointer in the struct, from inside a Storable poke implementation. >> >>> >> >>> But, there is no explicit free, nor a finalizer. >> >>> >> >>> Will the memory be freed when the Ptr of the Storable is freed? >> >>> >> >>> If it is, it implies that some magic keeps track of mallocs inside a poke, and creates finalizers. Or, this example leaks. If it leaks, how do I create a finalizer from inside a poke implementation? >> >>> >> >>> Mike >> >>> >> >>> _______________________________________________ >> >>> Haskell-Cafe mailing list >> >>> Haskell-Cafe at haskell.org >> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> >> Haskell-Cafe mailing list >> >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> -- >> -- Michael Steele > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon May 11 16:00:02 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 11 May 2015 12:00:02 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <5550d203de05a@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Haskell Web Engineer at Front Row Education http://functionaljobs.com/jobs/8823-haskell-web-engineer-at-front-row-education Sr. Software Engineer at McGraw-Hill Education http://functionaljobs.com/jobs/8822-sr-software-engineer-at-mcgraw-hill-education Cheers, Sean Murphy FunctionalJobs.com From roma at ro-che.info Mon May 11 17:34:39 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 11 May 2015 20:34:39 +0300 Subject: [Haskell-cafe] using scoped type variables in proofs... In-Reply-To: References: <55509951.8050300@ro-che.info> Message-ID: <5550E82F.8090708@ro-che.info> Actually, I was wrong there. The paper "Lexically-scoped type variables" from 2004 claims that variables only get bound in value bindings, but GHC has changed its design since. The docs say expression signatures do bind type variables: http://bit.ly/1GZ7VQw On 11/05/15 15:43, Nicholls, Mark wrote: > That worked!.... > > But doesn?t seem to be true of all the previous cases! > > i.e. > > The b1 here is bound quite happily > >> theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = >> -- forall 0 and a + 1 >> case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of >> (Refl :: (a :+ b1) :== (b1 :+ a)) -> >> (Refl :: (a :+ b) :== (b :+ a)) > > yet > >> theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = >> -- forall a+1 and b+1 >> -- 1st prove (a + 1) + b = b + (a + 1)...from above >> case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => SNat b1) of >> (Refl :: (a :+ b1) :== (b1 :+ a)) -> > > Complains > > There seems little difference? > > >> GHC tells you that b1 is ambiguous, so that should tell you that it isn't getting >> bound in the case expression as you'd think. >> >> The reason is that type variables only get bound at value bindings; but you >> attached the signature to an expression. >> >> To fix it, move the annotation to the pattern like this: >> >> theoremPlusAbelian ((SS a) :: (SNat a)) ((SS (b :: SNat b1)) :: (SNat b)) = >> >> >> On 11/05/15 13:33, Nicholls, Mark wrote: >>> Hello, >>> >>> >>> >>> I have written the below proof as an exercise. >>> >>> >>> >>> I want to explicitly annotate the proof with type variables ..but I >>> cant get a line to work >>> >>> >>> >>>> {-# LANGUAGE DataKinds #-} >>> >>>> {-# LANGUAGE ExplicitForAll #-} >>> >>>> {-# LANGUAGE FlexibleContexts #-} >>> >>>> {-# LANGUAGE FlexibleInstances #-} >>> >>>> {-# LANGUAGE GADTs #-} >>> >>>> {-# LANGUAGE MultiParamTypeClasses #-} >>> >>>> {-# LANGUAGE PolyKinds #-} >>> >>>> {-# LANGUAGE StandaloneDeriving #-} >>> >>>> {-# LANGUAGE TypeFamilies #-} >>> >>>> {-# LANGUAGE TypeOperators #-} >>> >>>> {-# LANGUAGE UndecidableInstances #-} >>> >>>> {-# LANGUAGE ScopedTypeVariables #-} >>> >>> >>> >>>> import Prelude hiding (head, tail, (++), (+), replicate) >>> >>>> import qualified Prelude as P >>> >>> >>> >>>> data Nat where >>> >>>> Z :: Nat >>> >>>> S :: Nat -> Nat >>> >>> >>> >>>> data SNat (a :: Nat) where >>> >>>> SZ :: SNat 'Z >>> >>>> SS :: SNat a -> SNat ('S a) >>> >>> >>> >>> here a nice plus >>> >>> >>> >>>> type family (n :: Nat) :+ (m :: Nat) :: Nat >>> >>>> type instance Z :+ m = m >>> >>>> type instance (S n) :+ m = S (n :+ m) >>> >>> >>> >>> lets try to do >>> >>> >>> >>>> data val1 :== val2 where >>> >>>> Refl :: val :== val >>> >>> >>> >>> If I prove its abelian then we get it... >>> >>> >>> >>> the "proof" works if we remove the type annotation >>> >>> but I want the annotation to convince myself I know whats going on. >>> >>> >>> >>> >>> >>>> theoremPlusAbelian :: SNat a -> SNat b -> (a :+ b) :== (b :+ a) >>> >>>> theoremPlusAbelian (SZ :: SNat a) (SZ :: SNat b) = >>> >>>> -- forall 0 and 0 >>> >>>> (Refl :: (a :+ b) :== (b :+ a)) >>> >>>> theoremPlusAbelian ((SS a) :: SNat a) (SZ :: SNat b) = >>> >>>> -- forall a + 1 and 0 >>> >>>> case theoremPlusAbelian (a :: (a ~ 'S a1) => SNat a1) (SZ :: SNat >>>> b) of >>> >>>> (Refl :: (a1 :+ b) :== (b :+ a1)) -> >>> >>>> (Refl :: (a :+ b) :== (b :+ a)) >>> >>>> theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = >>> >>>> -- forall 0 and a + 1 >>> >>>> case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat >>>> b1) of >>> >>>> (Refl :: (a :+ b1) :== (b1 :+ a)) -> >>> >>>> (Refl :: (a :+ b) :== (b :+ a)) >>> >>>> -- cant seem to prove this... >>> >>>> theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = >>> >>>> -- forall a+1 and b+1 >>> >>>> -- 1st prove (a + 1) + b = b + (a + 1)...from above >>> >>>> case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => >>> SNat b1) of >>> >>> >>> >>> THE COMMENTED LINE FAILS. >>> >>> >>> >>> Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) >>> >>> from the context (a ~ 'S a1) >>> >>> bound by a pattern with constructor >>> >>> SS :: forall (a :: Nat). SNat a -> SNat ('S a), >>> >>> in an equation for ?theoremPlusAbelian? >>> >>> at Cafe2.lhs:57:24-27 >>> >>> or from (b ~ 'S a2) >>> >>> bound by a pattern with constructor >>> >>> SS :: forall (a :: Nat). SNat a -> SNat ('S a), >>> >>> in an equation for ?theoremPlusAbelian? >>> >>> at Cafe2.lhs:57:45-48 >>> >>> NB: ?:+? is a type function, and may not be injective >>> >>> The type variable ?b1? is ambiguous >>> >>> Expected type: (a :+ a2) :== (a2 :+ a) >>> >>> Actual type: (a :+ b1) :== (b1 :+ a) >>> >>> Relevant bindings include >>> >>> b :: SNat a2 (bound at Cafe2.lhs:57:48) >>> >>> a :: SNat a1 (bound at Cafe2.lhs:57:27) >>> >>> In the pattern: Refl :: (a :+ b1) :== (b1 :+ a) >>> >>> In a case alternative: >>> >>> (Refl :: (a :+ b1) :== (b1 :+ a)) >>> >>> -> case theoremPlusAbelian a (SS b) of { >>> >>> Refl -> case theoremPlusAbelian a b of { Refl -> Refl } >>> } >>> >>> In the expression: >>> >>> case >>> >>> theoremPlusAbelian ((SS a) :: SNat a) (b :: b ~ S b1 => SNat >>> b1) >>> >>> of { >>> >>> (Refl :: (a :+ b1) :== (b1 :+ a)) >>> >>> -> case theoremPlusAbelian a (SS b) of { >>> >>> Refl -> case theoremPlusAbelian a b of { Refl -> ... } >>> } } >>> >>> >>> >>> >>> >>> >>> >>>> -- (Refl :: (a :+ b1) :== (b1 :+ a)) -> >>> >>>> Refl -> >>> >>>> -- now prove a + (b + 1) = (b + 1) + a...from above >>> >>>> case theoremPlusAbelian a (SS b) of >>> >>>> Refl -> >>> >>>> -- now prove a + b = b + a >>> >>>> case theoremPlusAbelian a b of >>> >>>> -- which seems to have proved a + b = b + a >>> >>>> Refl -> Refl >>> >>> >>> >>> >>> >>> >>> >>> >>> >>> CONFIDENTIALITY NOTICE >>> >>> This e-mail (and any attached files) is confidential and protected by >>> copyright (and other intellectual property rights). If you are not the >>> intended recipient please e-mail the sender and then delete the email >>> and any attached files immediately. Any further use or dissemination >>> is prohibited. >>> >>> While MTV Networks Europe has taken steps to ensure that this email >>> and any attachments are virus free, it is your responsibility to >>> ensure that this message and any attachments are virus free and do not >>> affect your systems / data. >>> >>> Communicating by email is not 100% secure and carries risks such as >>> delay, data corruption, non-delivery, wrongful interception and >>> unauthorised amendment. If you communicate with us by e-mail, you >>> acknowledge and assume these risks, and you agree to take appropriate >>> measures to minimise these risks when e-mailing us. >>> >>> MTV Networks International, MTV Networks UK & Ireland, Greenhouse, >>> Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions >>> International, Be Viacom, Viacom International Media Networks and VIMN >>> and Comedy Central are all trading names of MTV Networks Europe. MTV >>> Networks Europe is a partnership between MTV Networks Europe Inc. and >>> Viacom Networks Europe Inc. Address for service in Great Britain is >>> 17-29 Hawley Crescent, London, NW1 8TT. >>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From eir at cis.upenn.edu Mon May 11 18:25:16 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 11 May 2015 14:25:16 -0400 Subject: [Haskell-cafe] using scoped type variables in proofs... In-Reply-To: References: Message-ID: In my opinion, ScopedTypeVariables is rough around the edges. Here's what (I think) is going on: In your problematic > (Refl :: (a :+ b1) :== (b1 :+ a)) -> you are binding variable b1 in a pattern. This is an allowed feature of ScopedTypeVariables. The problem is that b1's only occurrence appears under a type function, so GHC is skittish about letting this be a *definition* for b1. (For example, we don't like defining a term level function like `foo (n + k) = n - k`! That would be utterly ambiguous.) So the type annotation is rejected. But why, you ask, is this allowed a few lines previously? Here's the context: > theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = > -- forall 0 and a + 1 > case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of > (Refl :: (a :+ b1) :== (b1 :+ a)) -> This is accepted. But this is actually OK. We know that `a` is really `'Z` here. So, in the type annotation for `Refl`, GHC rewrites `a` with `'Z`. Then, it simplifies `'Z :+ b1` to `b1`. Aha! Now `b1` appears outside of a type function argument, so GHC is happy to use this as a definition. Note that such reasoning is not possible in the other case. How to fix? We need to define (that is, bind) b1 elsewhere. The following works for me: > theoremPlusAbelian ((SS a) :: (SNat a)) ((SS (b :: SNat b1))) = > case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => SNat b1) of > (Refl :: (a :+ b1) :== (b1 :+ a)) -> Note that in the first line of this snippet, I bind `b1` in the type signature, not `b`. This isn't exactly beautiful because it lacks parallelism with the other cases, but I didn't see another way. As an annoying corner case that you might stumble upon soon, when you say > case foo of > (Blah :: some_type) -> ... GHC will pretend you said > case foo :: some_type of > Blah -> ... but scope any variables in some_type over the right-hand side of the Blah pattern. This is probably not what you want, if Blah is a GADT type constructor that refines variables. This weird behavior extends to pattern-matches that match against an argument to a function. Note that this weird behavior is different to when you put a type annotation anywhere under the top-level of a pattern. Richard On May 11, 2015, at 6:33 AM, "Nicholls, Mark" wrote: > Hello, > > I have written the below proof as an exercise. > > I want to explicitly annotate the proof with type variables?..but I cant get a line to work? > > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE ExplicitForAll #-} > > {-# LANGUAGE FlexibleContexts #-} > > {-# LANGUAGE FlexibleInstances #-} > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE PolyKinds #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE UndecidableInstances #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > import Prelude hiding (head, tail, (++), (+), replicate) > > import qualified Prelude as P > > > data Nat where > > Z :: Nat > > S :: Nat -> Nat > > > data SNat (a :: Nat) where > > SZ :: SNat 'Z > > SS :: SNat a -> SNat ('S a) > > here a nice plus > > > type family (n :: Nat) :+ (m :: Nat) :: Nat > > type instance Z :+ m = m > > type instance (S n) :+ m = S (n :+ m) > > lets try to do > > > data val1 :== val2 where > > Refl :: val :== val > > If I prove its abelian then we get it... > > the "proof" works if we remove the type annotation > but I want the annotation to convince myself I know whats going on. > > > > theoremPlusAbelian :: SNat a -> SNat b -> (a :+ b) :== (b :+ a) > > theoremPlusAbelian (SZ :: SNat a) (SZ :: SNat b) = > > -- forall 0 and 0 > > (Refl :: (a :+ b) :== (b :+ a)) > > theoremPlusAbelian ((SS a) :: SNat a) (SZ :: SNat b) = > > -- forall a + 1 and 0 > > case theoremPlusAbelian (a :: (a ~ 'S a1) => SNat a1) (SZ :: SNat b) of > > (Refl :: (a1 :+ b) :== (b :+ a1)) -> > > (Refl :: (a :+ b) :== (b :+ a)) > > theoremPlusAbelian (SZ :: SNat a) ((SS a) :: SNat b) = > > -- forall 0 and a + 1 > > case theoremPlusAbelian (SZ :: SNat a) (a :: (b ~ 'S b1) => SNat b1) of > > (Refl :: (a :+ b1) :== (b1 :+ a)) -> > > (Refl :: (a :+ b) :== (b :+ a)) > > -- cant seem to prove this... > > theoremPlusAbelian ((SS a) :: (SNat a)) ((SS b) :: (SNat b)) = > > -- forall a+1 and b+1 > > -- 1st prove (a + 1) + b = b + (a + 1)...from above > > case theoremPlusAbelian ((SS a) :: (SNat a)) (b :: (b ~ 'S b1) => SNat b1) of > > THE COMMENTED LINE FAILS. > > Could not deduce ((b1 :+ 'S a1) ~ (a2 :+ 'S a1)) > from the context (a ~ 'S a1) > bound by a pattern with constructor > SS :: forall (a :: Nat). SNat a -> SNat ('S a), > in an equation for ?theoremPlusAbelian? > at Cafe2.lhs:57:24-27 > or from (b ~ 'S a2) > bound by a pattern with constructor > SS :: forall (a :: Nat). SNat a -> SNat ('S a), > in an equation for ?theoremPlusAbelian? > at Cafe2.lhs:57:45-48 > NB: ?:+? is a type function, and may not be injective > The type variable ?b1? is ambiguous > Expected type: (a :+ a2) :== (a2 :+ a) > Actual type: (a :+ b1) :== (b1 :+ a) > Relevant bindings include > b :: SNat a2 (bound at Cafe2.lhs:57:48) > a :: SNat a1 (bound at Cafe2.lhs:57:27) > In the pattern: Refl :: (a :+ b1) :== (b1 :+ a) > In a case alternative: > (Refl :: (a :+ b1) :== (b1 :+ a)) > -> case theoremPlusAbelian a (SS b) of { > Refl -> case theoremPlusAbelian a b of { Refl -> Refl } } > In the expression: > case > theoremPlusAbelian ((SS a) :: SNat a) (b :: b ~ S b1 => SNat b1) > of { > (Refl :: (a :+ b1) :== (b1 :+ a)) > -> case theoremPlusAbelian a (SS b) of { > Refl -> case theoremPlusAbelian a b of { Refl -> ... } } } > > > > > -- (Refl :: (a :+ b1) :== (b1 :+ a)) -> > > Refl -> > > -- now prove a + (b + 1) = (b + 1) + a...from above > > case theoremPlusAbelian a (SS b) of > > Refl -> > > -- now prove a + b = b + a > > case theoremPlusAbelian a b of > > -- which seems to have proved a + b = b + a > > Refl -> Refl > -------------- next part -------------- An HTML attachment was scrubbed... URL: From vogt.adam at gmail.com Mon May 11 22:29:01 2015 From: vogt.adam at gmail.com (adam vogt) Date: Mon, 11 May 2015 18:29:01 -0400 Subject: [Haskell-cafe] Automated Differentiation of Matrices (again) In-Reply-To: References: Message-ID: Hi Florian, The restriction Edward described is gone: here's an unboxed vector of ForwardDouble: . But I don't think there's been any work to make hmatrix's Field class have a ForwardDouble instance. I don't know of a ReverseDouble either. Regards, Adam On Mon, May 11, 2015 at 6:24 AM, Florian Hofmann < fhofmann at techfak.uni-bielefeld.de> wrote: > In [1](this) email thread Edward Kmett and Dominic Steinitz discuss the > state of interoperability of `ad` and `hmatric` (or `repa`) with Edward > hinting that the 4.0 line of `ad` might improve on the situation. > > Could someone elaborate on the state of affairs two years later? > > Florian > > [1]: > https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107561.html > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chpatrick at gmail.com Tue May 12 02:47:25 2015 From: chpatrick at gmail.com (Patrick Chilton) Date: Mon, 11 May 2015 19:47:25 -0700 Subject: [Haskell-cafe] ANN: codec: easy bidirectional serialization and first-class record construction Message-ID: Tired of writing complementary parseJSON/toJSON, peek/poke or Binary get/put functions? codec provides easy bidirectional serialization of plain Haskell records in any Applicative context. All you need to do is provide a de/serializer for every record field in any order you like, and you get a de/serializer for the whole structure. The type system ensures that you provide every record exactly once. It also includes a library for general record construction in an Applicative context, of which creating codecs is just one application. *JSON:* data User = User { username :: Text , userEmail :: Text , userLanguages :: [ Text ] , userReferrer :: Maybe User } deriving Show genFields ''User userCodec :: JSONCodec User userCodec = obj "user object" $ User $>> f_username >-< "user" >>> f_userEmail >-< "email" >>> f_userLanguages >-< "languages" >>> f_userReferrer >-< opt "referrer" instance FromJSON User where parseJSON = parseVal userCodec instance ToJSON User where toJSON = produceVal userCodec *Bit fields:* ipv4Codec :: BinaryCodec IPv4 ipv4Codec = toBytes $ IPv4 $>> f_version >-< word8 4 >>> f_ihl >-< word8 4 >>> f_dscp >-< word8 6 >>> f_ecn >-< word8 2 >>> f_totalLength >-< word16be 16 >>> f_identification >-< word16be 16 >>> f_flags >-< word8 3 >>> f_fragmentOffset >-< word16be 13 >>> f_timeToLive >-< word8 8 >>> f_protocol >-< word8 8 >>> f_headerChecksum >-< word16be 16 >>> f_sourceIP >-< word32be 32 >>> f_destIP >-< word32be 32 instance Binary IPv4 where get = parse ipv4Codec put = produce ipv4Codec The same types and combinators can be used to make Storable or Binary instances, or used with pretty much any de/serialization library. The implementation only uses a little bit of Template Haskell to generate the f_... structures for each field and the rest is very basic in terms of extensions (no DataKinds or type families needed). Please take a look at the docs and the examples. I'd love to get some feedback before I put it on Hackage. :) All the best, Patrick -------------- next part -------------- An HTML attachment was scrubbed... URL: From briand at aracnet.com Tue May 12 03:50:26 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Mon, 11 May 2015 20:50:26 -0700 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable Message-ID: <20150511205026.660785ac@cedar.deldotd.com> Hi, I'm using the FFT package (the FFTW bindings), and for a complex FFT I get back : (FFTWReal r, Ix i, Shapable i) => CArray i (Complex r) -> CArray i (Complex r) at first I thought I could use elems to get to a list and then do Vector.Storable.fromList to get back to a Vector.Storable. Unfortunately r is FFTWReal so i need to map over the returned list and get a haskell Double back from that. FFTWReal maps to RealFloat which i found, but i haven't found anything that will take a RealFloat and give me a Double. Was hoping someone might know how to do that, or maybe have a little cleaner way to get from the FFT data type over to Vector. Thanks. Brian From anton.kholomiov at gmail.com Tue May 12 04:53:44 2015 From: anton.kholomiov at gmail.com (Anton Kholomiov) Date: Tue, 12 May 2015 07:53:44 +0300 Subject: [Haskell-cafe] 3rd CFP FARM 2015 -- final reminder Message-ID: ************************************************************ 3rd CFP FARM 2015 3rd ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design Vancouver, Canada, 5 September, 2015 affiliated with ICFP 2015 Full Paper and Demo Abstract submission Deadline: 17 May ************************************************************ The ACM SIGPLAN International Workshop on Functional Art, Music, Modelling and Design (FARM) gathers together people who are harnessing functional techniques in the pursuit of creativity and expression. Functional Programming has emerged as a mainstream software development paradigm, and its artistic and creative use is booming. A growing number of software toolkits, frameworks and environments for art, music and design now employ functional programming languages and techniques. FARM is a forum for exploration and critical evaluation of these developments, for example to consider potential benefits of greater consistency, tersity, and closer mapping to a problem domain. FARM encourages submissions from across art, craft and design, including textiles, visual art, music, 3D sculpture, animation, GUIs, video games, 3D printing and architectural models, choreography, poetry, and even VLSI layouts, GPU configurations, or mechanical engineering designs. The language used need not be purely functional (?mostly functional? is fine), and may be manifested as a domain specific language or tool. Theoretical foundations, language design, implementation issues, and applications in industry or the arts are all within the scope of the workshop. Submissions are invited in two categories: * Full papers 5 to 12 pages using the ACM SIGPLAN template. FARM 2015 is an interdisciplinary conference, so a wide range of approaches are encouraged and we recognize that the appropriate length of a paper may vary considerably depending on the approach. However, all submissions must propose an original contribution to the FARM theme, cite relevant previous work, and apply appropriate research methods. * Demo abstracts Demo abstracts should describe the demonstration and its context, connecting it with the themes of FARM. A demo could be in the form of a short (10-20 minute) tutorial, presentation of work-in-progress, an exhibition of some work, or even a performance. Abstracts should be no longer than 2 pages, using the ACM SIGPLAN template and will be subject to a light-touch peer review. If you have any questions about what type of contributions that might be suitable, or anything else regarding submission or the workshop itself, please contact the organisers at: farm-2015 at easychair.org KEY DATES: Full Paper and Demo Abstract submission Deadline: 17 May Author Notification: 26 June Camera Ready: 19 July Workshop: 5 September SUBMISSION All papers and demo abstracts must be in portable document format (PDF), using the ACM SIGPLAN style guidelines. The text should be in a 9-point font in two columns. The submission itself will be via EasyChair: https://easychair.org/conferences/?conf=farm2015 PUBLICATION Accepted papers will be included in the formal proceedings published by ACM Press and will also be made available through the the ACM Digital Library; see http://authors.acm.org/main.cfm for information on the options available to authors. Authors are encouraged to submit auxiliary material for publication along with their paper (source code, data, videos, images, etc.); authors retain all rights to the auxiliary material. WORKSHOP ORGANISATION Workshop Chair: Henrik Nilsson, University of Nottingham Program Chair: David Janin, University of Bordeaux Publicity Chair: Samuel Aaron, University of Cambridge Program Committee: Samuel Aaron, University of Cambridge Jean Bresson, IRCAM Paris David Broman, KTH and UC Berkeley David Janin (chair), University of Bordeaux Anton Kholomiov, Orffeus instrumental ensemble Moscow Alex Mclean, University of Leeds Carin Meier, Outpace Systems Henrik Nilsson, University of Nottingham Yann Orlarey, GRAME Lyon Donya Quick, Yale University Shigeki Sagayama, Meiji University Chung-chieh Shan, Indiana University Michael Sperber, Active Group GmbH Bodil Stokke, FutureAdLabs For further details, see the FARM website: http://functional-art.org -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Tue May 12 07:20:34 2015 From: sean.leather at gmail.com (Sean Leather) Date: Tue, 12 May 2015 09:20:34 +0200 Subject: [Haskell-cafe] Multiway tree vs rose tree In-Reply-To: <5550C622.8010207@gmail.com> References: <5550A590.8060802@gmail.com> <5550C622.8010207@gmail.com> Message-ID: On Mon, May 11, 2015 at 5:09 PM, Tara Athan wrote: > As to naming of trees, every published paper I have found so far that uses > the term "rose tree" is consistent with the original definition from > Meerten, who is the one who coined the name in the first place, to indicate > a quite specialized tree that only has values at the tips, not the nodes. I believe you mean Lambert Meertens here and are referring to the reference ?First steps towards the theory of rose trees? [1]. Unfortunately, this article does not seem to be available online, but it does appear that articles citing Meertens use your definition. It is only in Haskell-related literature that it is stated that rose tree > is the same as multiway tree. Since there is a perfectly good name for > multiway tree, I don't see why there would be any need to have another name > for it - why not let the name "rose tree" be used for what it was > originally intended. I don't think there is a One True Definition for a rose tree. For example, Ralf Hinze uses a definition like the Data.Tree one in ?Polytypic Functions Over Nested Datatypes? [2]. Also, Meertens himself uses the value-at-the-tips definition in a later publication [3]. BTW, I have a stake in this, as I am working on a case where I need (a > generalization of ) rose trees, not multiway trees, and I ran across this > different usage of "rose tree" during the literature search. I wouldn't worry about which definition is the ?right? one. Both are equally acceptable. Regards, Sean [1] CWI, Amsterdam, 1988, Draft Rept. [SD-008]. [2] Discrete Mathematics and Theoretical Computer Science 3, 1999, 193?214. http://www.dmtcs.org/dmtcs-ojs/index.php/dmtcs/article/view/109 [3] Calculate Polytypically! Proceedings of the 8th International Symposium on Programming Languages: Implementations, Logics, and Programs Pages, 1996, 1-16. http://www.kestrel.edu/home/people/meertens/publications/papers/Calculate_polytypically.pdf -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean.leather at gmail.com Tue May 12 07:25:43 2015 From: sean.leather at gmail.com (Sean Leather) Date: Tue, 12 May 2015 09:25:43 +0200 Subject: [Haskell-cafe] Multiway tree vs rose tree In-Reply-To: References: <5550A590.8060802@gmail.com> <5550C622.8010207@gmail.com> Message-ID: On Tue, May 12, 2015 at 9:20 AM, Sean Leather wrote: > Also, Meertens himself uses the value-at-the-tips definition in a later > publication [3]. Correction. I meant to say he uses a value-at-the-nodes definition: > data Rose a = fork a (List(Rose a)) Regards, Sean -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Tue May 12 08:43:33 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Tue, 12 May 2015 10:43:33 +0200 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: <20150511205026.660785ac@cedar.deldotd.com> References: <20150511205026.660785ac@cedar.deldotd.com> Message-ID: On Tue, 12 May 2015 05:50:26 +0200, wrote: > (FFTWReal r, Ix i, Shapable i) => CArray i (Complex r) -> CArray i > (Complex r) : > FFTWReal maps to RealFloat which i found, but i haven't found anything > that will take a RealFloat and give me a Double. L.S., You could use something like: toDouble :: FFTWReal r => r -> Double toDouble = id Or add the type of the functions you create to your program. Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From roma at ro-che.info Tue May 12 09:23:10 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Tue, 12 May 2015 12:23:10 +0300 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: References: <20150511205026.660785ac@cedar.deldotd.com> Message-ID: <5551C67E.2080108@ro-che.info> On 12/05/15 11:43, Henk-Jan van Tuyl wrote: > You could use something like: > toDouble :: FFTWReal r => r -> Double > toDouble = id I don't think this is going to typecheck. You probably had something like this in mind: toDouble :: (forall r . FFTWReal r => r) -> Double toDouble d = d Here's a simpler way to do that: toDouble :: Double -> Double toDouble = id Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From atze at uu.nl Tue May 12 09:58:53 2015 From: atze at uu.nl (Atze Dijkstra) Date: Tue, 12 May 2015 11:58:53 +0200 Subject: [Haskell-cafe] Call for participation: Applied Functional Programming (AFP) Summerschool 6-17 July 2015, Utrecht, Netherlands Message-ID: =========== AFP Summerschool 2015 =========== Applied Functional Programming (AFP) Summerschool July 6-17, 2015 Utrecht University, Department of Information and Computing Sciences Utrecht, The Netherlands Summerschool & registration website: http://www.utrechtsummerschool.nl/courses/science/applied-functional-programming-in-haskell AFP website : http://www.cs.uu.nl/wiki/USCS contact : Uscs-afp at lists.science.uu.nl *** The 2015 edition of the Applied Functional Programming (AFP) Summerschool in Utrecht, Netherlands will be held from 6-17 July 2015. The summerschool teaches Haskell on both beginners and advanced levels via lectures and lab exercises. More info can be found via the references above, included here is a summary from the summerschool info: ``Typed functional programming in Haskell allows for the development of compact programs in minimal time and with maximal guarantees about robustness and correctness. The course introduces Haskell as well as its theoretical underpinnings such as typed lambda calculus, and Damas-Milner type inference. There is ample opportunity to put this all in practice during lab sessions. Typed functional programming languages allow for the development of robust, concise programs in a short amount of time. The key advantages are higher-order functions as an abstraction mechanism, and an advanced type system for safety and reusability. This course introduces Haskell, a state-of-the-art functional programming language, together with some of its theoretical background, such as typed lambda calculi, referential transparency, Damas-Milner type inference, type level programming, and functional design patterns. We will combine this with applications of functional programming, concentrating on topics such as language processing, building graphical user interfaces, networking, databases, and programming for the web. The goal of the course is not just to teach the programming language and underlying theory, but also to learn about the Haskell community and to get hands-on experience by doing lab exercises or a Haskell project of your own.'' *** This year is somewhat special in that the Tour de France starts in Utrecht the weekend before the start of the summerschool. It is an opportunity for enjoying the related festivities. It also implies that housing may be more difficult the weekend before the summerschool, something to keep in mind when you wait with registration until the latest. regards, - Atze - Atze Dijkstra, Department of Information and Computing Sciences. /|\ Utrecht University, PO Box 80089, 3508 TB Utrecht, Netherlands. / | \ Tel.: +31-30-2534118/1454 | WWW : http://www.cs.uu.nl/~atze . /--| \ Fax : +31-30-2513971 .... | Email: atze at uu.nl ............... / |___\ _______________________________________________ Haskell mailing list Haskell at haskell.org http://www.haskell.org/mailman/listinfo/haskell From jake.mcarthur at gmail.com Tue May 12 11:26:16 2015 From: jake.mcarthur at gmail.com (Jake McArthur) Date: Tue, 12 May 2015 11:26:16 +0000 Subject: [Haskell-cafe] Is this functional reactive programming In-Reply-To: References: Message-ID: This looks more like self-adjusting computation than functional reactive programming. There's a lot of good literature on this topic that's pretty easy to find on Google. Hope this helps! On 8:36PM, Sun, May 10, 2015 Clinton Mead wrote: > What I want to be able to do is something like this: > > do > x <- newSTRef 2 > y <- newSTRef 3 > z <- letSTRef (x + y) > r1 <- readSTRef z > writeSTRef x 5 > r2 <- readSTRef z > return (r1, r2) > > This should return (6,15) > > The "letSTRef" is what's new. The value it returns can change based on the > parts that make up it's function changing. > > I understand this syntax above isn't going to work (I'd have to use > applicative at least I'd imagine) but my main question is that does > something like this exist? Is it functional reactive programming or is it > something else? > > I don't want to be reinventing the wheel if this type of idea is already > implemented but I haven't recognised it. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Tue May 12 13:58:44 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Tue, 12 May 2015 20:58:44 +0700 Subject: [Haskell-cafe] Is this functional reactive programming In-Reply-To: References: Message-ID: For the record, 'self-adjusting computation' is also known as 'incremental computation'. The latter term is overloaded, as you might imagine. -- Kim-Ee On Tue, May 12, 2015 at 6:26 PM, Jake McArthur wrote: > This looks more like self-adjusting computation than functional reactive > programming. There's a lot of good literature on this topic that's pretty > easy to find on Google. Hope this helps! > > On 8:36PM, Sun, May 10, 2015 Clinton Mead wrote: > >> What I want to be able to do is something like this: >> >> do >> x <- newSTRef 2 >> y <- newSTRef 3 >> z <- letSTRef (x + y) >> r1 <- readSTRef z >> writeSTRef x 5 >> r2 <- readSTRef z >> return (r1, r2) >> >> This should return (6,15) >> >> The "letSTRef" is what's new. The value it returns can change based on >> the parts that make up it's function changing. >> >> I understand this syntax above isn't going to work (I'd have to use >> applicative at least I'd imagine) but my main question is that does >> something like this exist? Is it functional reactive programming or is it >> something else? >> >> I don't want to be reinventing the wheel if this type of idea is already >> implemented but I haven't recognised it. >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leza.ml at fecrd.cujae.edu.cu Tue May 12 15:19:48 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Tue, 12 May 2015 11:19:48 -0400 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: <20150511205026.660785ac@cedar.deldotd.com> References: <20150511205026.660785ac@cedar.deldotd.com> Message-ID: <55521A14.9040509@fecrd.cujae.edu.cu> On 05/11/2015 11:50 PM, briand at aracnet.com wrote: > FFTWReal maps to RealFloat which i found, but i haven't found anything that will take a RealFloat and give me a Double. Double` is `RealFloat`, so it is `Fractional`. Every FFTWReal is a `Real` too, so you can use realToFrac to map from FFTWReal to Double: fftwRealToDouble :: FFTWReal r => r -> Double fftwRealToDouble = realToFrac Regards. -- Leza Morais Lutonda, Lemol-C http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu From jeffbrown.the at gmail.com Tue May 12 20:19:09 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Tue, 12 May 2015 13:19:09 -0700 Subject: [Haskell-cafe] evaluate arbitrary code + mutable variables Message-ID: I wrote a graph-like data type, with some functions for adding statements and relationships between statements. (It's different from a graph in that there's no edge/vertex distinction; there are only statements, but a statement might refer to other statements.) Currently I'm using them in GHCI. Because it does not allow one to change a variable, I keep having to do things like this: let g0 = emptyDocument let s1 = newStatement ... let g1 = addStatement s1 g0 let s2 = newStatement ... let g2 = addStatement s2 g1 ... If I wrote a standalone application, I could use mutable variables, so I would not have to define a new object every time I want to modify an existing one. However I like being able to type in arbitrary code into GHCI. Can one have both of those at once? That is, could I either (1) use MVars from within GHCI, or (2) write a standalone app that lets the user evaluate arbitrary Haskell? -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeffbrown.the at gmail.com Wed May 13 00:02:35 2015 From: jeffbrown.the at gmail.com (Jeffrey Brown) Date: Tue, 12 May 2015 17:02:35 -0700 Subject: [Haskell-cafe] evaluate arbitrary code + mutable variables In-Reply-To: References: Message-ID: Half solved! David Gladstein pointed out that GHCI's "it" variable can at least sometimes solve the problem: Prelude System.IO> let x = 3 Prelude System.IO> x 3 Prelude System.IO> let x = it + 1 Prelude System.IO> x 4 Then I discovered that in GHCI one can bind monadically: Prelude> x <- return 3 Prelude> x <- return $ x + 1 Prelude> x 4 Prelude> x <- getLine This line was user input, not computer output. Prelude> x "This line was user input, not computer output." Prelude> I don't remember seeing anyone demonstrate it; perhaps it is deprecated. I would still very much like to know whether and if so how it is possible to let the user evaluate arbitrary haskell when running compiled code. On Tue, May 12, 2015 at 1:19 PM, Jeffrey Brown wrote: > I wrote a graph-like data type, with some functions for adding statements > and relationships between statements. (It's different from a graph in that > there's no edge/vertex distinction; there are only statements, but a > statement might refer to other statements.) > > Currently I'm using them in GHCI. Because it does not allow one to change > a variable, I keep having to do things like this: > let g0 = emptyDocument > let s1 = newStatement ... > let g1 = addStatement s1 g0 > let s2 = newStatement ... > let g2 = addStatement s2 g1 > ... > If I wrote a standalone application, I could use mutable variables, so I > would not have to define a new object every time I want to modify an > existing one. However I like being able to type in arbitrary code into GHCI. > > Can one have both of those at once? That is, could I either (1) use MVars > from within GHCI, or (2) write a standalone app that lets the user evaluate > arbitrary Haskell? > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aditya.siram at gmail.com Wed May 13 00:05:29 2015 From: aditya.siram at gmail.com (aditya siram) Date: Tue, 12 May 2015 19:05:29 -0500 Subject: [Haskell-cafe] Start GHCI with a static library In-Reply-To: References: Message-ID: Any ideas? -deech On Sat, May 2, 2015 at 10:24 AM, aditya siram wrote: > Hi all, > I have a Haskell library I'd like to load up in GHCI along with a > statically linked C library (libblah.a) . Is there any way to do this? My > Googling only turns up instructions on loading a shared library > (libblah.so). > > Thanks! > -deech > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Wed May 13 00:30:11 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Tue, 12 May 2015 19:30:11 -0500 Subject: [Haskell-cafe] Start GHCI with a static library In-Reply-To: References: Message-ID: You need a GHC built for this, I think. Using this setup: https://ghc.haskell.org/trac/ghc/ticket/5371 [callen at atlantis ~/Work/exist]$ ghci -L. -lfoo testlink.hs GHCi, version 7.10.1: http://www.haskell.org/ghc/ :? for help ghc: panic! (the 'impossible' happened) (GHC version 7.10.1 for x86_64-unknown-linux): Loading archives not supported [callen at atlantis ~/Work/exist]$ /opt/ghc/7.6.3/bin/ghci -L. -lfoo testlink.hs GHCi, version 7.6.3: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static archive) ./libfoo.a ... done final link ... done [1 of 1] Compiling TestLink ( testlink.hs, interpreted ) Ok, modules loaded: TestLink. Prelude> Leaving GHCi. [callen at atlantis ~/Work/exist]$ /opt/ghc/7.8.4/bin/ghci -L. -lfoo testlink.hs GHCi, version 7.8.4: http://www.haskell.org/ghc/ :? for help Loading package ghc-prim ... linking ... done. Loading package integer-gmp ... linking ... done. Loading package base ... linking ... done. Loading object (static archive) ./libfoo.a ... ghc: panic! (the 'impossible' happened) (GHC version 7.8.4 for x86_64-unknown-linux): Loading archives not supported (ditto 7.8.3) https://github.com/ghc/ghc/blob/master/compiler/ghci/Linker.hs#L444-L450 https://mail.haskell.org/pipermail/glasgow-haskell-users/2014-October/thread.html#25338 Respective versions of GHC are all from hvr's Ubuntu PPA. These are the versions I have installed: ghc-7.10.1 install ghc-7.6.3 install ghc-7.8.3 install ghc-7.8.4 install Afraid I don't know much about linkers or GHC dev so that's I all I can do for you at this time. Cheers, Chris On Tue, May 12, 2015 at 7:05 PM, aditya siram wrote: > Any ideas? > -deech > > On Sat, May 2, 2015 at 10:24 AM, aditya siram > wrote: > >> Hi all, >> I have a Haskell library I'd like to load up in GHCI along with a >> statically linked C library (libblah.a) . Is there any way to do this? My >> Googling only turns up instructions on loading a shared library >> (libblah.so). >> >> Thanks! >> -deech >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Wed May 13 03:42:32 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Tue, 12 May 2015 23:42:32 -0400 Subject: [Haskell-cafe] Start GHCI with a static library In-Reply-To: References: Message-ID: adityah, if the library is cabalized, do cabal configure --extra-lib-dirs=$PATHtoArchive and assuming you have the right foreign import code, things should work fine. (or the equivalient .cabal file extra lib dirs field with can be a relative path within the package). then cabal repl should also presumably work. if you then wanna use ghci directly, try invoking cabal repl with the verbose flag (-v) to see how its setting up ghci. if your ffi bindings dont work in cabal repl, thats probably valid a bug report. (at least on some platforms) On Sat, May 2, 2015 at 11:24 AM, aditya siram wrote: > Hi all, > I have a Haskell library I'd like to load up in GHCI along with a > statically linked C library (libblah.a) . Is there any way to do this? My > Googling only turns up instructions on loading a shared library > (libblah.so). > > Thanks! > -deech > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpmoresmau at gmail.com Wed May 13 15:16:01 2015 From: jpmoresmau at gmail.com (JP Moresmau) Date: Wed, 13 May 2015 17:16:01 +0200 Subject: [Haskell-cafe] IDE-backend + Atom editor Message-ID: Hello, when the open sourcing of IDE-backend was announced ( https://www.fpcomplete.com/blog/2015/03/announce-ide-backend), one thing mentioned was Atom support, and indeed the home page for the client ( https://github.com/chrisdone/ide-backend-client) mentions Atom. But is there a project out there I can use that brings the two together? The ide-haskell (https://atom.io/packages/ide-haskell) Atom plugin still relies on ghc-mod as far as I can tell. I saw edsko tutorial on writing Atom plugin in Haskell ( http://edsko.net/2015/02/14/atom-haskell/), so it seem we are tentalizingly close to have Atom + Haskell implemented in Haskell, and I'd like to give it a go if there's anything available out there (and maybe help if needed). Thanks! JP -- JP Moresmau http://jpmoresmau.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From j at functorgroup.com Wed May 13 17:22:43 2015 From: j at functorgroup.com (Johan Glimming) Date: Wed, 13 May 2015 19:22:43 +0200 Subject: [Haskell-cafe] Job openings for Haskell, O'Caml programmers at Swedish spin-off startup Message-ID: <41FF352A-7B64-4BBA-8F97-369259E5E3EB@functorgroup.se> Hi Haskell people, and beyond, Summary: Openings for software developers highly trained in functional programming, six developer or more entangled in our "teams", three with considerable Haskell, O'Caml experience, talents, entrepreneurial mind-set, and three for Scala, spear-edge Functor Consulting branch, with out-standing industrial track-records, as the new constructive programming paradigm is gradually unleashed to the software industry from Functor Group AB, Sweden. Keywords: type theory, dependent type, new programming paradigm, static analysis with dependent types, DDD-like development with solid Scandinavian-style Martin-L?f type theory operational semantics in the VM above LLVM, Haskell, O?Caml, embedded systems is one submarket. Official call with the details here: https://goo.gl/vdu1d4 We will always work closely with academia and internships, MSc theses and research collaborations are always interesting though right now we are focused on delivering to customers and building up the business meaning larger research projects are not yet possible, a large-scale EU project planned but not for this year. You?re most welcome to apply via jobs at functor.se . See the call for details! Yours Sincerely, Johan Glimming ? Dr Johan Glimming Chief Technical Officer and Co-Founder at Functor AB and Functor Group AB LinkedIn profile: www.linkedin.com/in/glimming Mobile: +46-76-7646000 (direct) Main: +46-8-55005500 Functor AB, Box 7070, 164 07 Kista, SWEDEN Web: www.functorgroup.com Twitter: @functors -------------- next part -------------- An HTML attachment was scrubbed... URL: From mihai.maruseac at gmail.com Wed May 13 19:30:55 2015 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Wed, 13 May 2015 15:30:55 -0400 Subject: [Haskell-cafe] all for Contributions - Haskell Communities and Activities Report, May 2015 edition (28th edition) In-Reply-To: References: Message-ID: On Fri, Apr 17, 2015 at 10:04 PM, Mihai Maruseac wrote: > We would like to collect contributions for the 28th edition of the > > ============================================================ > Haskell Communities & Activities Report > > http://www.haskell.org/haskellwiki/Haskell_Communities_and_Activities_Report > > Submission deadline: 17 May 2015 > > (please send your contributions to hcar at haskell.org, > in plain text or LaTeX format) > ============================================================ Hi all. Just a small reminder that the deadline for submissions is at the end of this week. -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya From mainland at cs.drexel.edu Thu May 14 00:35:42 2015 From: mainland at cs.drexel.edu (Geoffrey Mainland) Date: Wed, 13 May 2015 20:35:42 -0400 Subject: [Haskell-cafe] CFP: Extended Deadline: Functional High-Performance Computing (held with ICFP) Message-ID: <5553EDDE.5030909@cs.drexel.edu> ====================================================================== CALL FOR PAPERS FHPC 2015 The 4th ACM SIGPLAN Workshop on Functional High-Performance Computing Vancouver, British Columbia, Canada, Canada September 3, 2015 https://sites.google.com/site/fhpcworkshops/ Co-located with the International Conference on Functional Programming (ICFP 2015) EXTENDED Submission Deadline: Friday, 22 May, 2015 (anywhere on earth) ====================================================================== The FHPC workshop aims at bringing together researchers exploring uses of functional (or more generally, declarative or high-level) programming technology in application domains where high performance is essential. The aim of the meeting is to enable sharing of results, experiences, and novel ideas about how high-level, declarative specifications of computationally challenging problems can serve as maintainable and portable code that approaches (or even exceeds) the performance of machine-oriented imperative implementations. All aspects of performance critical programming and parallel programming are in-scope for the workshop, irrespective of hardware target. This includes both traditional large-scale scientific computing (HPC), as well as work targeting single node systems with SMPs, GPUs, FPGAs, or embedded processors. It is becoming apparent that radically new and well founded methodologies for programming such systems are required to address their inherent complexity and to reconcile execution performance with programming productivity. Proceedings: ============ Accepted papers will be published by the ACM and will appear in the ACM Digital Library. * Submissions due: Friday, 22 May, 2015 (anywhere on earth) * Author notification: Friday, 26 June, 2015 * Final copy due: Sunday, 19 July, 2015 Submitted papers must be in portable document format (PDF), formatted according to the ACM SIGPLAN style guidelines (2 column, 9pt format). See http://www.sigplan.org/authorInformation.htm for more information and style files. Typical papers are expected to be 8 pages (but up to four additional pages are permitted). Contributions to FHPC 2015 should be submitted via Easychair, at the following URL: * https://www.easychair.org/conferences/?conf=fhpc15 The submission site is now open. The FHPC workshops adhere to the ACM SIGPLAN policies regarding programme committee contributions and republication. Any paper submitted must adhere to ACM SIGPLAN's republication policy. PC member submissions are welcome, but will be reviewed to a higher standard. http://www.sigplan.org/Resources/Policies/Review http://www.sigplan.org/Resources/Policies/Republication Travel Support: =============== Student attendees with accepted papers can apply for a SIGPLAN PAC grant to help cover travel expenses. PAC also offers other support, such as for child-care expenses during the meeting or for travel costs for companions of SIGPLAN members with physical disabilities, as well as for travel from locations outside of North America and Europe. For details on the PAC programme, see its web page (http://www.sigplan.org/PAC.htm). Programme Committee: ==================== Tiark Rompf (co-chair), Purdue University, USA Geoffrey Mainland (co-chair), Drexel University, USA Kevin Brown Stanford University, USA James Cheney University of Edinburgh, UK Albert Cohen INRIA, France David Duke University of Leeds, UK Yukiyoshi Kameyama University of Tsukuba, Japan Gabriele Keller University of New South Wales, Australia Paul H J Kelly Imperial College London, UK Trevor L. Mcdonell Indiana University, USA Greg Michaelson Heriot-Watt University, UK Cosmin E. Oancea University of Copenhagen, Denmark Markus Pueschel ETH Zurich, Switzerland Sukyoung Ryu KAIST, Korea Alexander Slesarenko Huawei, Russia Josef Svenningsson Chalmers University of Technology, Sweden From briand at aracnet.com Thu May 14 04:51:21 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Wed, 13 May 2015 21:51:21 -0700 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: <55521A14.9040509@fecrd.cujae.edu.cu> References: <20150511205026.660785ac@cedar.deldotd.com> <55521A14.9040509@fecrd.cujae.edu.cu> Message-ID: <20150513215121.1f853d0a@cedar.deldotd.com> On Tue, 12 May 2015 11:19:48 -0400 Leza Morais Lutonda wrote: > On 05/11/2015 11:50 PM, briand at aracnet.com wrote: > > FFTWReal maps to RealFloat which i found, but i haven't found anything that will take a RealFloat and give me a Double. > Double` is `RealFloat`, so it is `Fractional`. Every FFTWReal is a > `Real` too, so you can use realToFrac to map from FFTWReal to Double: > > fftwRealToDouble :: FFTWReal r => r -> Double > fftwRealToDouble = realToFrac > > Regards. > Well what I was _really_ trying to do was to get to a Vector of (Complex Double). Interestingly, the following, where ys is type Vector.Storable (Complex Double), ys_array = listArray (0, V.length ys -1) (V.toList ys) y = V.fromList $ map (\z -> realPart z :+ imagPart z) (elems (dft ys_array)) worked just fine, but it's not obvious to me that it should have. Seems like the realPart/imagPart should have failed to work because the argument is not Complex Double it's Complex FFTWReal, so I should have ended up with (Complex FFTWReal) when I really wanted (Complex Double) and fail. BTW, it seems to me that it would be awfully nice if FFT delivered results as Vectors instead of the Array thingy. It looked to me like V.Storable is something which is supposed to ease the marshalling to and from the C world. Would it be a whole lot of work to change the interface to Vector.Storable ? Among other advantages, it makes interfacing to HMatrix easier. Thanks, Brian From eleventynine at gmail.com Thu May 14 05:57:28 2015 From: eleventynine at gmail.com (Mike Ledger) Date: Thu, 14 May 2015 15:57:28 +1000 Subject: [Haskell-cafe] evaluate arbitrary code + mutable variables In-Reply-To: References: Message-ID: It's maybe a bit of a hack, but you can just shadow names in GHCi. (You might want to :set -fno-warn-name-shadowing so you aren't harassed with warnings). e.g. >>> let x = 423 >>> let y = x + 123 >>> let x = y + 54 but this breaks down if you try something like >>> let x = x + 1 expecting it to increment x (it'll just recurse infinitely) For actual variables, probably just use an IORef, or venture into state monads (and use :{ and :} to enter multi-line expressions in ghci) Cheers, Mike On Wed, May 13, 2015 at 10:02 AM, Jeffrey Brown wrote: > Half solved! > > David Gladstein pointed out that GHCI's "it" variable can at least > sometimes solve the problem: > > Prelude System.IO> let x = 3 > Prelude System.IO> x > 3 > Prelude System.IO> let x = it + 1 > Prelude System.IO> x > 4 > > Then I discovered that in GHCI one can bind monadically: > > Prelude> x <- return 3 > Prelude> x <- return $ x + 1 > Prelude> x > 4 > > Prelude> x <- getLine > This line was user input, not computer output. > Prelude> x > "This line was user input, not computer output." > Prelude> > > I don't remember seeing anyone demonstrate it; perhaps it is deprecated. > > I would still very much like to know whether and if so how it is possible > to let the user evaluate arbitrary haskell when running compiled code. > > On Tue, May 12, 2015 at 1:19 PM, Jeffrey Brown > wrote: > >> I wrote a graph-like data type, with some functions for adding statements >> and relationships between statements. (It's different from a graph in that >> there's no edge/vertex distinction; there are only statements, but a >> statement might refer to other statements.) >> >> Currently I'm using them in GHCI. Because it does not allow one to change >> a variable, I keep having to do things like this: >> let g0 = emptyDocument >> let s1 = newStatement ... >> let g1 = addStatement s1 g0 >> let s2 = newStatement ... >> let g2 = addStatement s2 g1 >> ... >> If I wrote a standalone application, I could use mutable variables, so I >> would not have to define a new object every time I want to modify an >> existing one. However I like being able to type in arbitrary code into GHCI. >> >> Can one have both of those at once? That is, could I either (1) use MVars >> from within GHCI, or (2) write a standalone app that lets the user evaluate >> arbitrary Haskell? >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Thu May 14 06:25:41 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Wed, 13 May 2015 23:25:41 -0700 Subject: [Haskell-cafe] IDE-backend + Atom editor In-Reply-To: References: Message-ID: Hello! I don't know if there's any code around integrating atom and ide-backend. The new work-in-progress School of Haskell implementation directly uses ide-backend-client. It turned out to not be very hard to get it working with GHCJS and using websockets. In particular, the ide-backend-common[1] package builds with GHCJS! This is the package which defines the protocol types and serialization instances. I needed to modify ide-backend-client a bit to allow me to use it with websockets. Since atom is local, maybe ide-backend-client's default of using stdin / stdout is fine. However, it might be helpful that my ide-backend-client branch[2] makes it into a library and allows the caller to specify actions for sending / receiving messages. The current state of that branch also requires a special branch of ide-backend[3]. I'm glad you're interested in this! I'm happy to help out with it! -Michael [1] https://github.com/fpco/ide-backend/tree/master/ide-backend-common [2] https://github.com/mgsloan/ide-backend-client/tree/soh [3] https://github.com/fpco/ide-backend/tree/soh On Wed, May 13, 2015 at 8:16 AM, JP Moresmau wrote: > Hello, when the open sourcing of IDE-backend was announced ( > https://www.fpcomplete.com/blog/2015/03/announce-ide-backend), one thing > mentioned was Atom support, and indeed the home page for the client ( > https://github.com/chrisdone/ide-backend-client) mentions Atom. But is > there a project out there I can use that brings the two together? The > ide-haskell (https://atom.io/packages/ide-haskell) Atom plugin still > relies on ghc-mod as far as I can tell. > > I saw edsko tutorial on writing Atom plugin in Haskell ( > http://edsko.net/2015/02/14/atom-haskell/), so it seem we are > tentalizingly close to have Atom + Haskell implemented in Haskell, and I'd > like to give it a go if there's anything available out there (and maybe > help if needed). > > Thanks! > > JP > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From leza.ml at fecrd.cujae.edu.cu Thu May 14 06:31:55 2015 From: leza.ml at fecrd.cujae.edu.cu (Leza Morais Lutonda) Date: Thu, 14 May 2015 02:31:55 -0400 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: <20150513215121.1f853d0a@cedar.deldotd.com> References: <20150511205026.660785ac@cedar.deldotd.com> <55521A14.9040509@fecrd.cujae.edu.cu> <20150513215121.1f853d0a@cedar.deldotd.com> Message-ID: <5554415B.6080401@fecrd.cujae.edu.cu> On 05/14/2015 12:51 AM, briand at aracnet.com wrote: > Well what I was_really_ trying to do was to get to a Vector of (Complex Double). > > Interestingly, the following, where ys is type Vector.Storable (Complex Double), > > > ys_array = listArray (0, V.length ys -1) (V.toList ys) > y = V.fromList $ map (\z -> realPart z :+ imagPart z) (elems (dft ys_array)) > > worked just fine, but it's not obvious to me that it should have. Seems like the realPart/imagPart should have failed to work because the argument is not Complex Double it's Complex FFTWReal, so I should have ended up with (Complex FFTWReal) when I really wanted (Complex Double) and fail. > > BTW, it seems to me that it would be awfully nice if FFT delivered results as Vectors instead of the Array thingy. It looked to me like V.Storable is something which is supposed to ease the marshalling to and from the C world. > > Would it be a whole lot of work to change the interface to Vector.Storable ? > > Among other advantages, it makes interfacing to HMatrix easier. Hi Brian, I think the problem is in the way of seeing the types and type classes. First, the type of `ys` is not `Vector.Storable (Complex Double)`, it is Vector (Complex Double). `FFTWReal` is not a type, it is a type class. It is used as a constraint for types, for example, the type of `dft`: dft :: (Ix i, Shapable i, FFTWReal r) => CArray i (Complex r) -> CArray i (Complex r) this means that the type `r` must be instance o FFTWReal type class. So, the type of `dft ys_array` is `CArray i (Complex Double)`, since the type of `ys_array` is `CArray i (Complex Double)`, that means that the `r` in the type of `dft` is `Double`. So, the `map` is unnecessary. You can try: ``` vectorToArray v = listArray (0, V.length v - 1) (V.toList v) arrayToVector = V.fromList . elems fft :: FFTWReal r => V.Vector (Complex r) -> V.Vector (Complex r) fft = arrayToVector . dft . vectorToArray ``` Hope it can help! -- Leza Morais Lutonda, Lemol-C Electronics & Telecommunications Engineer Software Development and Architecture Enthusiast http://lemol.github.io 50 Aniversario de la Cujae. Inaugurada por Fidel el 2 de diciembre de 1964 http://cujae.edu.cu From jones.noamle at gmail.com Thu May 14 08:50:58 2015 From: jones.noamle at gmail.com (jones.noamle at gmail.com) Date: Thu, 14 May 2015 11:50:58 +0300 Subject: [Haskell-cafe] Suggestion: "Sizable" super class for Storable Message-ID: Storable instances have a size, given by sizeOf. In many cases, we're not interested in peeking/poking data but only passing it opaquely via the FFI. A common use case is when the C API offers an "init" function such as: void mycontext_init(mycontext *context); For these cases it would be useful to know the size of "mycontext", so we could malloc it and pass a pointer to mycontext_init. Also, it allows Haskell-side code to decide how it wants to allocate the data, perhaps using some other (external) mechanism not related to the specific API that the FFI bindings are wrapping. c2hs would benefit by allowing users to use the '+' notation in function parameters (which generate malloc-and-pass style code), without having to guess the size of the structure. Instead, it could simply use the Sizable (TM) instance to get the size, and the user will define Sizable in any way they want (for example, using the {#sizeof#} macro, which is somewhat unreliable, or by hard-coding or manually entering the size or by some other method). Your thoughts are much appreciated! -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Thu May 14 12:12:45 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Thu, 14 May 2015 15:12:45 +0300 Subject: [Haskell-cafe] Suggestion: "Sizable" super class for Storable In-Reply-To: References: Message-ID: <5554913D.7020906@ro-che.info> On 14/05/15 11:50, jones.noamle at gmail.com wrote: > Storable instances have a size, given by sizeOf. > > In many cases, we're not interested in peeking/poking data but only > passing it opaquely via the FFI. A common use case is when the C API > offers an "init" function such as: > > void mycontext_init(mycontext *context); > > For these cases it would be useful to know the size of "mycontext", so > we could malloc it and pass a pointer to mycontext_init. > > Also, it allows Haskell-side code to decide how it wants to allocate the > data, perhaps using some other (external) mechanism not related to the > specific API that the FFI bindings are wrapping. > > c2hs would benefit by allowing users to use the '+' notation in function > parameters (which generate malloc-and-pass style code), without having > to guess the size of the structure. Instead, it could simply use the > Sizable (TM) instance to get the size, and the user will define Sizable > in any way they want (for example, using the {#sizeof#} macro, which is > somewhat unreliable, or by hard-coding or manually entering the size or > by some other method). > > > Your thoughts are much appreciated! +1, I've needed this in the past. How about 'Sized' instead of 'Sizable'? -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From elliot.cameron at covenanteyes.com Thu May 14 12:37:42 2015 From: elliot.cameron at covenanteyes.com (Elliot Cameron) Date: Thu, 14 May 2015 12:37:42 +0000 Subject: [Haskell-cafe] Suggestion: "Sizable" super class for Storable In-Reply-To: <5554913D.7020906@ro-che.info> References: <5554913D.7020906@ro-che.info> Message-ID: <3c4b1367dde243ca8da12ccd081c7e5e@HQWS-EXMB-01.main.covenanteyes.com> More specificity might be appropriate since there are many ways to "size" things: perhaps "ByteSized" in this context. Let the puns begin. -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Roman Cheplyaka Sent: Thursday, May 14, 2015 8:13 AM To: jones.noamle at gmail.com; haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Suggestion: "Sizable" super class for Storable On 14/05/15 11:50, jones.noamle at gmail.com wrote: > Storable instances have a size, given by sizeOf. > > In many cases, we're not interested in peeking/poking data but only > passing it opaquely via the FFI. A common use case is when the C API > offers an "init" function such as: > > void mycontext_init(mycontext *context); > > For these cases it would be useful to know the size of "mycontext", so > we could malloc it and pass a pointer to mycontext_init. > > Also, it allows Haskell-side code to decide how it wants to allocate > the data, perhaps using some other (external) mechanism not related to > the specific API that the FFI bindings are wrapping. > > c2hs would benefit by allowing users to use the '+' notation in > function parameters (which generate malloc-and-pass style code), > without having to guess the size of the structure. Instead, it could > simply use the Sizable (TM) instance to get the size, and the user > will define Sizable in any way they want (for example, using the > {#sizeof#} macro, which is somewhat unreliable, or by hard-coding or > manually entering the size or by some other method). > > > Your thoughts are much appreciated! +1, I've needed this in the past. How about 'Sized' instead of 'Sizable'? From amindfv at gmail.com Thu May 14 12:40:29 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Thu, 14 May 2015 08:40:29 -0400 Subject: [Haskell-cafe] evaluate arbitrary code + mutable variables In-Reply-To: References: Message-ID: <45F3F79A-E0E4-482E-95CB-BD282A0AB287@gmail.com> Using monadic bind in ghci is not at all deprecated -- it's one of the main ways people interact with ghci. MVar, iorefs, etc also work within ghci. Almost anything you can do in haskell you can do in ghci. Tom El May 12, 2015, a las 20:02, Jeffrey Brown escribi?: > Half solved! > > David Gladstein pointed out that GHCI's "it" variable can at least sometimes solve the problem: > > Prelude System.IO> let x = 3 > Prelude System.IO> x > 3 > Prelude System.IO> let x = it + 1 > Prelude System.IO> x > 4 > > Then I discovered that in GHCI one can bind monadically: > > Prelude> x <- return 3 > Prelude> x <- return $ x + 1 > Prelude> x > 4 > > Prelude> x <- getLine > This line was user input, not computer output. > Prelude> x > "This line was user input, not computer output." > Prelude> > > I don't remember seeing anyone demonstrate it; perhaps it is deprecated. > > I would still very much like to know whether and if so how it is possible to let the user evaluate arbitrary haskell when running compiled code. > > On Tue, May 12, 2015 at 1:19 PM, Jeffrey Brown wrote: >> I wrote a graph-like data type, with some functions for adding statements and relationships between statements. (It's different from a graph in that there's no edge/vertex distinction; there are only statements, but a statement might refer to other statements.) >> >> Currently I'm using them in GHCI. Because it does not allow one to change a variable, I keep having to do things like this: >> let g0 = emptyDocument >> let s1 = newStatement ... >> let g1 = addStatement s1 g0 >> let s2 = newStatement ... >> let g2 = addStatement s2 g1 >> ... >> If I wrote a standalone application, I could use mutable variables, so I would not have to define a new object every time I want to modify an existing one. However I like being able to type in arbitrary code into GHCI. >> >> Can one have both of those at once? That is, could I either (1) use MVars from within GHCI, or (2) write a standalone app that lets the user evaluate arbitrary Haskell? > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Thu May 14 16:36:05 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Thu, 14 May 2015 16:36:05 +0000 Subject: [Haskell-cafe] =?windows-1252?q?Data_constructor_=91Minus=92_come?= =?windows-1252?q?s_from_an_un-promotable_type_=91Ints=92?= Message-ID: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Fri May 15 01:17:07 2015 From: mike at proclivis.com (Michael Jones) Date: Thu, 14 May 2015 19:17:07 -0600 Subject: [Haskell-cafe] Equality Contstraint? Message-ID: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> I am poking around in Arrow to understand it better. There is the following definition: second :: a b c -> a (d,b) (d,c) second f = arr swap >>> first f >>> arr swap where swap :: (x,y) -> (y,x) swap ~(x,y) = (y,x) Can someone explain what the ~ is? Searching the net resulted in frustration. I kind of think it is some kind of equality constraint but can?t find documentation. Perhaps if I knew what it was called I might succeed in finding something. If it is an equality constraint, please provide a reference if you have one. I did not find anything in a search including GHC, etc. Thanks From rasen.dubi at gmail.com Fri May 15 01:26:23 2015 From: rasen.dubi at gmail.com (Alexey Shmalko) Date: Fri, 15 May 2015 01:26:23 +0000 Subject: [Haskell-cafe] Equality Contstraint? In-Reply-To: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> References: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> Message-ID: Hi, Michael, It's irrefutable pattern - the pattern that matches lazily. You can get more info here [1]. Hope this helps, Alexey Shmalko [1]: http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching On Fri, May 15, 2015 at 4:17 AM Michael Jones wrote: > I am poking around in Arrow to understand it better. There is the > following definition: > > second :: a b c -> a (d,b) (d,c) > second f = arr swap >>> first f >>> arr swap > where > swap :: (x,y) -> (y,x) > swap ~(x,y) = (y,x) > > Can someone explain what the ~ is? Searching the net resulted in > frustration. > > I kind of think it is some kind of equality constraint but can?t find > documentation. Perhaps if I knew what it was called I might succeed in > finding something. If it is an equality constraint, please provide a > reference if you have one. I did not find anything in a search including > GHC, etc. > > Thanks > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hyarion at iinet.net.au Fri May 15 01:44:42 2015 From: hyarion at iinet.net.au (Ben) Date: Fri, 15 May 2015 11:44:42 +1000 Subject: [Haskell-cafe] Equality Contstraint? In-Reply-To: Message-ID: <7c5cc1b990a818d8e44544cac527d5d7e57c224b@webmail.iinet.net.au> Just in case it helps anyone's confusion, your equality constraint idea was on a reasonable track. When the ~ symbol appears *in a type signature* it is indeed an equality constraint. But in a pattern expression it's the marker for an irrefutable pattern. Regads,Ben ----- Original Message ----- From: "Alexey Shmalko" To:"Michael Jones" , "" Cc: Sent:Fri, 15 May 2015 01:26:23 +0000 Subject:Re: [Haskell-cafe] Equality Contstraint? Hi, Michael, It's irrefutable pattern - the pattern that matches lazily. You can get more info here [1]. Hope this helps,Alexey Shmalko [1]:?http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching [1] On Fri, May 15, 2015 at 4:17 AM Michael Jones wrote: I am poking around in Arrow to understand it better. There is the following definition: ? ? second :: a b c -> a (d,b) (d,c) ? ? second f = arr swap >>> first f >>> arr swap ? ? ? where ? ? ? ? swap :: (x,y) -> (y,x) ? ? ? ? swap ~(x,y) = (y,x) Can someone explain what the ~ is? Searching the net resulted in frustration. I kind of think it is some kind of equality constraint but can?t find documentation. Perhaps if I knew what it was called I might succeed in finding something If it is an equality constraint, please provide a reference if you have one. I did not find anything in a search including GHC, etc. Thanks _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org [3] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe [4] Links: ------ [1] http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching [2] mailto:mike at proclivis.com [3] mailto:Haskell-Cafe at haskell.org [4] http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Fri May 15 01:47:35 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 14 May 2015 21:47:35 -0400 Subject: [Haskell-cafe] Equality Contstraint? In-Reply-To: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> References: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> Message-ID: On Thu, May 14, 2015 at 9:17 PM, Michael Jones wrote: > I kind of think it is some kind of equality constraint but can?t find > documentation. Perhaps if I knew what it was called I might succeed in > finding something. If it is an equality constraint, please provide a > reference if you have one. I did not find anything in a search including > GHC, etc. ~ is an equality constraint only in a type constraint (foo :: (x ~ y) => ...). In a pattern, it indicates the pattern matches lazily instead of the usual strict match. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From mike at proclivis.com Fri May 15 02:50:31 2015 From: mike at proclivis.com (Proclivis) Date: Thu, 14 May 2015 20:50:31 -0600 Subject: [Haskell-cafe] Equality Contstraint? In-Reply-To: References: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> Message-ID: <55EAEDB0-9F43-46AE-93C5-42E169802B23@proclivis.com> Thanks, is there a recommended tutorial that walks through the type signatures of Arrow and sample implementations, and use in practice? Where the newbie reading it may need more hand holding. Sent from my iPad > On May 14, 2015, at 7:26 PM, Alexey Shmalko wrote: > > Hi, Michael, > > It's irrefutable pattern - the pattern that matches lazily. You can get more info here [1]. > > Hope this helps, > Alexey Shmalko > > [1]: http://en.wikibooks.org/wiki/Haskell/Laziness#Lazy_pattern_matching > >> On Fri, May 15, 2015 at 4:17 AM Michael Jones wrote: >> I am poking around in Arrow to understand it better. There is the following definition: >> >> second :: a b c -> a (d,b) (d,c) >> second f = arr swap >>> first f >>> arr swap >> where >> swap :: (x,y) -> (y,x) >> swap ~(x,y) = (y,x) >> >> Can someone explain what the ~ is? Searching the net resulted in frustration. >> >> I kind of think it is some kind of equality constraint but can?t find documentation. Perhaps if I knew what it was called I might succeed in finding something. If it is an equality constraint, please provide a reference if you have one. I did not find anything in a search including GHC, etc. >> >> Thanks >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From briand at aracnet.com Fri May 15 05:22:55 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Thu, 14 May 2015 22:22:55 -0700 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: <5554415B.6080401@fecrd.cujae.edu.cu> References: <20150511205026.660785ac@cedar.deldotd.com> <55521A14.9040509@fecrd.cujae.edu.cu> <20150513215121.1f853d0a@cedar.deldotd.com> <5554415B.6080401@fecrd.cujae.edu.cu> Message-ID: <20150514222255.5b220cf9@cedar.deldotd.com> On Thu, 14 May 2015 02:31:55 -0400 Leza Morais Lutonda wrote: > On 05/14/2015 12:51 AM, briand at aracnet.com wrote: > I think the problem is in the way of seeing the types and type classes. > First, the type of `ys` is not `Vector.Storable (Complex Double)`, it is > Vector (Complex Double). Well that may be, but when I try to use Vector (Complex Double) with hmatrix it doesn't work. I have to make sure to use/import Vector.Storable. Meanwhile, back at the fft example. import qualified Data.Vector.Storable as V import Data.Complex import Math.FFT(dft) import Math.FFT.Base(FFTWReal) import Data.Array.IArray(elems) import Data.Array.CArray(listArray) vectorToArray v = listArray (0, V.length v - 1) (V.toList v) arrayToVector = V.fromList . elems fft :: FFTWReal r => V.Vector (Complex r) -> V.Vector (Complex r) fft = arrayToVector . dft . vectorToArray And the following error messages are why i get very little done in an evening of haskell hacking. To understand those error messages I'd have to be so good with haskell that I wouldn't actually need those error messages, or so it seems to me. Clearly I have something important to learn about what you are saying about type classes. So I'll stare at this for a few more hours, and try random type assignments until it works. Meanwhile, along the way, I may type up one of Shakespeare's plays... Thanks very much for your help. simple.hs:9:17: No instance for (V.Storable a0) arising from a use of ?V.fromList? The type variable ?a0? is ambiguous Relevant bindings include arrayToVector :: Data.Array.CArray.Base.CArray Int a0 -> V.Vector a0 (bound at simple.hs:9:1) Note: there are several potential instances: instance V.Storable a => V.Storable (Complex a) -- Defined in ?Data.Complex? instance V.Storable GHC.Fingerprint.Type.Fingerprint -- Defined in ?Foreign.Storable? instance V.Storable GHC.Int.Int16 -- Defined in ?Foreign.Storable? ...plus 18 others In the first argument of ?(.)?, namely ?V.fromList? In the expression: V.fromList . elems In an equation for ?arrayToVector?: arrayToVector = V.fromList . elems simple.hs:12:7: Couldn't match type ?a0? with ?Complex r? because type variable ?r? would escape its scope This (rigid, skolem) type variable is bound by the type signature for fft :: FFTWReal r => V.Vector (Complex r) -> V.Vector (Complex r) at simple.hs:11:8-65 Expected type: Data.Array.CArray.Base.CArray Int a0 -> V.Vector (Complex r) Actual type: Data.Array.CArray.Base.CArray Int a0 -> V.Vector a0 Relevant bindings include fft :: V.Vector (Complex r) -> V.Vector (Complex r) (bound at simple.hs:12:1) In the first argument of ?(.)?, namely ?arrayToVector? In the expression: arrayToVector . dft . vectorToArray From briand at aracnet.com Fri May 15 05:32:57 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Thu, 14 May 2015 22:32:57 -0700 Subject: [Haskell-cafe] trying to go from FFT type to Vector.Storable In-Reply-To: <5554415B.6080401@fecrd.cujae.edu.cu> References: <20150511205026.660785ac@cedar.deldotd.com> <55521A14.9040509@fecrd.cujae.edu.cu> <20150513215121.1f853d0a@cedar.deldotd.com> <5554415B.6080401@fecrd.cujae.edu.cu> Message-ID: <20150514223257.40d30959@cedar.deldotd.com> On Thu, 14 May 2015 02:31:55 -0400 Leza Morais Lutonda wrote: > arrayToVector = V.fromList . elems Success. arrayToVector :: FFTWReal r => CArray Int (Complex r) -> V.Vector (Complex r) is the correct type declaration. It seems that I am too eager to assign Double to places where `r` would work, and it's entirely due to an obviously glaring whole in my understanding of type classes. I kind of thought i understood them, but i obviously don't, no I need to go figure that out. I also need to spend time to understand exactly how that type declaration solved the error messages. Thanks very much for your help, I really appreciate it ! Brian From codygman.consulting at gmail.com Fri May 15 06:47:49 2015 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 15 May 2015 01:47:49 -0500 Subject: [Haskell-cafe] Can I specify the a in a phantom type to be limited to a sum type? Message-ID: How can I create Answers of type Gender, Race, or Age? These should be possible: ?> Answer Male ?> Answer White ?> Answer Black ?> Answer 28 Others such as using a string should not be possible: ?> Answer "a string" -- should throw type error {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} module Tutorial where data Gender = Male | Female deriving (Show) data Race = White | Black deriving (Show) type Age = Int data Answer a where Answer :: Gender -> Answer Gender deriving instance Show (Answer w) -- ?> -- This is pretty useful and accepts Answers with the Gender -- ?> Answer Male -- Answer Male -- ?> :t Answer Male -- Answer Male :: Answer Gender -- ?> -- how do I also accept Race and Age? -- below I try to sort out how to use type families (unsuccessfully) before bed -- type family Answer :: * -- type instance Answer Gender = Answer Gender From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Fri May 15 06:51:52 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Fri, 15 May 2015 07:51:52 +0100 Subject: [Haskell-cafe] Can I specify the a in a phantom type to be limited to a sum type? In-Reply-To: References: Message-ID: <20150515065152.GA2530@weber> On Fri, May 15, 2015 at 01:47:49AM -0500, Cody Goodman wrote: > How can I create Answers of type Gender, Race, or Age? > > These should be possible: > > ?> Answer Male > ?> Answer White > ?> Answer Black > ?> Answer 28 > > Others such as using a string should not be possible: > > ?> Answer "a string" -- should throw type error It would probably help if you tell us why precisely you want this, and in particular why data Answer = AnswerGender Gender | AnswerRace Race | AnswerAge Int is not satisfactory. Tom From hjgtuyl at chello.nl Fri May 15 08:14:09 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Fri, 15 May 2015 10:14:09 +0200 Subject: [Haskell-cafe] Equality Contstraint? In-Reply-To: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> References: <4D2432F1-CABA-4360-BC53-CCA8E14119FC@proclivis.com> Message-ID: On Fri, 15 May 2015 03:17:07 +0200, Michael Jones wrote: > Can someone explain what the ~ is? Searching the net resulted in > frustration. The Hoogle at haskell.org[0] can help you, it leads to: https://wiki.haskell.org/Keywords#.7E The Hoogle version at fpcomplete.com doesn't handle keywords or standard operators any more. Regards, Henk-Jan van Tuyl [0] https://www.haskell.org/hoogle/ -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From 0slemi0 at gmail.com Fri May 15 09:12:29 2015 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Fri, 15 May 2015 11:12:29 +0200 Subject: [Haskell-cafe] Can I specify the a in a phantom type to be limited to a sum type? In-Reply-To: <20150515065152.GA2530@weber> References: <20150515065152.GA2530@weber> Message-ID: You can do this, although you still need a datastructure that allows you to use the contained type: {-# LANGUAGE GADTs #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE TypeSynonymInstances #-} module Tutorial where data Gender = Male | Female deriving (Show) data Race = White | Black deriving (Show) type Age = Int data Answer a where Answer :: RacistAgistSexist a => a -> Answer a deriving instance Show w => Show (Answer w) data GenderRaceAge = Gender Gender | Race Race | Age Age class RacistAgistSexist a where genderRaceAge :: a -> GenderRaceAge instance RacistAgistSexist Gender where genderRaceAge = Gender instance RacistAgistSexist Race where genderRaceAge = Race instance RacistAgistSexist Age where genderRaceAge = Age -- You can use genderRaceAge to get a GenderRaceAge out of the contained type if you don't know 'a' On 15 May 2015 at 08:51, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Fri, May 15, 2015 at 01:47:49AM -0500, Cody Goodman wrote: > > How can I create Answers of type Gender, Race, or Age? > > > > These should be possible: > > > > ?> Answer Male > > ?> Answer White > > ?> Answer Black > > ?> Answer 28 > > > > Others such as using a string should not be possible: > > > > ?> Answer "a string" -- should throw type error > > It would probably help if you tell us why precisely you want this, and in > particular why > > data Answer = AnswerGender Gender > | AnswerRace Race > | AnswerAge Int > > is not satisfactory. > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From 0slemi0 at gmail.com Fri May 15 09:49:57 2015 From: 0slemi0 at gmail.com (Andras Slemmer) Date: Fri, 15 May 2015 11:49:57 +0200 Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= In-Reply-To: References: Message-ID: If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look at http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark wrote: > Hello, > > > > I clearly don?t really know what I?m doing?but at least I know it?. > > > > Here we defined the Naturals?and then attempt to construct the Integers?. > > > > > {-# LANGUAGE DataKinds #-} > > > {-# LANGUAGE ExplicitForAll #-} > > > {-# LANGUAGE FlexibleContexts #-} > > > {-# LANGUAGE FlexibleInstances #-} > > > {-# LANGUAGE GADTs #-} > > > {-# LANGUAGE MultiParamTypeClasses #-} > > > {-# LANGUAGE PolyKinds #-} > > > {-# LANGUAGE StandaloneDeriving #-} > > > {-# LANGUAGE TypeFamilies #-} > > > {-# LANGUAGE TypeOperators #-} > > > {-# LANGUAGE UndecidableInstances #-} > > > {-# LANGUAGE ScopedTypeVariables #-} > > > > > import Prelude hiding (head, tail, (++), (+), replicate) > > > import qualified Prelude as P > > > > naturals > > > > > data Nat where > > > Z :: Nat > > > S :: Nat -> Nat > > > > I can now define + and * and prove things about them?1 * x == x > etc?.nice..but lets put that on one side. > > > > Borrow bits and bobs from singletons > > > > > data family Sing (a :: k) > > > > Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs > in nat now map to SNat?double nice. > > > > > type SNat = (Sing :: Nat -> *) > > > > Create the integers by following my nose??(the integers are the > equivalence class of pairs of naturals?.) > > > > i.e. we have ?positive? or ?negative? or ?zero?? > > > > > data Ints (a :: Nat) (b :: Nat) where > > > Minus :: SNat a -> Ints 'Z a > > > Zero :: Ints 'Z 'Z > > > Plus :: SNat a -> Ints a 'Z > > > > > > > Ok?.this works as a set of values?.but?. > > > > I can?t prove anything about these because the data constructors for my > integers aren?t ?promotable??..so I cant do the same trick I did with Nat. > > > > ?:k Zero? ?.. > > Data constructor ?Zero? comes from an un-promotable type ?Ints? > > In a type in a GHCi command: Zero > > > > I?ve tried rejigging this in various futile and ignorant manners?.but the > bottom line is its??un-promotable??..look at the docs, and it says > something vague about GADT?s?but that isnt the problem directly. > > > > Is there a nifty way around this log jam? > > (I can start proving things about ?(Nat,Nat)?.but this will soon become a > bit clumsy?.) > > > > Or do I just stop here and wrestle with getting agda installed and lose > another few months in the agda-caf? (which appears to be a very nice place > somewhere in finland?.hmmmm?I think that?s something different). > > > > (I?ve already allegedly descended into cabal hell following my nose with > an agda install? > > setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the > > version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is > > version 1.19). > > > > computer science would be good, if it wasn?t for the computers. > > > > > > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by > copyright (and other intellectual property rights). If you are not the > intended recipient please e-mail the sender and then delete the email and > any attached files immediately. Any further use or dissemination is > prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and > any attachments are virus free, it is your responsibility to ensure that > this message and any attachments are virus free and do not affect your > systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, > data corruption, non-delivery, wrongful interception and unauthorised > amendment. If you communicate with us by e-mail, you acknowledge and assume > these risks, and you agree to take appropriate measures to minimise these > risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, > Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions > International, Be Viacom, Viacom International Media Networks and VIMN and > Comedy Central are all trading names of MTV Networks Europe. MTV Networks > Europe is a partnership between MTV Networks Europe Inc. and Viacom > Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley > Crescent, London, NW1 8TT. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Fri May 15 11:57:42 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Fri, 15 May 2015 11:57:42 +0000 Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= In-Reply-To: References: Message-ID: Ah, ok that?s a vote for agda. Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). From: Andras Slemmer [mailto:0slemi0 at gmail.com] Sent: 15 May 2015 10:50 AM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look at http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark > wrote: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Fri May 15 12:03:29 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Fri, 15 May 2015 12:03:29 +0000 Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= References: Message-ID: Ignore me?of course it?s inhabited?.. From: Nicholls, Mark Sent: 15 May 2015 12:58 PM To: 'Andras Slemmer' Cc: haskell-cafe at haskell.org Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ah, ok that?s a vote for agda. Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). From: Andras Slemmer [mailto:0slemi0 at gmail.com] Sent: 15 May 2015 10:50 AM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look at http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark > wrote: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Fri May 15 12:07:09 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 15 May 2015 19:07:09 +0700 Subject: [Haskell-cafe] Haskell Weekly News Message-ID: *Top Picks:* - Is Servant the most type-safe HTTP server library ever? Are the type signatures hard to read ? In addition to its utmost relevance as a web library, Servant is also an awesome case study in the type safety vs type readability trade-off spectrum, brought to you by Alp Mestanogullari and Julian Arni. HN and /r/haskell - Ozan Sener compiles Pandoc into JS via GHCJS and creates a web interface to it using the Reflex FRP library . Markup.Rocks is much loved on /r/haskell . See also HN . - Is Haskell a "Startup Secret Weapon"? Alexandr Kurilin reveals adoption challenges at Front Row Education . Among them, slow build times. Also, "senior developers [that] get very frustrated when something wouldn't compile for hours and they couldn't find any help to move forward." Comments on HN and /r/haskell . - At Facebook, Bryan O'Sullivan debugs aeson's gigabyte space leak on decoding a JSON megabyte of non-stop backslashes. Culprit? The streaming interface didn't match the use case. In place of streaming, Bryan now blasts bytes into a single big buffer, gaining 27x speed and 42x memory reduction. Comments on HN , Proggit , /r/haskell . - Paul Chiusano's Unison programming platform hits the HN and /r/haskell headlines. Features include a browser-based UI that constrains edits to those that are well-typed. Also, DRY-ness up the wazoo: every type and term is uniquely identified by a hash a la Git. - Joey Hess reports that Debian unstable now has a working GHCi for ARM. The Template Haskell challenges have been surmounted. - Garrison Jensen blows the whistle on the impostor sieve on the front page of Haskell.org. In jest. A festive one-upmanship of fondly treasured code ensues on /r/haskell . And since bad publicity is better than no publicity, we owe kudos to Garrison. HN-worthy . - Michael Snoyman decries use of ExceptT IO for exception handling because the user exception data type creates misleading expectations of comprehensiveness. The gotcha is that it doesn't cover IO exceptions! Furthermore, distinct exception types mean that the corresponding code can't compose. Instead? Use MonadThrow. /r/haskell - JP Moresmau steps down as chief of EclipseFP and the companion Haskell packages BuildWrapper, ghc-pkg-lib, and scion-browser. Without anyone to take his place, the sun sets on EclipseFP. But the sun continues to shine on ide-backend (previously reported ), a GHC API wrapper akin to BuildWrapper. JP spitballs on how he might move on to the Atom editor, jiggering it to use ide-backend-client. /r/haskell - Tatsuya Hirose translates Go By Example into Haskell. GBE comprises code samples annotated for an experienced programmer new to Go. For this first cut , Tatsuya stays close to the original and creates Go-ish, imperative Haskell. Already good for Go-to-Haskell crossovers. Potentially excellent when done in idiomatic Haskell. /r/haskell - Tomas Petricek observes the diversity of type theories and type systems and posits harm in any attempt at a single all-encompassing capture of the meaning of 'types'. What about unsound types? He doesn't offer a way out for those stuck with the appellation. Comments on HN and /r/haskell . - John De Goes launches a crowdfund to solicit $15,000 for video-recording 70 talks at LambdaConf 2015, which features many known Haskell programmers. /r/haskell - A redditor asks ex-Lispers what it's like moving to Haskell . "I miss Lisp parens" is a frequent answer. Also, Lisp has a better REPL experience. A biggie upside? The refactoring afforded by Haskell's type system. *Tip of the Week:* - When programming fractals, use the LLVM backend because it's "usually good at optimizing this kind of non-allocating code" as Reid Barton advises. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Fri May 15 12:35:30 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Fri, 15 May 2015 12:35:30 +0000 Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= References: Message-ID: Its inhabited, and I can potentials readon about positive and negative and zero?because these are mapped to type constructors?.but they are not isomorphic to the integers?they are just 3 sub classes of the class of integers? That aint much good. I assume its because the even the type of my data constructor Zero is? Ints 'Z 'Z If I wanted an isomorphic type constructor?it would need to be? 'Ints ''Z ''Z (I know haskell doesn?t promote the type Ints to a kind ?Ints, it irritatingly promotes it to Ints?.) ??Z doesn?t exist?? hmmm From: Nicholls, Mark Sent: 15 May 2015 1:03 PM To: 'Andras Slemmer' Cc: 'haskell-cafe at haskell.org' Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ignore me?of course it?s inhabited?.. From: Nicholls, Mark Sent: 15 May 2015 12:58 PM To: 'Andras Slemmer' Cc: haskell-cafe at haskell.org Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ah, ok that?s a vote for agda. Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). From: Andras Slemmer [mailto:0slemi0 at gmail.com] Sent: 15 May 2015 10:50 AM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look at http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark > wrote: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Fri May 15 12:39:59 2015 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 15 May 2015 07:39:59 -0500 Subject: [Haskell-cafe] Can I specify the a in a phantom type to be limited to a sum type? In-Reply-To: References: <20150515065152.GA2530@weber> Message-ID: Tom, I'm trying to make a well-typed API to Question/Answers on medical forms. The questions will be lined with a specific code, so I want to enforce that certain codes can only contain certain types of answers. Andras, thanks. I'll give that a try later today and let you know how it works. On Fri, May 15, 2015 at 4:12 AM, Andras Slemmer <0slemi0 at gmail.com> wrote: > You can do this, although you still need a datastructure that allows you to > use the contained type: > > {-# LANGUAGE GADTs #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeSynonymInstances #-} > module Tutorial where > > data Gender = Male | Female deriving (Show) > > data Race = White | Black deriving (Show) > > type Age = Int > > data Answer a where > Answer :: RacistAgistSexist a => a -> Answer a > > deriving instance Show w => Show (Answer w) > > data GenderRaceAge > = Gender Gender > | Race Race > | Age Age > > class RacistAgistSexist a where > genderRaceAge :: a -> GenderRaceAge > instance RacistAgistSexist Gender where > genderRaceAge = Gender > instance RacistAgistSexist Race where > genderRaceAge = Race > instance RacistAgistSexist Age where > genderRaceAge = Age > > -- You can use genderRaceAge to get a GenderRaceAge out of the contained > type if you don't know 'a' > > > On 15 May 2015 at 08:51, Tom Ellis > wrote: >> >> On Fri, May 15, 2015 at 01:47:49AM -0500, Cody Goodman wrote: >> > How can I create Answers of type Gender, Race, or Age? >> > >> > These should be possible: >> > >> > ?> Answer Male >> > ?> Answer White >> > ?> Answer Black >> > ?> Answer 28 >> > >> > Others such as using a string should not be possible: >> > >> > ?> Answer "a string" -- should throw type error >> >> It would probably help if you tell us why precisely you want this, and in >> particular why >> >> data Answer = AnswerGender Gender >> | AnswerRace Race >> | AnswerAge Int >> >> is not satisfactory. >> >> Tom >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From mike at barrucadu.co.uk Fri May 15 13:14:37 2015 From: mike at barrucadu.co.uk (Michael Walker) Date: Fri, 15 May 2015 14:14:37 +0100 Subject: [Haskell-cafe] Call for concurrency bugs! Message-ID: <20150515131437.GA7237@localhost> Hi cafe, I've been working on a little library for testing concurrent Haskell programs, and would really like some test cases not constructed by myself to throw it at. If anyone has any examples of buggy concurrency (preferably where it's tricky to provoke the bugs with conventional testing techniques) that I could use: either open bugs, or things which have been fixed but were awkward to do so, that would be really useful. This is leading up to a paper, hopefully, so examples may go into that: anonymously, if preferred. Thank you. -- Michael Walker (http://www.barrucadu.co.uk) -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 473 bytes Desc: Digital signature URL: From anakreonmejdi at gmail.com Fri May 15 16:08:43 2015 From: anakreonmejdi at gmail.com (anakreon) Date: Fri, 15 May 2015 09:08:43 -0700 (PDT) Subject: [Haskell-cafe] Transforming ASTs Message-ID: <2a9b6e20-8e2e-4927-9fab-ecf7b277a405@googlegroups.com> This might be a duplicated message. The first time I posted it I had not subscribed to haskell cafe. Suppose the following data type for encoding Boolean expressions: data BExpr a = BTrue | BFalse | Id String | Not a | And a a | Or a a | BEq a a deriving (Functor) type Expr = Fix BExpr It is easy to produce a string representation of an expression or evaluate it: estr :: BExpr String -> String eval :: BExpr Bool -> Bool with the cata function from Data.Functor.Fixedpoint. Could you suggest a solution for transforming trees encoded as Exp into equivalent Expr (e.g Not Not a ~> a)? cata does not work since it expects a function f a -> a while a transformation would be f a -> f a. -------------- next part -------------- An HTML attachment was scrubbed... URL: From serg.foo at gmail.com Fri May 15 17:26:57 2015 From: serg.foo at gmail.com (Sergey Vinokurov) Date: Fri, 15 May 2015 20:26:57 +0300 Subject: [Haskell-cafe] Fwd: Transforming ASTs In-Reply-To: References: <2a9b6e20-8e2e-4927-9fab-ecf7b277a405@googlegroups.com> Message-ID: Hi anakreon, You should look at paramorphism and histomorphism recursion schemes. Paramorphism has type f (a, Fix f) -> a, and thus allows you to pattern match on the subtree that produced the result. But it's not enough to write simplification of (Not (Not x)) -> x because it'll have to access simplification result that is more than one level deep. But this recursion scheme would be helpful for simpler transformations like (And True x) -> x. As for original optimization of double negation I'd suggest to use histomorphism where you'll have access to all the expression subtrees annotated with intermediate results. E.g. {-# LANGUAGE DeriveFunctor #-} {-# LANGUAGE StandaloneDeriving #-} {-# LANGUAGE UndecidableInstances #-} data Cofree f a = a :< f (Cofree f a) deriving (Functor) strip :: (Functor f) => Cofree f a -> Fix f strip (_ :< x) = Fix $ fmap strip x newtype Fix f = Fix (f (Fix f)) deriving instance (Show (f (Fix f))) => Show (Fix f) unFix :: Fix f -> f (Fix f) unFix (Fix x) = x histo :: (Functor f) => (f (Cofree f a) -> a) -> Fix f -> a histo alg x = case histo' alg x of y :< _ -> y histo' :: (Functor f) => (f (Cofree f a) -> a) -> Fix f -> Cofree f a histo' alg = (\x -> alg x :< x) . fmap (histo' alg) . unFix simplify :: Fix BExpr -> Fix BExpr simplify = histo alg where alg :: BExpr (Cofree BExpr Expr) -> Expr alg (Not (_ :< (Not (x :< _)))) = x alg x = Fix $ fmap strip x main :: IO () main = do print $ simplify $ Fix (Not (Fix (Not (Fix (Not (Fix (And (Fix BTrue) (Fix BFalse)))))))) For more detailed exposition I'd suggest to look into https://github.com/willtim/recursion-schemes/raw/master/slides-final.pdf Sergey. On Fri, May 15, 2015 at 7:08 PM, anakreon wrote: > This might be a duplicated message. The first time I posted it I had not > subscribed to haskell cafe. > > Suppose the following data type for encoding Boolean expressions: > > data BExpr a = BTrue > | BFalse > | Id String > | Not a > | And a a > | Or a a > | BEq a a > deriving (Functor) > type Expr = Fix BExpr > > It is easy to produce a string representation of an expression or evaluate > it: > > estr :: BExpr String -> String > eval :: BExpr Bool -> Bool > > with the cata function from Data.Functor.Fixedpoint. > > Could you suggest a solution for transforming trees encoded as Exp into > equivalent Expr (e.g Not Not a ~> a)? > cata does not work since it expects a function f a -> a while a > transformation would be f a -> f a. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From teodor.vlasov at gmail.com Fri May 15 18:59:37 2015 From: teodor.vlasov at gmail.com (Teodor Vlasov) Date: Fri, 15 May 2015 21:59:37 +0300 Subject: [Haskell-cafe] cast to specific Typeclass Message-ID: <1431716377.15531.14.camel@gmail.com> Hello everyone, I'm trying to implement traversal over data structures and found Data.Typeable very useful for that. But it seems to be impossible to cast to specific typeclass, so that we can cast Typeable to something that is Show'able for example. It'd be usefull to have something like: data CanShow = forall a. CanShow a toConcrete :: (Typeable a) => a -> Maybe CanShow Implementing such datatypes for needed classes would allow to do some kind of class casting. Is it possible to implement this somehow? Is it a limitation of the implementation or a principal one? Thanks! Regards, Teodor. From anakreonmejdi at gmail.com Fri May 15 20:02:38 2015 From: anakreonmejdi at gmail.com (Anakreontas Mentis) Date: Fri, 15 May 2015 21:02:38 +0100 Subject: [Haskell-cafe] Transforming ASTs In-Reply-To: References: <2a9b6e20-8e2e-4927-9fab-ecf7b277a405@googlegroups.com> Message-ID: Thank you Sergey for the link. Very nice presentation On Fri, May 15, 2015 at 6:26 PM, Sergey Vinokurov wrote: > Hi anakreon, > > You should look at paramorphism and histomorphism recursion schemes. > > Paramorphism has type f (a, Fix f) -> a, and thus allows you to > pattern match on the subtree that produced the result. > But it's not enough to write simplification of (Not (Not x)) -> x > because it'll have to access simplification result that is more than > one level deep. But this recursion scheme would be helpful for > simpler transformations like (And True x) -> x. > > As for original optimization of double negation I'd suggest to use > histomorphism where you'll have access to all the expression > subtrees annotated with intermediate results. > > E.g. > > {-# LANGUAGE DeriveFunctor #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE UndecidableInstances #-} > > data Cofree f a = a :< f (Cofree f a) > deriving (Functor) > > strip :: (Functor f) => Cofree f a -> Fix f > strip (_ :< x) = Fix $ fmap strip x > > newtype Fix f = Fix (f (Fix f)) > > deriving instance (Show (f (Fix f))) => Show (Fix f) > > unFix :: Fix f -> f (Fix f) > unFix (Fix x) = x > > histo :: (Functor f) => (f (Cofree f a) -> a) -> Fix f -> a > histo alg x = case histo' alg x of y :< _ -> y > > histo' :: (Functor f) => (f (Cofree f a) -> a) -> Fix f -> Cofree f a > histo' alg = (\x -> alg x :< x) . fmap (histo' alg) . unFix > > simplify :: Fix BExpr -> Fix BExpr > simplify = histo alg > where > alg :: BExpr (Cofree BExpr Expr) -> Expr > alg (Not (_ :< (Not (x :< _)))) = x > alg x = Fix $ fmap strip x > > main :: IO () > main = do > print $ simplify $ Fix (Not (Fix (Not (Fix (Not (Fix (And (Fix > BTrue) (Fix BFalse)))))))) > > > For more detailed exposition I'd suggest to look into > https://github.com/willtim/recursion-schemes/raw/master/slides-final.pdf > > Sergey. > > On Fri, May 15, 2015 at 7:08 PM, anakreon wrote: > > This might be a duplicated message. The first time I posted it I had not > > subscribed to haskell cafe. > > > > Suppose the following data type for encoding Boolean expressions: > > > > data BExpr a = BTrue > > | BFalse > > | Id String > > | Not a > > | And a a > > | Or a a > > | BEq a a > > deriving (Functor) > > type Expr = Fix BExpr > > > > It is easy to produce a string representation of an expression or > evaluate > > it: > > > > estr :: BExpr String -> String > > eval :: BExpr Bool -> Bool > > > > with the cata function from Data.Functor.Fixedpoint. > > > > Could you suggest a solution for transforming trees encoded as Exp into > > equivalent Expr (e.g Not Not a ~> a)? > > cata does not work since it expects a function f a -> a while a > > transformation would be f a -> f a. > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex.solla at gmail.com Fri May 15 20:24:21 2015 From: alex.solla at gmail.com (Alexander Solla) Date: Fri, 15 May 2015 13:24:21 -0700 Subject: [Haskell-cafe] Can I specify the a in a phantom type to be limited to a sum type? In-Reply-To: References: <20150515065152.GA2530@weber> Message-ID: Read the paper "Data types a la carte"[1], and check out the compdata[2] library for an implementation. The idea is that instead of making a big union type like: data Answers = SexAnswer | AgeAnswer | etc... you make data Sex = M | F | etc newtype Age = Age Int and then you construct functions that accept sum types: ageOrSex :: Age :+: Sex -> m Bool ... A single type class, called :<: in the paper, handles dispatching from sums the underlying values to sums. [1]: http://www.cs.ru.nl/~W.Swierstra/Publications/DataTypesALaCarte.pdf [2: https://hackage.haskell.org/package/compdata On Fri, May 15, 2015 at 5:39 AM, Cody Goodman wrote: > Tom, I'm trying to make a well-typed API to Question/Answers on > medical forms. The questions will be lined with a specific code, so I > want to enforce that certain codes can only contain certain types of > answers. > > Andras, thanks. I'll give that a try later today and let you know how it > works. > > On Fri, May 15, 2015 at 4:12 AM, Andras Slemmer <0slemi0 at gmail.com> wrote: > > You can do this, although you still need a datastructure that allows you > to > > use the contained type: > > > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeSynonymInstances #-} > > module Tutorial where > > > > data Gender = Male | Female deriving (Show) > > > > data Race = White | Black deriving (Show) > > > > type Age = Int > > > > data Answer a where > > Answer :: RacistAgistSexist a => a -> Answer a > > > > deriving instance Show w => Show (Answer w) > > > > data GenderRaceAge > > = Gender Gender > > | Race Race > > | Age Age > > > > class RacistAgistSexist a where > > genderRaceAge :: a -> GenderRaceAge > > instance RacistAgistSexist Gender where > > genderRaceAge = Gender > > instance RacistAgistSexist Race where > > genderRaceAge = Race > > instance RacistAgistSexist Age where > > genderRaceAge = Age > > > > -- You can use genderRaceAge to get a GenderRaceAge out of the contained > > type if you don't know 'a' > > > > > > On 15 May 2015 at 08:51, Tom Ellis > > wrote: > >> > >> On Fri, May 15, 2015 at 01:47:49AM -0500, Cody Goodman wrote: > >> > How can I create Answers of type Gender, Race, or Age? > >> > > >> > These should be possible: > >> > > >> > ?> Answer Male > >> > ?> Answer White > >> > ?> Answer Black > >> > ?> Answer 28 > >> > > >> > Others such as using a string should not be possible: > >> > > >> > ?> Answer "a string" -- should throw type error > >> > >> It would probably help if you tell us why precisely you want this, and > in > >> particular why > >> > >> data Answer = AnswerGender Gender > >> | AnswerRace Race > >> | AnswerAge Int > >> > >> is not satisfactory. > >> > >> Tom > >> > >> _______________________________________________ > >> Haskell-Cafe mailing list > >> Haskell-Cafe at haskell.org > >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri May 15 20:48:10 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 15 May 2015 23:48:10 +0300 Subject: [Haskell-cafe] Transforming ASTs In-Reply-To: <2a9b6e20-8e2e-4927-9fab-ecf7b277a405@googlegroups.com> References: <2a9b6e20-8e2e-4927-9fab-ecf7b277a405@googlegroups.com> Message-ID: <55565B8A.70006@ro-che.info> On 15/05/15 19:08, anakreon wrote: > Could you suggest a solution for transforming trees encoded as Exp into > equivalent Expr (e.g Not Not a ~> a)? > cata does not work since it expects a function f a -> a while a > transformation would be f a -> f a. As you say, you have something of type f a -> f a, but you need something of type f a -> a to pass it to cata. Or, more specifically (replacing f with BExpr and a with Expr), you have something of type BExpr Expr -> BExpr Expr, and you need something of type BExpr Expr -> Expr. If only BExpr Expr was isomorphic to Expr! Oh wait... it is. You define Expr as the fixpoint of BExpr, which means that BExpr Expr and Expr are essentially the same. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From roma at ro-che.info Fri May 15 20:52:40 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 15 May 2015 23:52:40 +0300 Subject: [Haskell-cafe] cast to specific Typeclass In-Reply-To: <1431716377.15531.14.camel@gmail.com> References: <1431716377.15531.14.camel@gmail.com> Message-ID: <55565C98.3030900@ro-che.info> On 15/05/15 21:59, Teodor Vlasov wrote: > Hello everyone, > > I'm trying to implement traversal over data structures and found > Data.Typeable very useful for that. But it seems to be impossible to > cast to specific typeclass, so that we can cast Typeable to something > that is Show'able for example. It'd be usefull to have something like: > > data CanShow = forall a. CanShow a > > toConcrete :: (Typeable a) => a -> Maybe CanShow > > Implementing such datatypes for needed classes would allow to do some > kind of class casting. > > Is it possible to implement this somehow? > Is it a limitation of the implementation or a principal one? Casting to a type works because all information is there, you only need to convince the type system that it is fine to use it. "Casting to a class" doesn't work because the type class implementation (the method dictionary) is not contained in a value of that type. Instead, compiler plugs it in during compile time where it is needed. What you can do is try to cast a value to a number of known types, and if one of those casts succeeds, get hold of the dictionary corresponding to that monomorphic type. What you *cannot* do is to find out at runtime which instances the compiler knew about at compile time (let alone recover the dictionary); that information is gone. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From codygman.consulting at gmail.com Fri May 15 23:45:22 2015 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 15 May 2015 18:45:22 -0500 Subject: [Haskell-cafe] Deriving Show instance with ADT that has phantom type Message-ID: Going through the Data Types Ala Carte paper I found this definition: data Expr f = In (f (Expr f)) I tried to use "deriving Show"... data Expr f = In (f (Expr f)) deriving Show I found out that doesn't work with ADT's that have phantom types. I tried StandaloneDeriving too since GHC recommended it: {-# LANGUAGE StandaloneDeriving #-} data Expr f = In (f (Expr f)) deriving Show instance deriving Show (Expr f) Got this error: src/Main.hs:32:1-31: No instance for (Show (f (Expr f))) ? arising from a use of ?showsPrec? In the second argument of ?(.)?, namely ?(showsPrec 11 b1)? In the second argument of ?showParen?, namely ?((.) (showString "In ") (showsPrec 11 b1))? In the expression: showParen ((a >= 11)) ((.) (showString "In ") (showsPrec 11 b1)) When typechecking the code for ?showsPrec? in a standalone derived instance for ?Show (Expr f)?: To see the code I am typechecking, use -ddump-deriv Compilation failed. Here is the derived instance output from ghc -ddump-simple: Derived instances: instance GHC.Show.Show (Main.Expr f_aq1) where GHC.Show.showsPrec a_azP (Main.In b1_azQ) = GHC.Show.showParen ((a_azP GHC.Classes.>= 11)) ((GHC.Base..) (GHC.Show.showString "In ") (GHC.Show.showsPrec 11 b1_azQ)) GHC.Show.showList = GHC.Show.showList__ (GHC.Show.showsPrec 0) Didn't work. Can this be derived? Will I need to manually make instances? From danburton.email at gmail.com Sat May 16 03:26:42 2015 From: danburton.email at gmail.com (Dan Burton) Date: Fri, 15 May 2015 20:26:42 -0700 Subject: [Haskell-cafe] Call for concurrency bugs! In-Reply-To: <20150515131437.GA7237@localhost> References: <20150515131437.GA7237@localhost> Message-ID: I'm not sure if this is as nuanced as what you're looking for, but the test suite for enclosed-exceptions involves provoking very particular concurrent circumstances. https://github.com/jcristovao/enclosed-exceptions/blob/master/test/main.hs -- Dan Burton On Fri, May 15, 2015 at 6:14 AM, Michael Walker wrote: > Hi cafe, > > I've been working on a little library for testing concurrent Haskell > programs, > and would really like some test cases not constructed by myself to throw > it at. > If anyone has any examples of buggy concurrency (preferably where it's > tricky to > provoke the bugs with conventional testing techniques) that I could use: > either > open bugs, or things which have been fixed but were awkward to do so, that > would > be really useful. > > This is leading up to a paper, hopefully, so examples may go into that: > anonymously, if preferred. > > Thank you. > > -- > Michael Walker (http://www.barrucadu.co.uk) > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Sat May 16 14:35:07 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Sat, 16 May 2015 15:35:07 +0100 Subject: [Haskell-cafe] [ANN] relational-record - relational-algebraic query building DSL In-Reply-To: <20141220.015016.1996398754200322441.ex8k.hibino@gmail.com> References: <20141219.123901.2041677716305014953.ex8k.hibino@gmail.com> <20141219124436.GA20224@weber> <20141220.015016.1996398754200322441.ex8k.hibino@gmail.com> Message-ID: <20150516143506.GG5062@weber> On Sat, Dec 20, 2014 at 01:50:16AM +0900, Kei Hibino wrote: > > On Fri, Dec 19, 2014 at 12:39:01PM +0900, Kei Hibino wrote: > >> From: Manuel G?mez > >> Subject: Re: [Haskell-cafe] [ANN] relational-record - relational-algebraic query building DSL > >> Date: Sun, 14 Dec 2014 12:22:25 -0430 > >> > >> > On Sun, Dec 14, 2014 at 12:04 PM, Kei Hibino wrote: > >> >> I am happy to announce relational-record library and its project page. > >> >> > >> >> relational-record is domain specific language for type-safe SQL query building, > >> >> and database access API with compile time schema generators. > >> > > >> > Congratulations on the release! It?s great to see more and more > >> > interesting abstractions for relational databases in the Haskell > >> > ecosystem. > >> > > >> > It looks like this project shares many goals with Tom Ellis? excellent > >> > and recently released[1] Opaleye library. How would you say your > >> > approach compares with Opaleye?s? > >> > > >> > [1]: > >> > >> Relational Record and Opaleye resembles in approach of building > >> not aggregated SQL query. > >> > >> Opaleye's method using arrow notation is very cool. > > > > Opaleye uses arrows only because it is hard to implement a sensible > > semantics otherwise. See, for example, this bug report on HaskellDB which > > used a monad rather than an arrow > > > > https://github.com/m4dc4p/haskelldb/issues/22 > > In my -- Relational Record -- implementation, > this issue does not exist like exmaple code below. Unfortunately I just discovered that Haskell Relational Record suffers from a worse issue: not just strange semantics, but a (SQL) crash bug: https://github.com/khibino/haskell-relational-record/issues/19 Designing a typesafe relational query language is *hard*. Opaleye is still the only SQL EDSL I am aware of that has natural semantics and whose design is typesafe. Sadly, at least for now, Haskell Relational Record doesn't meet the second condition. Tom From manpacket at gmail.com Sun May 17 01:38:17 2015 From: manpacket at gmail.com (Michael Baikov) Date: Sun, 17 May 2015 09:38:17 +0800 Subject: [Haskell-cafe] Haskell-Cafe Digest, Vol 141, Issue 25 In-Reply-To: References: Message-ID: > > Suppose the following data type for encoding Boolean expressions: > > data BExpr a = BTrue > | BFalse > | Id String > | Not a > | And a a > | Or a a > | BEq a a > deriving (Functor) > type Expr = Fix BExpr > > It is easy to produce a string representation of an expression or evaluate > it: > > estr :: BExpr String -> String > eval :: BExpr Bool -> Bool > > with the cata function from Data.Functor.Fixedpoint. > > Could you suggest a solution for transforming trees encoded as Exp into > equivalent Expr (e.g Not Not a ~> a)? > cata does not work since it expects a function f a -> a while a > transformation would be f a -> f a. Actually cata works just fine, all you need following transformation which is f a -> a alg :: BExpr Expr -> Expr alg (Not (Fix (Not a))) = a alg x = Fix x From thomas at koch.ro Sun May 17 06:11:43 2015 From: thomas at koch.ro (Thomas Koch) Date: Sun, 17 May 2015 08:11:43 +0200 Subject: [Haskell-cafe] no Web-Security component in Haskell? Message-ID: <2608800.UApO9Nzphg@x121e> Hallo, I did not found anything comparable to Spring Security[1][2] (Java) or Symfony Security[3] (PHP) in Haskell. Both components are used in web applications to grant or deny access to resources based on roles, ACLs or custom voters. A naive strategy would be to port the concepts of both components, which are very similar, to Haskell. They represent a lot of accumulated knowledge from many experts about web security. Or are there better ways to do web security in a powerful language like Haskell? Regards, Thomas Koch [1] http://projects.spring.io/spring-security [2] http://docs.spring.io/autorepo/docs/spring-security/3.1.7.RELEASE/apidocs [3] http://api.symfony.com/master/Symfony/Component/Security/Core/SecurityContext.html From hsyl20 at gmail.com Sun May 17 12:25:24 2015 From: hsyl20 at gmail.com (Sylvain Henry) Date: Sun, 17 May 2015 14:25:24 +0200 Subject: [Haskell-cafe] Static executables in minimal Docker containers In-Reply-To: References: <86ca2603-37f2-4645-9cd2-f09703f2be67@googlegroups.com> <553407EF.1030303@gmail.com> Message-ID: Hi, I had the same bug with a single static binary in a initramfs. I fixed GHC.IO.Encoding to avoid using Iconv for the default (ASCII) charmap used with static binaries and now it works. Patch is in my comment on https://ghc.haskell.org/trac/ghc/ticket/10298 If the default LC_CTYPE value is the DEFAULT_CHARMAP from glibc/locale/programs/config.h, it is set to "ANSI_X3.4-1968" since 2000 and was set to "POSIX" before. Maybe we should match this one too? Sylvain 2015-04-20 6:34 GMT+02:00 Michael Snoyman : > Thanks for the update Simon. > > On Sun, Apr 19, 2015 at 10:54 PM Simon Marlow wrote: > >> Hi Michael, >> >> This rang a bell for me. It might be the same as these: >> https://ghc.haskell.org/trac/ghc/ticket/7695 >> https://ghc.haskell.org/trac/ghc/ticket/8928 >> >> I think the conclusion was that the IO library is failing to start >> iconv, and printing the error messages causes it to retry loading iconv, >> ad infinitum (or something like that). There's no fix yet, but it >> probably isn't hard to fix, just that nobody got around to it yet. >> >> Cheers, >> Simon >> >> On 13/04/2015 11:50, Michael Snoyman wrote: >> > I'm not sure if this issue would show up, but I can try it in Fedora >> > tomorrow. I didn't address the linker warning at all right now, it seems >> > to not have been triggered, though I suppose it is possible that it's >> > the cause of this issue. >> > >> > On Mon, Apr 13, 2015 at 7:10 PM Greg Weber > > > wrote: >> > >> > Haskell is not that great at producing statically linked libraries >> > independent of the OS. >> > The issue you are running into would likely show up in another >> > non-ubuntu image (or even possibly a different version of an ubuntu >> > image), so you could probably use a Fedora image that has tracing. >> > >> > How are you addressing the linker warning about needing a particular >> > glibc version at runtime? >> > >> > On Mon, Apr 13, 2015 at 3:28 AM, Sharif Olorin >> > > wrote: >> > >> > Unfortunately, strace and ltrace aren't available in that >> > Docker image, but it's a good idea to see if I can get them >> > running there somehow. >> > >> > >> > Failing that, you might be able to get useful information of the >> > same kind by running docker (the server, not the `docker run` >> > command) under perf[0] and then running your busybox container. >> > It should at least give you an idea of what it's doing when it >> > explodes. >> > >> > Sharif >> > >> > [0]: https://perf.wiki.kernel.org/index.php/Tutorial >> > >> > -- >> > You received this message because you are subscribed to the >> > Google Groups "Commercial Haskell" group. >> > To unsubscribe from this group and stop receiving emails from >> > it, send an email to >> > commercialhaskell+unsubscribe at googlegroups.com >> > . >> > To post to this group, send email to >> > commercialhaskell at googlegroups.com >> > . >> > To view this discussion on the web visit >> > >> https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-f09703f2be67%40googlegroups.com >> > < >> https://groups.google.com/d/msgid/commercialhaskell/86ca2603-37f2-4645-9cd2-f09703f2be67%40googlegroups.com?utm_medium=email&utm_source=footer >> >. >> > >> > For more options, visit https://groups.google.com/d/optout. >> > >> > >> > -- >> > You received this message because you are subscribed to the Google >> > Groups "Commercial Haskell" group. >> > To unsubscribe from this group and stop receiving emails from it, send >> > an email to commercialhaskell+unsubscribe at googlegroups.com >> > . >> > To post to this group, send email to commercialhaskell at googlegroups.com >> > . >> > To view this discussion on the web visit >> > >> https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_5GWPO1Dcn%2BvwsiB_xWj%2B8GfHvMkoBjw%40mail.gmail.com >> > < >> https://groups.google.com/d/msgid/commercialhaskell/CAKA2Jg%2B%3DzJiXmak2FU_5GWPO1Dcn%2BvwsiB_xWj%2B8GfHvMkoBjw%40mail.gmail.com?utm_medium=email&utm_source=footer >> >. >> > For more options, visit https://groups.google.com/d/optout. >> >> -- >> You received this message because you are subscribed to the Google Groups >> "Commercial Haskell" group. >> To unsubscribe from this group and stop receiving emails from it, send an >> email to commercialhaskell+unsubscribe at googlegroups.com. >> To post to this group, send email to commercialhaskell at googlegroups.com. >> To view this discussion on the web visit >> https://groups.google.com/d/msgid/commercialhaskell/553407EF.1030303%40gmail.com >> . >> For more options, visit https://groups.google.com/d/optout. >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun May 17 12:46:08 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 17 May 2015 14:46:08 +0200 Subject: [Haskell-cafe] Announcement: Gipeda, the git performance dashboard Message-ID: <1431866768.19043.27.camel@joachim-breitner.de> Dear Haskellers, a while ago, I set up a performance dashboard? for GHC, based on codespeed?, but I was dissatisfied, so in the end, I wrote a new one, called Gipeda for ?Git Performance Dashboard?. The git in the name as, in contrast to codespeed, I do not try to be VCS-agnostic but do want to use and expose the structure of your project?s git repository in the output. You can have a look at http://perf.haskell.org/ghc. It should be relatively self-explanatory. Just note that by default it hides boring stuff (commits and results with no significant change), you can select what to show in the top-right corner. The idea behind gipeda is relatively simple. Starting with a directory with one file for each of your project?s benchmarked commit, gipeda digests this to produce a bunch of JSON files. It uses shake? to avoid unnecessary recalculations. A static HTML file with lots of JavaScript (using handlebars as a templating engine, and other JS libraries like jQuery and flot) then presents this data, in a hopefully snappy and intuitive way. I have announced the GHC instance on the ghc-dev mailing list?, so why do I write here as well? Because you can use gipeda for your own projects! And because you can contribute! The program is not GHC-specific, so if you have a way to produce benchmark numbers (or any other kind of metric) for your project, you can feed them to gipeda to be visualized. See the README at https://github.com/nomeata/gipeda for instructions (and ask me if you are stuck). If it makes sense we can host the result at http://perf.haskell.org/ (but you still need to run the benchmarks yourself). And although it is quite nice so far, there are a lot of things it should also be able to do. Here are a few ideas: * Integrate data from multiple build hosts. * Compare the results from arbitrary two commits. * Visualize non-linear git histories, e.g. due to branches. * Know about named branches and tags. * RSS feeds and email notifications. * Find a way to efficiently run gipeda on travis. * General UI polishing. Some of that is possible without touching any JavaScript, some without touching any Haskell, so if you want to contribute, I?m sure you?ll find something. I plan to work on that during ZuriHac? (only two more weeks), so if you are there and looking for a project, please join me! Greetings, Joachim ? http://ghcspeed-nomeata.rhcloud.com/ ? https://github.com/tobami/codespeed ? http://shakebuild.com/ ? https://mail.haskell.org/pipermail/ghc-devs/2015-May/009032.html ? https://wiki.haskell.org/ZuriHac2015 PS: Thanks to davean from the haskell.org admin team for setting up perf.haskell.org. -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From chrisdone at gmail.com Sun May 17 16:42:34 2015 From: chrisdone at gmail.com (Christopher Done) Date: Sun, 17 May 2015 18:42:34 +0200 Subject: [Haskell-cafe] FIXME pragma Message-ID: What's the feeling on having a FIXME pragma so that I can attach warnings to unfinished things? {-# FIXME foo "Reasons here." #-} I would use the WARNING pragma but that doesn't work within a module and only triggers on use. Compiler errors are the one thing I and everyone else pays attention to, it would be very handy to have more control over things GHC reports to the developer to aid development. Ciao -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Sun May 17 17:24:02 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Sun, 17 May 2015 19:24:02 +0200 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: Message-ID: <1431883442.21053.3.camel@joachim-breitner.de> Hi, Am Sonntag, den 17.05.2015, 18:42 +0200 schrieb Christopher Done: > What's the feeling on having a FIXME pragma so that I can attach > warnings to unfinished things? > > {-# FIXME foo "Reasons here." #-} > > > I would use the WARNING pragma but that doesn't work within a module > and only triggers on use. Compiler errors are the one thing I and > everyone else pays attention to, it would be very handy to have more > control over things GHC reports to the developer to aid development. do you want GHC to print a warning here, or an error, or either depending on your flags? I thought there was a GHC trac ticket that asked for a more general WARNING where you could specify the type of warning, and the warnings could be ignored/displayed/made errors per group; then FIXME would just be one such type. Unfortunately, I cannot find it ? maybe it was just a discussion elsewhere. I believe people wanted to use it to warn about partial functions.... ah, that made me find it. See https://mail.haskell.org/pipermail/libraries/2015-February/025044.html Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From roma at ro-che.info Sun May 17 20:10:37 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Sun, 17 May 2015 23:10:37 +0300 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: Message-ID: <5558F5BD.70309@ro-che.info> On 17/05/15 19:42, Christopher Done wrote: > What's the feeling on having a FIXME pragma so that I can attach > warnings to unfinished things? > > |{-# FIXME foo "Reasons here." #-}| > > I would use the WARNING pragma but that doesn't work within a module and > only triggers on use. Compiler errors are the one thing I and everyone > else pays attention to, it would be very handy to have more control over > things GHC reports to the developer to aid development. +1. I actively use WARNING in such cases, and I'd prefer the warning to be reported at the definition site. It'd also be great to allow this pragma anywhere in the code, but I realize it'd complicate the parser. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From madhadron at gmail.com Mon May 18 01:34:45 2015 From: madhadron at gmail.com (Fred Ross) Date: Sun, 17 May 2015 18:34:45 -0700 Subject: [Haskell-cafe] Request for maintainers Message-ID: <59359F54-E9A8-461F-863E-C445E5C90EF6@gmail.com> I have finally accepted that I won't be part of the Haskell community in any real sense in the foreseeable future. There are three libraries that I am still the maintainer of that I need to hand off. Is there anyone who would take over any of the following? hdaemonize - Utilities for writing Unix daemons in Haskell serial - Serial port access library hscamwire - FFI bindings to camwire to access IIDC1394 Firewire cameras Fred Ross http://madhadron.com From eir at cis.upenn.edu Mon May 18 02:47:15 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Sun, 17 May 2015 22:47:15 -0400 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: <5558F5BD.70309@ro-che.info> References: <5558F5BD.70309@ro-che.info> Message-ID: -1 I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell: $([] <$ reportWarning "Fix this function!") You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.) If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways. Richard On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote: > On 17/05/15 19:42, Christopher Done wrote: >> What's the feeling on having a FIXME pragma so that I can attach >> warnings to unfinished things? >> >> |{-# FIXME foo "Reasons here." #-}| >> >> I would use the WARNING pragma but that doesn't work within a module and >> only triggers on use. Compiler errors are the one thing I and everyone >> else pays attention to, it would be very handy to have more control over >> things GHC reports to the developer to aid development. > > +1. I actively use WARNING in such cases, and I'd prefer the warning to > be reported at the definition site. > > It'd also be great to allow this pragma anywhere in the code, but I > realize it'd complicate the parser. > > Roman > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From benl at ouroborus.net Mon May 18 03:20:46 2015 From: benl at ouroborus.net (Ben Lippmeier) Date: Mon, 18 May 2015 13:20:46 +1000 Subject: [Haskell-cafe] CFP: Haskell Symposium Regular Track Final Call Message-ID: <56C47F83-AA54-45DB-9263-9CA379D32AD4@ouroborus.net> ===================================================================== ACM SIGPLAN CALL FOR SUBMISSIONS Haskell Symposium 2015 Vancouver, Canada, 3-4 September 2015, directly after ICFP http://www.haskell.org/haskell-symposium/2015 ===================================================================== Reminder that the Haskell Symposium Regular Track abstract deadline is this: Tuesday 19th of May, with full papers due this: Friday 22nd of May. Authors that have *already submitted to the early track*, have until 5th of June to resubmit an improved version of those papers. Deadlines stated are valid anywhere on earth. (the HotCRP submission site states them in US EDT, but don't fret) See the website for further details http://www.haskell.org/haskell-symposium/2015 ===================================================================== From brucker at spamfence.net Mon May 18 05:36:44 2015 From: brucker at spamfence.net (Achim D. Brucker) Date: Mon, 18 May 2015 07:36:44 +0200 Subject: [Haskell-cafe] OCL 2015: First Call for Papers Message-ID: <20150518053644.GA8636@fujikawa.home.brucker.ch> (Apologies for duplicates) CALL FOR PAPERS 15th International Workshop on OCL and Textual Modeling Tools and Textual Model Transformations Co-located with ACM/IEEE 18th International Conference on Model Driven Engineering Languages and Systems (MODELS 2015) September 28th, 2015, Ottawa, Canada http://ocl2015.lri.fr Modeling started out with UML and its precursors as a graphical notation. Such visual representations enable direct intuitive capturing of reality, but some of their features are difficult to formalize and lack the level of precision required to create complete and unambiguous specifications. Limitations of the graphical notations encouraged the development of text-based modeling languages that either integrate with or replace graphical notations for modeling. Typical examples of such languages are OCL, textual MOF, Epsilon, and Alloy. Textual modeling languages have their roots in formal language paradigms like logic, programming and databases. The goal of this workshop is to create a forum where researchers and practitioners interested in building models using OCL or other kinds of textual languages can directly interact, report advances, share results, identify tools for language development, and discuss appropriate standards. In particular, the workshop will encourage discussions for achieving synergy from different modeling language concepts and modeling language use. The close interaction will enable researchers and practitioners to identify common interests and options for potential cooperation. Topics of interest include (but are not limited to) =================================================== - Mappings between textual modeling languages and other languages/formalisms - Algorithms, evaluation strategies and optimizations in the context of textual modeling languages for -- validation, verification, and testing, -- model transformation and code generation, -- meta-modeling and DSLs, and -- query and constraint specifications - Alternative graphical/textual notations for textual modeling languages - Evolution, transformation and simplification of textual modeling expressions - Libraries, templates and patterns for textual modeling languages - Tools that support textual modeling languages (e.g., verification of OCL formulae, runtime monitoring of invariants) - Complexity results for textual modeling languages - Quality models and benchmarks for comparing and evaluating textual modeling tools and algorithms - Successful applications of textual modeling languages - Case studies on industrial applications of textual modeling languages - Experience reports -- usage of textual modeling languages and tools in complex domains, -- usability of textual modeling languages and tools for end-users - Empirical studies about the benefits and drawbacks of textual modeling languages - Innovative textual modeling tools - Comparison, evaluation and integration of modeling languages - Correlation between modeling languages and modeling tasks This year, we particularly encourage submissions describing tools that support - in a very broad sense - textual modeling languages (if you have implemented OCL.js to run OCL in a web browser, this is the right workshop to present your work) as well as textual model transformations. Venue ===== The workshop will be organized as a part of MODELS 2015 Conference in Ottawa, Canada. It continues the series of OCL workshops held at UML/MODELS conferences: York (2000), Toronto (2001), San Francisco (2003), Lisbon (2004), Montego Bay (2005), Genova (2006), Nashville (2007), Toulouse (2008), Denver (2009), Oslo (2010), Zurich (2011, at the TOOLs conference), 2012 in Innsbruck, 2013 in Miami, and 2014 in Valencia, Spain. Similar to its predecessors, the workshop addresses both people from academia and industry. The aim is to provide a forum for addressing integration of OCL and other textual modeling languages, as well as tools for textual modeling, and for disseminating good practice and discussing the new requirements for textual modeling. Workshop Format =============== The workshop will include short (about 15 min) presentations, parallel sessions of working groups, and sum-up discussions. Submissions =========== Three types of papers will be considered: * short papers (between 6 and 8 pages) describing ideas, * tool papers (between 6 and 8 pages), and * full papers (between 12 and 16 pages) in LNCS format. Submissions should be uploaded to EasyChair (https://easychair.org/conferences/?conf=ocl20150). The program committee will review the submissions (minimum 2 reviews per paper, usually 3 reviews) and select papers according to their relevance and interest for discussions that will take place at the workshop. Accepted papers will be published online in a pre-conference edition of CEUR (http://www.ceur-ws.org). Important Dates =============== Submission of papers: July 17, 2015 Notification: August 21, 2015 Workshop date: September 28, 2015 Organizers ========== Achim D. Brucker, SAP SE, Germany Marina Egea, Indra Sistemas S.A., Spain Martin Gogolla, University of Bremen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Programme Committee =================== Mira Balaban, Ben-Gurion University of the Negev, Israel Tricia Balfe, Nomos Software, Ireland Achim D. Brucker, SAP SE, Germany Fabian Buettner, Inria - Ecole des Mines de Nantes, France Jordi Cabot, Inria - Ecole des Mines de Nantes, France Dan Chiorean, Babes-Bolyai University, Romania Robert Clariso, Universitat Oberta de Catalunya, Spain Tony Clark, Middlesex University, UK Manuel Clavel, IMDEA Software Institute, Spain Carolina Dania, IMDEA Software Institute, Spain Birgit Demuth, Technische Universitat Dresden, Germany Marina Egea, Indra Sistemas S.A., Spain Geri Georg, Colorado State University, USA Martin Gogolla, University of Bremen, Germany Shahar Maoz, Tel Aviv University, Israel Istvan Rath, Budapest University of Technology and Economics, Hungary Bernhard Rumpe, RWTH Aachen, Germany Frederic Tuong, Univ. Paris-Sud - IRT SystemX - LRI, France Claas Wilke, Technische Universitat Dresden, Germany Edward Willink, Willink Transformations Ltd., UK Burkhart Wolff, Univ. Paris-Sud - LRI, France Steffen Zschaler, King's College, UK -- Dr. Achim D. Brucker, SAP SE, Vincenz-Priessnitz-Str. 1, D-76131 Karlsruhe Phone: +49 6227 7-52595, http://www.brucker.ch/ From zilinc.dev at gmail.com Mon May 18 06:25:33 2015 From: zilinc.dev at gmail.com (Zilin Chen) Date: Mon, 18 May 2015 16:25:33 +1000 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: <5558F5BD.70309@ro-che.info> Message-ID: <555985DD.5070401@gmail.com> I also wanted such a feature but eventually I just went with: __todo :: String -> a {-# WARNING __todo "TODO" #-} __todo msg = error $ "TODO: " ++ msg __fixme :: a -> a {-# WARNING __fixme "FIXME" #-} __fixme = id Cheers, Zilin On 18/05/15 12:47, Richard Eisenberg wrote: > -1 > > I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell: > > $([] <$ reportWarning "Fix this function!") > > You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.) > > If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways. > > Richard > > On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote: > >> On 17/05/15 19:42, Christopher Done wrote: >>> What's the feeling on having a FIXME pragma so that I can attach >>> warnings to unfinished things? >>> >>> |{-# FIXME foo "Reasons here." #-}| >>> >>> I would use the WARNING pragma but that doesn't work within a module and >>> only triggers on use. Compiler errors are the one thing I and everyone >>> else pays attention to, it would be very handy to have more control over >>> things GHC reports to the developer to aid development. >> +1. I actively use WARNING in such cases, and I'd prefer the warning to >> be reported at the definition site. >> >> It'd also be great to allow this pragma anywhere in the code, but I >> realize it'd complicate the parser. >> >> Roman >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Mon May 18 08:27:19 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 18 May 2015 11:27:19 +0300 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: <5558F5BD.70309@ro-che.info> Message-ID: <5559A267.7080004@ro-che.info> Great, this should do the trick for me. Thanks Richard! On 18/05/15 05:47, Richard Eisenberg wrote: > -1 > > I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell: > > $([] <$ reportWarning "Fix this function!") > > You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.) > > If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways. > > Richard > > On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote: > >> On 17/05/15 19:42, Christopher Done wrote: >>> What's the feeling on having a FIXME pragma so that I can attach >>> warnings to unfinished things? >>> >>> |{-# FIXME foo "Reasons here." #-}| >>> >>> I would use the WARNING pragma but that doesn't work within a module and >>> only triggers on use. Compiler errors are the one thing I and everyone >>> else pays attention to, it would be very handy to have more control over >>> things GHC reports to the developer to aid development. >> >> +1. I actively use WARNING in such cases, and I'd prefer the warning to >> be reported at the definition site. >> >> It'd also be great to allow this pragma anywhere in the code, but I >> realize it'd complicate the parser. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From nicholls.mark at vimn.com Mon May 18 09:02:09 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Mon, 18 May 2015 09:02:09 +0000 Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= In-Reply-To: References: Message-ID: So?just to wrap this one up?. We can define the naturals in the canonical way using DataKind etc?.and create singleton instances? But?. There is no way to define the Integers FROM this definition and create singleton Integer instances. The problem being the any definition containing promoted types, cannot be promoted. Is that a fair summary? From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Nicholls, Mark Sent: 15 May 2015 1:35 PM To: Andras Slemmer Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Its inhabited, and I can potentials readon about positive and negative and zero?because these are mapped to type constructors?.but they are not isomorphic to the integers?they are just 3 sub classes of the class of integers? That aint much good. I assume its because the even the type of my data constructor Zero is? Ints 'Z 'Z If I wanted an isomorphic type constructor?it would need to be? 'Ints ''Z ''Z (I know haskell doesn?t promote the type Ints to a kind ?Ints, it irritatingly promotes it to Ints?.) ??Z doesn?t exist?? hmmm From: Nicholls, Mark Sent: 15 May 2015 1:03 PM To: 'Andras Slemmer' Cc: 'haskell-cafe at haskell.org' Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ignore me?of course it?s inhabited?.. From: Nicholls, Mark Sent: 15 May 2015 12:58 PM To: 'Andras Slemmer' Cc: haskell-cafe at haskell.org Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ah, ok that?s a vote for agda. Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). From: Andras Slemmer [mailto:0slemi0 at gmail.com] Sent: 15 May 2015 10:50 AM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look at http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark > wrote: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Mon May 18 09:20:27 2015 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 18 May 2015 11:20:27 +0200 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: <5558F5BD.70309@ro-che.info> Message-ID: Nice idea! I didn't know reportWarning existed. Very cool. On 18 May 2015 at 04:47, Richard Eisenberg wrote: > -1 > > I like the idea of having GHC spit out warnings and such of this form, but > this is so straightforward to do with Template Haskell: > > $([] <$ reportWarning "Fix this function!") > > You could do something similar in terms, spitting out `id` instead of an > empty list of declarations. (You'd have to be careful where you do this, > admittedly.) > > If it's this easy to do in userland without affecting the compiler, let's > do it that way. And, even better, with some library support, you could > customize this behavior in all sorts of ways. > > Richard > > On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote: > > > On 17/05/15 19:42, Christopher Done wrote: > >> What's the feeling on having a FIXME pragma so that I can attach > >> warnings to unfinished things? > >> > >> |{-# FIXME foo "Reasons here." #-}| > >> > >> I would use the WARNING pragma but that doesn't work within a module and > >> only triggers on use. Compiler errors are the one thing I and everyone > >> else pays attention to, it would be very handy to have more control over > >> things GHC reports to the developer to aid development. > > > > +1. I actively use WARNING in such cases, and I'd prefer the warning to > > be reported at the definition site. > > > > It'd also be great to allow this pragma anywhere in the code, but I > > realize it'd complicate the parser. > > > > Roman > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From chrisdone at gmail.com Mon May 18 09:58:53 2015 From: chrisdone at gmail.com (Christopher Done) Date: Mon, 18 May 2015 11:58:53 +0200 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: <555985DD.5070401@gmail.com> References: <5558F5BD.70309@ro-che.info> <555985DD.5070401@gmail.com> Message-ID: I found WARNING fell short because it doesn't work on module-local definitions, and only triggers on use. On 18 May 2015 at 08:25, Zilin Chen wrote: > I also wanted such a feature but eventually I just went with: > > __todo :: String -> a > {-# WARNING __todo "TODO" #-} > __todo msg = error $ "TODO: " ++ msg > > __fixme :: a -> a > {-# WARNING __fixme "FIXME" #-} > __fixme = id > > Cheers, > Zilin > > On 18/05/15 12:47, Richard Eisenberg wrote: > > -1 > > I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell: > > $([] <$ reportWarning "Fix this function!") > > You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.) > > If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways. > > Richard > > On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote: > > > On 17/05/15 19:42, Christopher Done wrote: > > What's the feeling on having a FIXME pragma so that I can attach > warnings to unfinished things? > > |{-# FIXME foo "Reasons here." #-}| > > I would use the WARNING pragma but that doesn't work within a module and > only triggers on use. Compiler errors are the one thing I and everyone > else pays attention to, it would be very handy to have more control over > things GHC reports to the developer to aid development. > > +1. I actively use WARNING in such cases, and I'd prefer the warning to > be reported at the definition site. > > It'd also be great to allow this pragma anywhere in the code, but I > realize it'd complicate the parser. > > Roman > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > _______________________________________________ > Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at ibotty.net Mon May 18 10:12:38 2015 From: haskell at ibotty.net (Tobias Florek) Date: Mon, 18 May 2015 12:12:38 +0200 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: <5558F5BD.70309@ro-che.info> <555985DD.5070401@gmail.com> Message-ID: <5559BB16.7040406@ibotty.net> Hi, >> I also wanted such a feature but eventually I just went with: >> >> __todo :: String -> a >> {-# WARNING __todo "TODO" #-} >> __todo msg = error $ "TODO: " ++ msg >> >> __fixme :: a -> a >> {-# WARNING __fixme "FIXME" #-} >> __fixme = id > I found WARNING fell short because it doesn't work on module-local > definitions, and only triggers on use. Maybe I am missing things, but `__todo` should generate a warning at use site which _is_ the module definition of the thing using it. Cheers, Tobi(as Florek) From roma at ro-che.info Mon May 18 10:42:39 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 18 May 2015 13:42:39 +0300 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: <5559BB16.7040406@ibotty.net> References: <5558F5BD.70309@ro-che.info> <555985DD.5070401@gmail.com> <5559BB16.7040406@ibotty.net> Message-ID: <5559C21F.60200@ro-che.info> On 18/05/15 13:12, Tobias Florek wrote: > Hi, > >>> I also wanted such a feature but eventually I just went with: >>> >>> __todo :: String -> a >>> {-# WARNING __todo "TODO" #-} >>> __todo msg = error $ "TODO: " ++ msg >>> >>> __fixme :: a -> a >>> {-# WARNING __fixme "FIXME" #-} >>> __fixme = id > >> I found WARNING fell short because it doesn't work on module-local >> definitions, and only triggers on use. > > Maybe I am missing things, but `__todo` should generate a warning at use > site which _is_ the module definition of the thing using it. Yes, that's right. The downside of __todo is that you can't specify the text of the compiler warning. (The String argument is the text of the runtime error.) Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From zilinc.dev at gmail.com Mon May 18 12:21:19 2015 From: zilinc.dev at gmail.com (Zilin Chen) Date: Mon, 18 May 2015 22:21:19 +1000 Subject: [Haskell-cafe] FIXME pragma In-Reply-To: References: <5558F5BD.70309@ro-che.info> <555985DD.5070401@gmail.com> Message-ID: Yes, my __todo and __fixme are just trivial tricks that work slightly better than -- FIXME and -- TODO as comments. I think I did miss some message from your initial post: could you elaborate how/why {-# WARNING ... #-} does not work within a module? About use-site and definition-site problem, _todo function itself need not be warned., but the functions defined in terms of it are the one we care about. So in that sense, it's still warned at definition site (i.e., __todo becomes the trigger). Cheers, Zilin On Mon, May 18, 2015 at 7:58 PM, Christopher Done wrote: > I found WARNING fell short because it doesn't work on module-local > definitions, and only triggers on use. > > On 18 May 2015 at 08:25, Zilin Chen wrote: > >> I also wanted such a feature but eventually I just went with: >> >> __todo :: String -> a >> {-# WARNING __todo "TODO" #-} >> __todo msg = error $ "TODO: " ++ msg >> >> __fixme :: a -> a >> {-# WARNING __fixme "FIXME" #-} >> __fixme = id >> >> Cheers, >> Zilin >> >> On 18/05/15 12:47, Richard Eisenberg wrote: >> >> -1 >> >> I like the idea of having GHC spit out warnings and such of this form, but this is so straightforward to do with Template Haskell: >> >> $([] <$ reportWarning "Fix this function!") >> >> You could do something similar in terms, spitting out `id` instead of an empty list of declarations. (You'd have to be careful where you do this, admittedly.) >> >> If it's this easy to do in userland without affecting the compiler, let's do it that way. And, even better, with some library support, you could customize this behavior in all sorts of ways. >> >> Richard >> >> On May 17, 2015, at 4:10 PM, Roman Cheplyaka wrote: >> >> >> On 17/05/15 19:42, Christopher Done wrote: >> >> What's the feeling on having a FIXME pragma so that I can attach >> warnings to unfinished things? >> >> |{-# FIXME foo "Reasons here." #-}| >> >> I would use the WARNING pragma but that doesn't work within a module and >> only triggers on use. Compiler errors are the one thing I and everyone >> else pays attention to, it would be very handy to have more control over >> things GHC reports to the developer to aid development. >> >> +1. I actively use WARNING in such cases, and I'd prefer the warning to >> be reported at the definition site. >> >> It'd also be great to allow this pragma anywhere in the code, but I >> realize it'd complicate the parser. >> >> Roman >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> _______________________________________________ >> Haskell-Cafe mailing listHaskell-Cafe at haskell.orghttp://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dvde at gmx.net Mon May 18 12:32:25 2015 From: dvde at gmx.net (Daniel van den Eijkel) Date: Mon, 18 May 2015 14:32:25 +0200 Subject: [Haskell-cafe] data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) Message-ID: <5559DBD9.4030907@gmx.net> Hi, I am wondering if there is a library with a datatype like the following defined: data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) I could not find anything with Hoogle. Does anybody know such a thing? Thank you & best, Daniel From roma at ro-che.info Mon May 18 12:45:02 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Mon, 18 May 2015 15:45:02 +0300 Subject: [Haskell-cafe] data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) In-Reply-To: <5559DBD9.4030907@gmx.net> References: <5559DBD9.4030907@gmx.net> Message-ID: <5559DECE.4040004@ro-che.info> It's right in transformers: https://hackage.haskell.org/package/transformers-0.4.3.0/docs/Data-Functor-Sum.html On 18/05/15 15:32, Daniel van den Eijkel wrote: > Hi, > > I am wondering if there is a library with a datatype like the following > defined: > > data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) > > I could not find anything with Hoogle. Does anybody know such a thing? > > Thank you & best, Daniel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From dvde at gmx.net Mon May 18 12:48:03 2015 From: dvde at gmx.net (Daniel van den Eijkel) Date: Mon, 18 May 2015 14:48:03 +0200 Subject: [Haskell-cafe] data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) In-Reply-To: <5559DECE.4040004@ro-che.info> References: <5559DBD9.4030907@gmx.net> <5559DECE.4040004@ro-che.info> Message-ID: <5559DF83.2080001@gmx.net> Ah great, thanks! Am 5/18/15 um 2:45 PM schrieb Roman Cheplyaka: > It's right in transformers: > https://hackage.haskell.org/package/transformers-0.4.3.0/docs/Data-Functor-Sum.html > > On 18/05/15 15:32, Daniel van den Eijkel wrote: >> Hi, >> >> I am wondering if there is a library with a datatype like the following >> defined: >> >> data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) >> >> I could not find anything with Hoogle. Does anybody know such a thing? >> >> Thank you & best, Daniel >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tonymorris at gmail.com Mon May 18 12:55:13 2015 From: tonymorris at gmail.com (Tony Morris) Date: Mon, 18 May 2015 22:55:13 +1000 Subject: [Haskell-cafe] data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) In-Reply-To: <5559DBD9.4030907@gmx.net> References: <5559DBD9.4030907@gmx.net> Message-ID: <5559E131.8060501@gmail.com> https://hackage.haskell.org/package/comonad-transformers-4.0/docs/Data-Functor-Coproduct.html On 18/05/15 22:32, Daniel van den Eijkel wrote: > Hi, > > I am wondering if there is a library with a datatype like the following > defined: > > data EitherF m1 m2 a = LeftF (m1 a) | RightF (m2 a) > > I could not find anything with Hoogle. Does anybody know such a thing? > > Thank you & best, Daniel > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From eir at cis.upenn.edu Mon May 18 13:05:17 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 18 May 2015 09:05:17 -0400 Subject: [Haskell-cafe] =?windows-1252?q?Data_constructor_=91Minus=92_come?= =?windows-1252?q?s_from_an_un-promotable_type_=91Ints=92?= In-Reply-To: References: Message-ID: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> On May 18, 2015, at 5:02 AM, "Nicholls, Mark" wrote: > > The problem being the any definition containing promoted types, cannot be promoted. > > Is that a fair summary? Yes. Only "simple" types can be promoted. But this will all change in 7.12, where just about anything will promote. For now, you may want to switch to Agda, but come back in a year's time. :) Richard > > > From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Nicholls, Mark > Sent: 15 May 2015 1:35 PM > To: Andras Slemmer > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > Its inhabited, and I can potentials readon about positive and negative and zero?because these are mapped to type constructors?.but they are not isomorphic to the integers?they are just 3 sub classes of the class of integers? > > That aint much good. > > I assume its because the even the type of my data constructor Zero is? > > Ints 'Z 'Z > > If I wanted an isomorphic type constructor?it would need to be? > > 'Ints ''Z ''Z > > (I know haskell doesn?t promote the type Ints to a kind ?Ints, it irritatingly promotes it to Ints?.) > > ??Z doesn?t exist?? > > hmmm > > > From: Nicholls, Mark > Sent: 15 May 2015 1:03 PM > To: 'Andras Slemmer' > Cc: 'haskell-cafe at haskell.org' > Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > Ignore me?of course it?s inhabited?.. > > From: Nicholls, Mark > Sent: 15 May 2015 12:58 PM > To: 'Andras Slemmer' > Cc: haskell-cafe at haskell.org > Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > Ah, ok that?s a vote for agda. > > Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. > > (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). > > From: Andras Slemmer [mailto:0slemi0 at gmail.com] > Sent: 15 May 2015 10:50 AM > To: Nicholls, Mark > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. > > However in this case you don't really need that complexity: > > data Ints > = Zero > | Minus Nat > | Plus Nat > > is sufficient enough. Although this definition is probably not the one you want to use... take a look athttp://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints > > On 14 May 2015 at 18:36, Nicholls, Mark wrote: > Hello, > > I clearly don?t really know what I?m doing?but at least I know it?. > > Here we defined the Naturals?and then attempt to construct the Integers?. > > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE ExplicitForAll #-} > > {-# LANGUAGE FlexibleContexts #-} > > {-# LANGUAGE FlexibleInstances #-} > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE PolyKinds #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE UndecidableInstances #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > import Prelude hiding (head, tail, (++), (+), replicate) > > import qualified Prelude as P > > naturals > > > data Nat where > > Z :: Nat > > S :: Nat -> Nat > > I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. > > Borrow bits and bobs from singletons > > > data family Sing (a :: k) > > Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > > > type SNat = (Sing :: Nat -> *) > > Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) > > i.e. we have ?positive? or ?negative? or ?zero?? > > > data Ints (a :: Nat) (b :: Nat) where > > Minus :: SNat a -> Ints 'Z a > > Zero :: Ints 'Z 'Z > > Plus :: SNat a -> Ints a 'Z > > > > Ok?.this works as a set of values?.but?. > > I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. > > ?:k Zero? ?.. > Data constructor ?Zero? comes from an un-promotable type ?Ints? > In a type in a GHCi command: Zero > > I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. > > Is there a nifty way around this log jam? > (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) > > Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). > > (I?ve already allegedly descended into cabal hell following my nose with an agda install? > setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the > version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is > version 1.19). > > computer science would be good, if it wasn?t for the computers. > > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Mon May 18 13:06:48 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Mon, 18 May 2015 13:06:48 +0000 Subject: [Haskell-cafe] =?windows-1252?q?Data_constructor_=91Minus=92_come?= =?windows-1252?q?s_from_an_un-promotable_type_=91Ints=92?= In-Reply-To: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> References: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> Message-ID: Hmmmm? OK, Any idea of a timescale Maybe I jump ship to agda temporarily. From: Richard Eisenberg [mailto:eir at cis.upenn.edu] Sent: 18 May 2015 2:05 PM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? On May 18, 2015, at 5:02 AM, "Nicholls, Mark" > wrote: The problem being the any definition containing promoted types, cannot be promoted. Is that a fair summary? Yes. Only "simple" types can be promoted. But this will all change in 7.12, where just about anything will promote. For now, you may want to switch to Agda, but come back in a year's time. :) Richard From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Nicholls, Mark Sent: 15 May 2015 1:35 PM To: Andras Slemmer Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Its inhabited, and I can potentials readon about positive and negative and zero?because these are mapped to type constructors?.but they are not isomorphic to the integers?they are just 3 sub classes of the class of integers? That aint much good. I assume its because the even the type of my data constructor Zero is? Ints 'Z 'Z If I wanted an isomorphic type constructor?it would need to be? 'Ints ''Z ''Z (I know haskell doesn?t promote the type Ints to a kind ?Ints, it irritatingly promotes it to Ints?.) ??Z doesn?t exist?? hmmm From: Nicholls, Mark Sent: 15 May 2015 1:03 PM To: 'Andras Slemmer' Cc: 'haskell-cafe at haskell.org' Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ignore me?of course it?s inhabited?.. From: Nicholls, Mark Sent: 15 May 2015 12:58 PM To: 'Andras Slemmer' Cc: haskell-cafe at haskell.org Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ah, ok that?s a vote for agda. Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). From: Andras Slemmer [mailto:0slemi0 at gmail.com] Sent: 15 May 2015 10:50 AM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look athttp://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark > wrote: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Mon May 18 13:23:37 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Mon, 18 May 2015 09:23:37 -0400 Subject: [Haskell-cafe] =?windows-1252?q?Data_constructor_=91Minus=92_come?= =?windows-1252?q?s_from_an_un-promotable_type_=91Ints=92?= In-Reply-To: References: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> Message-ID: <8BAD8EA7-733F-4C19-91B0-3F9A72826FDE@cis.upenn.edu> On May 18, 2015, at 9:06 AM, "Nicholls, Mark" wrote: > Hmmmm? > > OK, > > Any idea of a timescale In ways that would be hard to predict, promoting all types is a fairly massive change to GHC. If I merge in August, I'll be quite pleased. But it really should be there by 7.12, which should occur by Feb/Mar '16. Richard > > Maybe I jump ship to agda temporarily. > > From: Richard Eisenberg [mailto:eir at cis.upenn.edu] > Sent: 18 May 2015 2:05 PM > To: Nicholls, Mark > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > > On May 18, 2015, at 5:02 AM, "Nicholls, Mark" wrote: > > The problem being the any definition containing promoted types, cannot be promoted. > > Is that a fair summary? > > Yes. Only "simple" types can be promoted. > > But this will all change in 7.12, where just about anything will promote. For now, you may want to switch to Agda, but come back in a year's time. :) > > Richard > > > > > From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Nicholls, Mark > Sent: 15 May 2015 1:35 PM > To: Andras Slemmer > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > Its inhabited, and I can potentials readon about positive and negative and zero?because these are mapped to type constructors?.but they are not isomorphic to the integers?they are just 3 sub classes of the class of integers? > > That aint much good. > > I assume its because the even the type of my data constructor Zero is? > > Ints 'Z 'Z > > If I wanted an isomorphic type constructor?it would need to be? > > 'Ints ''Z ''Z > > (I know haskell doesn?t promote the type Ints to a kind ?Ints, it irritatingly promotes it to Ints?.) > > ??Z doesn?t exist?? > > hmmm > > > From: Nicholls, Mark > Sent: 15 May 2015 1:03 PM > To: 'Andras Slemmer' > Cc: 'haskell-cafe at haskell.org' > Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > Ignore me?of course it?s inhabited?.. > > From: Nicholls, Mark > Sent: 15 May 2015 12:58 PM > To: 'Andras Slemmer' > Cc: haskell-cafe at haskell.org > Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > Ah, ok that?s a vote for agda. > > Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. > > (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). > > From: Andras Slemmer [mailto:0slemi0 at gmail.com] > Sent: 15 May 2015 10:50 AM > To: Nicholls, Mark > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? > > If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. > > However in this case you don't really need that complexity: > > data Ints > = Zero > | Minus Nat > | Plus Nat > > is sufficient enough. Although this definition is probably not the one you want to use... take a look athttp://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints > > On 14 May 2015 at 18:36, Nicholls, Mark wrote: > Hello, > > I clearly don?t really know what I?m doing?but at least I know it?. > > Here we defined the Naturals?and then attempt to construct the Integers?. > > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE ExplicitForAll #-} > > {-# LANGUAGE FlexibleContexts #-} > > {-# LANGUAGE FlexibleInstances #-} > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE PolyKinds #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE UndecidableInstances #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > import Prelude hiding (head, tail, (++), (+), replicate) > > import qualified Prelude as P > > naturals > > > data Nat where > > Z :: Nat > > S :: Nat -> Nat > > I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. > > Borrow bits and bobs from singletons > > > data family Sing (a :: k) > > Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > > > type SNat = (Sing :: Nat -> *) > > Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) > > i.e. we have ?positive? or ?negative? or ?zero?? > > > data Ints (a :: Nat) (b :: Nat) where > > Minus :: SNat a -> Ints 'Z a > > Zero :: Ints 'Z 'Z > > Plus :: SNat a -> Ints a 'Z > > > > Ok?.this works as a set of values?.but?. > > I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. > > ?:k Zero? ?.. > Data constructor ?Zero? comes from an un-promotable type ?Ints? > In a type in a GHCi command: Zero > > I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. > > Is there a nifty way around this log jam? > (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) > > Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). > > (I?ve already allegedly descended into cabal hell following my nose with an agda install? > setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the > version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is > version 1.19). > > computer science would be good, if it wasn?t for the computers. > > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Mon May 18 13:36:48 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Mon, 18 May 2015 13:36:48 +0000 Subject: [Haskell-cafe] =?windows-1252?q?Data_constructor_=91Minus=92_come?= =?windows-1252?q?s_from_an_un-promotable_type_=91Ints=92?= In-Reply-To: <8BAD8EA7-733F-4C19-91B0-3F9A72826FDE@cis.upenn.edu> References: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> <8BAD8EA7-733F-4C19-91B0-3F9A72826FDE@cis.upenn.edu> Message-ID: Ok?so that gives me?..10 months to get my head around agda?before converting my knowledge back?.ideally I want this to work in Haskell. Thanks. From: Richard Eisenberg [mailto:eir at cis.upenn.edu] Sent: 18 May 2015 2:24 PM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? On May 18, 2015, at 9:06 AM, "Nicholls, Mark" > wrote: Hmmmm? OK, Any idea of a timescale In ways that would be hard to predict, promoting all types is a fairly massive change to GHC. If I merge in August, I'll be quite pleased. But it really should be there by 7.12, which should occur by Feb/Mar '16. Richard Maybe I jump ship to agda temporarily. From: Richard Eisenberg [mailto:eir at cis.upenn.edu] Sent: 18 May 2015 2:05 PM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? On May 18, 2015, at 5:02 AM, "Nicholls, Mark" > wrote: The problem being the any definition containing promoted types, cannot be promoted. Is that a fair summary? Yes. Only "simple" types can be promoted. But this will all change in 7.12, where just about anything will promote. For now, you may want to switch to Agda, but come back in a year's time. :) Richard From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Nicholls, Mark Sent: 15 May 2015 1:35 PM To: Andras Slemmer Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Its inhabited, and I can potentials readon about positive and negative and zero?because these are mapped to type constructors?.but they are not isomorphic to the integers?they are just 3 sub classes of the class of integers? That aint much good. I assume its because the even the type of my data constructor Zero is? Ints 'Z 'Z If I wanted an isomorphic type constructor?it would need to be? 'Ints ''Z ''Z (I know haskell doesn?t promote the type Ints to a kind ?Ints, it irritatingly promotes it to Ints?.) ??Z doesn?t exist?? hmmm From: Nicholls, Mark Sent: 15 May 2015 1:03 PM To: 'Andras Slemmer' Cc: 'haskell-cafe at haskell.org' Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ignore me?of course it?s inhabited?.. From: Nicholls, Mark Sent: 15 May 2015 12:58 PM To: 'Andras Slemmer' Cc: haskell-cafe at haskell.org Subject: RE: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? Ah, ok that?s a vote for agda. Your ints definition isn?t directly inhabited?..but maybe that doesn?t matter?.thanks I?ll struggle on a bit. (yes my definition is mildly problematic mathematically, I have 3 (coincident) zeros). From: Andras Slemmer [mailto:0slemi0 at gmail.com] Sent: 15 May 2015 10:50 AM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] Data constructor ?Minus? comes from an un-promotable type ?Ints? If you want to stick to your Ints datastructure then you need a stronger dependent type theory that allows you to reason about "double-promoted" types. However in this case you don't really need that complexity: data Ints = Zero | Minus Nat | Plus Nat is sufficient enough. Although this definition is probably not the one you want to use... take a look athttp://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints On 14 May 2015 at 18:36, Nicholls, Mark > wrote: Hello, I clearly don?t really know what I?m doing?but at least I know it?. Here we defined the Naturals?and then attempt to construct the Integers?. > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > import Prelude hiding (head, tail, (++), (+), replicate) > import qualified Prelude as P naturals > data Nat where > Z :: Nat > S :: Nat -> Nat I can now define + and * and prove things about them?1 * x == x etc?.nice..but lets put that on one side. Borrow bits and bobs from singletons > data family Sing (a :: k) Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs in nat now map to SNat?double nice. > type SNat = (Sing :: Nat -> *) Create the integers by following my nose??(the integers are the equivalence class of pairs of naturals?.) i.e. we have ?positive? or ?negative? or ?zero?? > data Ints (a :: Nat) (b :: Nat) where > Minus :: SNat a -> Ints 'Z a > Zero :: Ints 'Z 'Z > Plus :: SNat a -> Ints a 'Z > Ok?.this works as a set of values?.but?. I can?t prove anything about these because the data constructors for my integers aren?t ?promotable??..so I cant do the same trick I did with Nat. ?:k Zero? ?.. Data constructor ?Zero? comes from an un-promotable type ?Ints? In a type in a GHCi command: Zero I?ve tried rejigging this in various futile and ignorant manners?.but the bottom line is its??un-promotable??..look at the docs, and it says something vague about GADT?s?but that isnt the problem directly. Is there a nifty way around this log jam? (I can start proving things about ?(Nat,Nat)?.but this will soon become a bit clumsy?.) Or do I just stop here and wrestle with getting agda installed and lose another few months in the agda-caf? (which appears to be a very nice place somewhere in finland?.hmmmm?I think that?s something different). (I?ve already allegedly descended into cabal hell following my nose with an agda install? setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is version 1.19). computer science would be good, if it wasn?t for the computers. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From sean at functionaljobs.com Mon May 18 16:00:01 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 18 May 2015 12:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <555a0c846e258@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Senior Software Engineer (Functional Programming/Scala) at AdAgility http://functionaljobs.com/jobs/8826-senior-software-engineer-functional-programming-scala-at-adagility Cheers, Sean Murphy FunctionalJobs.com From andrew.gibiansky at gmail.com Mon May 18 22:44:54 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Mon, 18 May 2015 15:44:54 -0700 Subject: [Haskell-cafe] Abandoning String = [Char]? Message-ID: Hey all, In the earlier haskell-cafe discussion of IsString, someone mentioned that it would be nice to abandon [Char] as the blessed string type in Haskell. I've thought about this on and off for a while now, and think that the fact that [Char] is the default string type is a really big issue (for example, it gives beginners the idea that Haskell is incredibly slow, because everything that involves string processing is using linked lists). I am not proposing anything, but am curious as to what already has been discussed: 1. Has the possibility of migrating away from [Char] been investigated before? 2. What gains could we see in ease of use, performance, etc, if [Char] was deprecated? 3. What could replace [Char], while retaining the same ease of use for writing string manipulation functions (pattern matching, etc)? 4. Is there any sort of migration path that would make this change feasible in mainline Haskell in the medium term (2-5 years)? Thanks! I would welcome any references or links that my cursory googling has failed to find. -- Andrew -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Mon May 18 23:20:46 2015 From: codygman.consulting at gmail.com (Cody Goodman) Date: Mon, 18 May 2015 18:20:46 -0500 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] Message-ID: Can I use either template Haskell, GHC Generics, or something else to get the list of Constructors in Codes? Then I could do `map show codeSumTypeMembers` and get `["A0100A","A0500A"]`? Here's an example of solving this problem manually: data Codes = A0100A | A0500A deriving Show codeExists "A0100A" = True codeExists "A0500A" = True codeExists _ = False main = print $ codeExists xmlElementName where xmlElementName = "A0500A" -- ?> main -- True From kane at kane.cx Mon May 18 23:27:41 2015 From: kane at kane.cx (David Kraeutmann) Date: Tue, 19 May 2015 01:27:41 +0200 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: <555A756D.3030606@kane.cx> readConstr [1] from Data.Data will do the trick. DataType for a type can be retrieved with dataTypeOf. ---- 1: https://hackage.haskell.org/package/base-4.8.0.0/docs/Data-Data.html#v:readConstr On 5/19/2015 1:20 AM, Cody Goodman wrote: > Can I use either template Haskell, GHC Generics, or something else to > get the list of Constructors in Codes? Then I could do `map show > codeSumTypeMembers` and get `["A0100A","A0500A"]`? > > Here's an example of solving this problem manually: > > data Codes = A0100A | A0500A deriving Show > > codeExists "A0100A" = True > codeExists "A0500A" = True > codeExists _ = False > > > main = print $ codeExists xmlElementName > where xmlElementName = "A0500A" > > -- ?> main > -- True > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- A non-text attachment was scrubbed... Name: smime.p7s Type: application/pkcs7-signature Size: 4271 bytes Desc: S/MIME Cryptographic Signature URL: From allbery.b at gmail.com Mon May 18 23:27:51 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Mon, 18 May 2015 19:27:51 -0400 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: On Mon, May 18, 2015 at 7:20 PM, Cody Goodman wrote: > Can I use either template Haskell, GHC Generics, or something else to > get the list of Constructors in Codes? Then I could do `map show > codeSumTypeMembers` and get `["A0100A","A0500A"]`? > Derive Enum and Bounded as well, and you can then use minBound and maxBound along with show. This will only work for nullary constructors, though. IIRC, with Data.Typeable (deriving (Typeable)) you can do something like this for non-nullary constructors as well. It's more painful, though. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Mon May 18 23:29:48 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Mon, 18 May 2015 16:29:48 -0700 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: You can get this information through the Data.Data module. There are two typeclasses which can be (have to be, I believe) derived for your data type, Data and Typeable. The Data class lets you access a representation of your type including type constructors. To set this up, you need to import Data.Data and enable the DeriveDataTypeable extension: {-# LANGUAGE DeriveDataTypeable #-} import Data.Data data Codes = A0100A | A0500A deriving (Show, Data, Typeable) Now you can get a representation of the type: ?> dataTypeOf (undefined :: Codes) DataType {tycon = "Main.Codes", datarep = AlgRep [A0100A,A0500A]} Since your type is an algebraic data type (AlgRep), the DataRep contains its constructors, which you can inspect with functions from the Data.Data module. On Mon, May 18, 2015 at 4:20 PM, Cody Goodman wrote: > Can I use either template Haskell, GHC Generics, or something else to > get the list of Constructors in Codes? Then I could do `map show > codeSumTypeMembers` and get `["A0100A","A0500A"]`? > > Here's an example of solving this problem manually: > > data Codes = A0100A | A0500A deriving Show > > codeExists "A0100A" = True > codeExists "A0500A" = True > codeExists _ = False > > > main = print $ codeExists xmlElementName > where xmlElementName = "A0500A" > > -- ?> main > -- True > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue May 19 00:19:51 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 19 May 2015 02:19:51 +0200 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: Using GHC Generics: http://hackage.haskell.org/package/generic-deriving-1.7.0/docs/Generics-Deriving-ConNames.html On Tue, May 19, 2015 at 1:29 AM, Tikhon Jelvis wrote: > You can get this information through the Data.Data module. There are two > typeclasses which can be (have to be, I believe) derived for your data > type, Data and Typeable. The Data class lets you access a representation of > your type including type constructors. > > To set this up, you need to import Data.Data and enable the > DeriveDataTypeable extension: > > {-# LANGUAGE DeriveDataTypeable #-} > import Data.Data > > data Codes = A0100A | A0500A deriving (Show, Data, Typeable) > > Now you can get a representation of the type: > > ?> dataTypeOf (undefined :: Codes) > DataType {tycon = "Main.Codes", datarep = AlgRep [A0100A,A0500A]} > > Since your type is an algebraic data type (AlgRep), the DataRep contains > its constructors, which you can inspect with functions from the Data.Data > module. > > On Mon, May 18, 2015 at 4:20 PM, Cody Goodman < > codygman.consulting at gmail.com> wrote: > >> Can I use either template Haskell, GHC Generics, or something else to >> get the list of Constructors in Codes? Then I could do `map show >> codeSumTypeMembers` and get `["A0100A","A0500A"]`? >> >> Here's an example of solving this problem manually: >> >> data Codes = A0100A | A0500A deriving Show >> >> codeExists "A0100A" = True >> codeExists "A0500A" = True >> codeExists _ = False >> >> >> main = print $ codeExists xmlElementName >> where xmlElementName = "A0500A" >> >> -- ?> main >> -- True >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fuuzetsu at fuuzetsu.co.uk Tue May 19 04:47:09 2015 From: fuuzetsu at fuuzetsu.co.uk (Mateusz Kowalczyk) Date: Tue, 19 May 2015 05:47:09 +0100 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: Message-ID: <555AC04D.2030301@fuuzetsu.co.uk> On 05/18/2015 11:44 PM, Andrew Gibiansky wrote: > Hey all, > > In the earlier haskell-cafe discussion of IsString, someone mentioned that > it would be nice to abandon [Char] as the blessed string type in Haskell. > I've thought about this on and off for a while now, and think that the fact > that [Char] is the default string type is a really big issue (for example, > it gives beginners the idea that Haskell is incredibly slow, because > everything that involves string processing is using linked lists). > > I am not proposing anything, but am curious as to what already has been > discussed: Just me few cents below. > 1. Has the possibility of migrating away from [Char] been investigated > before? Migrating away to what? > 2. What gains could we see in ease of use, performance, etc, if [Char] was > deprecated? Deprecated in favour of what? > 3. What could replace [Char], while retaining the same ease of use for > writing string manipulation functions (pattern matching, etc)? ViewPatterns could let us imitate the pattern match at least but you'd still have to reconstruct from a list on RHS. Basically to me you're asking whether we can work with lists, using usual list things including constructors and presumably all list-y functions but without using lists? We either want one or another ;). But depending on what we want and if you're willing to give up the : and [] syntax, one could probably do well here anyway. But in any scenario, you'd be breaking every piece of code using String ever anyway. > 4. Is there any sort of migration path that would make this change feasible > in mainline Haskell in the medium term (2-5 years)? I don't think we'll ever see String changed in any significant way by default unless great pains are taken to do so. As I mention, you'd probably be breaking everything using String. If you don't want to work with a list of characters then use a different thing, most likely Text. Honestly, if your only motivation is that beginners might get a wrong idea, I don't think anything along your questions is even worth considering. Usually it takes few minutes top to tell a newbie in #haskell that they probably want Text or whatever, if they even care. Trying very hard to change what we already have and still make it as accessible as it is today is simply something I can't justify in any way I try. > Thanks! I would welcome any references or links that my cursory googling > has failed to find. > > -- Andrew > > -- Mateusz K. From clintonmead at gmail.com Tue May 19 05:19:11 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Tue, 19 May 2015 15:19:11 +1000 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: <555AC04D.2030301@fuuzetsu.co.uk> References: <555AC04D.2030301@fuuzetsu.co.uk> Message-ID: I've noticed improved list performance in GHC 7.10.1. In GHC 7.8, a simple "sum" function worked faster on a "Stream" than a List, a Stream being a data type with a state and successor function. The List version was around 10 times slower than the stream version when it came to summing Ints. However GHC 7.10.1 compiles the list away, so the list version, stream version, and accumulating parameter recursive function version now all run in the same time. If GHC continues to learn to optimise away lists effectively, [Char] may not be a performance issue after all. On Tue, May 19, 2015 at 2:47 PM, Mateusz Kowalczyk wrote: > On 05/18/2015 11:44 PM, Andrew Gibiansky wrote: > > Hey all, > > > > In the earlier haskell-cafe discussion of IsString, someone mentioned > that > > it would be nice to abandon [Char] as the blessed string type in Haskell. > > I've thought about this on and off for a while now, and think that the > fact > > that [Char] is the default string type is a really big issue (for > example, > > it gives beginners the idea that Haskell is incredibly slow, because > > everything that involves string processing is using linked lists). > > > > I am not proposing anything, but am curious as to what already has been > > discussed: > > Just me few cents below. > > > 1. Has the possibility of migrating away from [Char] been investigated > > before? > > Migrating away to what? > > > 2. What gains could we see in ease of use, performance, etc, if [Char] > was > > deprecated? > > Deprecated in favour of what? > > > 3. What could replace [Char], while retaining the same ease of use for > > writing string manipulation functions (pattern matching, etc)? > > ViewPatterns could let us imitate the pattern match at least but you'd > still have to reconstruct from a list on RHS. Basically to me you're > asking whether we can work with lists, using usual list things including > constructors and presumably all list-y functions but without using > lists? We either want one or another ;). But depending on what we want > and if you're willing to give up the : and [] syntax, one could probably > do well here anyway. But in any scenario, you'd be breaking every piece > of code using String ever anyway. > > > 4. Is there any sort of migration path that would make this change > feasible > > in mainline Haskell in the medium term (2-5 years)? > > I don't think we'll ever see String changed in any significant way by > default unless great pains are taken to do so. As I mention, you'd > probably be breaking everything using String. If you don't want to work > with a list of characters then use a different thing, most likely Text. > > Honestly, if your only motivation is that beginners might get a wrong > idea, I don't think anything along your questions is even worth > considering. Usually it takes few minutes top to tell a newbie in > #haskell that they probably want Text or whatever, if they even care. > Trying very hard to change what we already have and still make it as > accessible as it is today is simply something I can't justify in any way > I try. > > > Thanks! I would welcome any references or links that my cursory googling > > has failed to find. > > > > -- Andrew > > > > > > -- > Mateusz K. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Tue May 19 05:50:13 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Tue, 19 May 2015 08:50:13 +0300 Subject: [Haskell-cafe] =?utf-8?b?RGF0YSBjb25zdHJ1Y3RvciDigJhNaW51c+KAmSBj?= =?utf-8?q?omes_from_an_un-promotable_type_=E2=80=98Ints=E2=80=99?= In-Reply-To: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> References: <4696F212-1953-4065-8774-07D0B1332DA8@cis.upenn.edu> Message-ID: Wow, that's exciting news! 18 ????. 2015 16:05 "Richard Eisenberg" ????: > > On May 18, 2015, at 5:02 AM, "Nicholls, Mark" > wrote: > > > The problem being the any definition containing promoted types, cannot be > promoted. > > Is that a fair summary? > > > Yes. Only "simple" types can be promoted. > > But this will all change in 7.12, where just about anything will promote. > For now, you may want to switch to Agda, but come back in a year's time. :) > > Richard > > > > *From:* Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] *On Behalf > Of *Nicholls, Mark > *Sent:* 15 May 2015 1:35 PM > *To:* Andras Slemmer > *Cc:* haskell-cafe at haskell.org > *Subject:* Re: [Haskell-cafe] Data constructor ?Minus? comes from an > un-promotable type ?Ints? > > Its inhabited, and I can potentials readon about positive and negative and > zero?because these are mapped to type constructors?.but they are not > isomorphic to the integers?they are just 3 sub classes of the class of > integers? > > That aint much good. > > I assume its because the even the type of my data constructor Zero is? > > Ints 'Z 'Z > > If I wanted an isomorphic type constructor?it would need to be? > > 'Ints ''Z ''Z > > (I know haskell doesn?t promote the type Ints to a kind ?Ints, it > irritatingly promotes it to Ints?.) > > ??Z doesn?t exist?? > > hmmm > > > *From:* Nicholls, Mark > *Sent:* 15 May 2015 1:03 PM > *To:* 'Andras Slemmer' > *Cc:* 'haskell-cafe at haskell.org' > *Subject:* RE: [Haskell-cafe] Data constructor ?Minus? comes from an > un-promotable type ?Ints? > > Ignore me?of course it?s inhabited?.. > > *From:* Nicholls, Mark > *Sent:* 15 May 2015 12:58 PM > *To:* 'Andras Slemmer' > *Cc:* haskell-cafe at haskell.org > *Subject:* RE: [Haskell-cafe] Data constructor ?Minus? comes from an > un-promotable type ?Ints? > > Ah, ok that?s a vote for agda. > > Your ints definition isn?t directly inhabited?..but maybe that doesn?t > matter?.thanks I?ll struggle on a bit. > > (yes my definition is mildly problematic mathematically, I have 3 > (coincident) zeros). > > *From:* Andras Slemmer [mailto:0slemi0 at gmail.com <0slemi0 at gmail.com>] > *Sent:* 15 May 2015 10:50 AM > *To:* Nicholls, Mark > *Cc:* haskell-cafe at haskell.org > *Subject:* Re: [Haskell-cafe] Data constructor ?Minus? comes from an > un-promotable type ?Ints? > > > If you want to stick to your Ints datastructure then you need a stronger > dependent type theory that allows you to reason about "double-promoted" > types. > > However in this case you don't really need that complexity: > > data Ints > = Zero > | Minus Nat > | Plus Nat > is sufficient enough. Although this definition is probably not the one you > want to use... take a look at > http://www.cse.chalmers.se/~nad/repos/lib/src/Data/Integer.agda for hints > > On 14 May 2015 at 18:36, Nicholls, Mark wrote: > Hello, > > I clearly don?t really know what I?m doing?but at least I know it?. > > Here we defined the Naturals?and then attempt to construct the Integers?. > > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE ExplicitForAll #-} > > {-# LANGUAGE FlexibleContexts #-} > > {-# LANGUAGE FlexibleInstances #-} > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE PolyKinds #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE UndecidableInstances #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > import Prelude hiding (head, tail, (++), (+), replicate) > > import qualified Prelude as P > > naturals > > > data Nat where > > Z :: Nat > > S :: Nat -> Nat > > I can now define + and * and prove things about them?1 * x == x > etc?.nice..but lets put that on one side. > > Borrow bits and bobs from singletons > > > data family Sing (a :: k) > > Borrow bits and bobs from singletons..i.e. the isomorphic values?my proofs > in nat now map to SNat?double nice. > > > type SNat = (Sing :: Nat -> *) > > Create the integers by following my nose??(the integers are the > equivalence class of pairs of naturals?.) > > i.e. we have ?positive? or ?negative? or ?zero?? > > > data Ints (a :: Nat) (b :: Nat) where > > Minus :: SNat a -> Ints 'Z a > > Zero :: Ints 'Z 'Z > > Plus :: SNat a -> Ints a 'Z > > > > Ok?.this works as a set of values?.but?. > > I can?t prove anything about these because the data constructors for my > integers aren?t ?promotable??..so I cant do the same trick I did with Nat. > > ?:k Zero? ?.. > Data constructor ?Zero? comes from an un-promotable type ?Ints? > In a type in a GHCi command: Zero > > I?ve tried rejigging this in various futile and ignorant manners?.but the > bottom line is its??un-promotable??..look at the docs, and it says > something vague about GADT?s?but that isnt the problem directly. > > Is there a nifty way around this log jam? > (I can start proving things about ?(Nat,Nat)?.but this will soon become a > bit clumsy?.) > > Or do I just stop here and wrestle with getting agda installed and lose > another few months in the agda-caf? (which appears to be a very nice place > somewhere in finland?.hmmmm?I think that?s something different). > > (I?ve already allegedly descended into cabal hell following my nose with > an agda install? > setup.exe: The program cpphs version >=1.18.6 && <1.19 is required but the > version found at C:\Users\nichom\AppData\Roaming\cabal\bin\cpphs.exe is > version 1.19). > > computer science would be good, if it wasn?t for the computers. > > > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by > copyright (and other intellectual property rights). If you are not the > intended recipient please e-mail the sender and then delete the email and > any attached files immediately. Any further use or dissemination is > prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and > any attachments are virus free, it is your responsibility to ensure that > this message and any attachments are virus free and do not affect your > systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, > data corruption, non-delivery, wrongful interception and unauthorised > amendment. If you communicate with us by e-mail, you acknowledge and assume > these risks, and you agree to take appropriate measures to minimise these > risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, > Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions > International, Be Viacom, Viacom International Media Networks and VIMN and > Comedy Central are all trading names of MTV Networks Europe. MTV Networks > Europe is a partnership between MTV Networks Europe Inc. and Viacom > Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley > Crescent, London, NW1 8TT. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by > copyright (and other intellectual property rights). If you are not the > intended recipient please e-mail the sender and then delete the email and > any attached files immediately. Any further use or dissemination is > prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and > any attachments are virus free, it is your responsibility to ensure that > this message and any attachments are virus free and do not affect your > systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, > data corruption, non-delivery, wrongful interception and unauthorised > amendment. If you communicate with us by e-mail, you acknowledge and assume > these risks, and you agree to take appropriate measures to minimise these > risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, > Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions > International, Be Viacom, Viacom International Media Networks and VIMN and > Comedy Central are all trading names of MTV Networks Europe. MTV Networks > Europe is a partnership between MTV Networks Europe Inc. and Viacom > Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley > Crescent, London, NW1 8TT. > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by > copyright (and other intellectual property rights). If you are not the > intended recipient please e-mail the sender and then delete the email and > any attached files immediately. Any further use or dissemination is > prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and > any attachments are virus free, it is your responsibility to ensure that > this message and any attachments are virus free and do not affect your > systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, > data corruption, non-delivery, wrongful interception and unauthorised > amendment. If you communicate with us by e-mail, you acknowledge and assume > these risks, and you agree to take appropriate measures to minimise these > risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, > Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions > International, Be Viacom, Viacom International Media Networks and VIMN and > Comedy Central are all trading names of MTV Networks Europe. MTV Networks > Europe is a partnership between MTV Networks Europe Inc. and Viacom > Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley > Crescent, London, NW1 8TT. > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From heraldhoi at gmail.com Tue May 19 06:31:29 2015 From: heraldhoi at gmail.com (Geraldus) Date: Tue, 19 May 2015 06:31:29 +0000 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: Also there is good article by Chris Done: http://chrisdone.com/posts/data-typeable. Hope this will be helpful. ??, 19 ??? 2015 ?. ? 5:20, Adam Bergmark : > Using GHC Generics: > http://hackage.haskell.org/package/generic-deriving-1.7.0/docs/Generics-Deriving-ConNames.html > > > On Tue, May 19, 2015 at 1:29 AM, Tikhon Jelvis wrote: > >> You can get this information through the Data.Data module. There are two >> typeclasses which can be (have to be, I believe) derived for your data >> type, Data and Typeable. The Data class lets you access a representation of >> your type including type constructors. >> >> To set this up, you need to import Data.Data and enable the >> DeriveDataTypeable extension: >> >> {-# LANGUAGE DeriveDataTypeable #-} >> import Data.Data >> >> data Codes = A0100A | A0500A deriving (Show, Data, Typeable) >> >> Now you can get a representation of the type: >> >> ?> dataTypeOf (undefined :: Codes) >> DataType {tycon = "Main.Codes", datarep = AlgRep [A0100A,A0500A]} >> >> Since your type is an algebraic data type (AlgRep), the DataRep contains >> its constructors, which you can inspect with functions from the Data.Data >> module. >> >> On Mon, May 18, 2015 at 4:20 PM, Cody Goodman < >> codygman.consulting at gmail.com> wrote: >> >>> Can I use either template Haskell, GHC Generics, or something else to >>> get the list of Constructors in Codes? Then I could do `map show >>> codeSumTypeMembers` and get `["A0100A","A0500A"]`? >>> >>> Here's an example of solving this problem manually: >>> >>> data Codes = A0100A | A0500A deriving Show >>> >>> codeExists "A0100A" = True >>> codeExists "A0500A" = True >>> codeExists _ = False >>> >>> >>> main = print $ codeExists xmlElementName >>> where xmlElementName = "A0500A" >>> >>> -- ?> main >>> -- True >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Tue May 19 08:58:02 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 19 May 2015 10:58:02 +0200 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: <555AC04D.2030301@fuuzetsu.co.uk> Message-ID: <1432025882.2029.9.camel@joachim-breitner.de> Hi, Am Dienstag, den 19.05.2015, 15:19 +1000 schrieb Clinton Mead: > However GHC 7.10.1 compiles the list away, so the list version, stream > version, and accumulating parameter recursive function version now all > run in the same time. glad to hear that (I believe I am partly responsible for that). But > If GHC continues to learn to optimise away lists effectively, [Char] > may not be a performance issue after all. is too optimistic. [Char] will never be a good choice for efficient string manipulation; the optimizations you mention only work in very specific circumstances (at least: lists used exactly once, by a ?good consumer? and produced by a ?good producer?). The sufficiently smart compiler continues to be an utopia. (Which does not stop us from working towards it.) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From anatoly.zaretsky at gmail.com Tue May 19 09:03:52 2015 From: anatoly.zaretsky at gmail.com (Anatoly Zaretsky) Date: Tue, 19 May 2015 12:03:52 +0300 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: On Tue, May 19, 2015 at 2:20 AM, Cody Goodman wrote: > > data Codes = A0100A | A0500A deriving Show > > codeExists "A0100A" = True > codeExists "A0500A" = True > codeExists _ = False > data Codes = A0100A | A0500A deriving Read codeExists code = case reads code of [(_, "")] -> True _ -> False Or with -XPatternGuards: codeExists code | [(_, "")] <- reads code = True | otherwise = False From anatoly.zaretsky at gmail.com Tue May 19 09:12:21 2015 From: anatoly.zaretsky at gmail.com (Anatoly Zaretsky) Date: Tue, 19 May 2015 12:12:21 +0300 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: On Tue, May 19, 2015 at 12:03 PM, Anatoly Zaretsky wrote: > > data Codes = A0100A | A0500A deriving Read > > codeExists code = > case reads code of > [(_, "")] -> True > _ -> False > > Or with -XPatternGuards: > > codeExists code | [(_, "")] <- reads code = True > | otherwise = False Oops, should have checked the types before posting: codeExists code = case reads code :: [(Codes, String)] of [(_, "")] -> True _ -> False Otherwise the compiler could not guess the right Read instance. From mail at joachim-breitner.de Tue May 19 09:15:25 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Tue, 19 May 2015 11:15:25 +0200 Subject: [Haskell-cafe] Automatically generate sum type members -> [String] In-Reply-To: References: Message-ID: <1432026925.2029.18.camel@joachim-breitner.de> Hi, Am Dienstag, den 19.05.2015, 12:03 +0300 schrieb Anatoly Zaretsky: > On Tue, May 19, 2015 at 2:20 AM, Cody Goodman > wrote: > > > > data Codes = A0100A | A0500A deriving Show > > > > codeExists "A0100A" = True > > codeExists "A0500A" = True > > codeExists _ = False > > > > data Codes = A0100A | A0500A deriving Read > > codeExists code = > case reads code of > [(_, "")] -> True > _ -> False > > Or with -XPatternGuards: > > codeExists code | [(_, "")] <- reads code = True > | otherwise = False since base-4.6, there is readMaybe :: Read a => String -> Maybe a in Text.Read. So it might be nicer to write codeExists code = isJust (readMaybe code :: Maybe Codes) Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From kazu at iij.ad.jp Tue May 19 12:06:45 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 19 May 2015 21:06:45 +0900 (JST) Subject: [Haskell-cafe] advanced cabal configuration Message-ID: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> Hi, I'm a maintainer of simple-sendfile and need to implement the following is to rescue 32bit Linux: - If the COff size is 8, the following FFI is used: foreign import ccall unsafe "sendfile64" c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) - Otherwise, the following FFI is used: foreign import ccall unsafe "sendfile" c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) How can I implement this? I guess that Setup.hs should evaluate (sizeOf (1 :: COff)) and define a C macro, say LARGE_OFFSET and write the following code. #ifdef LARGE_OFFSET foreign import ccall unsafe "sendfile64" #else foreign import ccall unsafe "sendfile" #endif I have no experience to use Build-Type: other than Simple in cabal files. Would someone explain how to implement it concretely or suggest examples which implement similar things? For more informaion, please read: https://github.com/yesodweb/wai/issues/372 Thanks. --Kazu From lanablack at amok.cc Tue May 19 12:11:05 2015 From: lanablack at amok.cc (Lana Black) Date: Tue, 19 May 2015 12:11:05 +0000 Subject: [Haskell-cafe] Request for maintainers In-Reply-To: <59359F54-E9A8-461F-863E-C445E5C90EF6@gmail.com> References: <59359F54-E9A8-461F-863E-C445E5C90EF6@gmail.com> Message-ID: <20150519121105.GA1844@rhea> On 18:34 Sun 17 May , Fred Ross wrote: > I have finally accepted that I won't be part of the Haskell community in any real sense in the foreseeable future. There are three libraries that I am still the maintainer of that I need to hand off. Is there anyone who would take over any of the following? > > hdaemonize - Utilities for writing Unix daemons in Haskell > serial - Serial port access library > hscamwire - FFI bindings to camwire to access IIDC1394 Firewire cameras > > Fred Ross > http://madhadron.com > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe Hi Fred, I'd like to take over hdaemonize. From hesselink at gmail.com Tue May 19 12:51:53 2015 From: hesselink at gmail.com (Erik Hesselink) Date: Tue, 19 May 2015 14:51:53 +0200 Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> Message-ID: Could you use some combination of 'os' and 'arch' [0] in your cabal file to check for this, and then set a CPP define using 'CPP-options'? Erik [0] https://www.haskell.org/cabal/users-guide/developing-packages.html#conditions On Tue, May 19, 2015 at 2:06 PM, Kazu Yamamoto wrote: > Hi, > > I'm a maintainer of simple-sendfile and need to implement the > following is to rescue 32bit Linux: > > - If the COff size is 8, the following FFI is used: > > foreign import ccall unsafe "sendfile64" > c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > - Otherwise, the following FFI is used: > > foreign import ccall unsafe "sendfile" > c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > How can I implement this? > > I guess that Setup.hs should evaluate (sizeOf (1 :: COff)) and define > a C macro, say LARGE_OFFSET and write the following code. > > #ifdef LARGE_OFFSET > foreign import ccall unsafe "sendfile64" > #else > foreign import ccall unsafe "sendfile" > #endif > > I have no experience to use Build-Type: other than Simple in cabal > files. Would someone explain how to implement it concretely or > suggest examples which implement similar things? > > For more informaion, please read: > https://github.com/yesodweb/wai/issues/372 > > Thanks. > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From kazu at iij.ad.jp Tue May 19 13:26:32 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Tue, 19 May 2015 22:26:32 +0900 (JST) Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> Message-ID: <20150519.222632.48976923726483544.kazu@iij.ad.jp> Hi Erik, > Could you use some combination of 'os' and 'arch' [0] in your cabal > file to check for this, and then set a CPP define using 'CPP-options'? To my understanding, the COff size is somethime 4 and sometime 8 on 32bit Linux. I don't think we can capture this difference with 'os' and 'arch'. --Kazu From anselm.scholl at tu-harburg.de Tue May 19 13:59:57 2015 From: anselm.scholl at tu-harburg.de (Jonas Scholl) Date: Tue, 19 May 2015 15:59:57 +0200 Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> Message-ID: <555B41DD.4090407@tu-harburg.de> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256 Couldn't you write something like this? foreign import ccall unsafe "sendfile64" c_sendfile64 :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) foreign import ccall unsafe "sendfile" c_sendfile32 :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) c_sendfile = case sizeOf (undefined :: COff) of 4 -> c_sendfile32 8 -> c_sendfile64 _ -> error "COff has an unsupported size" Jonas On 05/19/2015 02:06 PM, Kazu Yamamoto (????) wrote: > Hi, > > I'm a maintainer of simple-sendfile and need to implement the > following is to rescue 32bit Linux: > > - If the COff size is 8, the following FFI is used: > > foreign import ccall unsafe "sendfile64" c_sendfile :: Fd -> Fd -> > Ptr COff -> CSize -> IO (#type ssize_t) > > - Otherwise, the following FFI is used: > > foreign import ccall unsafe "sendfile" c_sendfile :: Fd -> Fd -> > Ptr COff -> CSize -> IO (#type ssize_t) > > How can I implement this? > > I guess that Setup.hs should evaluate (sizeOf (1 :: COff)) and > define a C macro, say LARGE_OFFSET and write the following code. > > #ifdef LARGE_OFFSET foreign import ccall unsafe "sendfile64" #else > foreign import ccall unsafe "sendfile" #endif > > I have no experience to use Build-Type: other than Simple in cabal > files. Would someone explain how to implement it concretely or > suggest examples which implement similar things? > > For more informaion, please read: > https://github.com/yesodweb/wai/issues/372 > > Thanks. > > --Kazu _______________________________________________ Haskell-Cafe > mailing list Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJVW0HAAAoJEM0PYZBmfhoBSJUH/A/J1sxInz3sv7KN/qt2jKQN /qVOrm1tLDPBpIz0D3l5CaO/NrPYkzW+GHF6IxHswuO1suJLHIPJHHptJhLIB8mZ 83NRWtnbQh2nPTvVcj8Ey3BhsX/VEdqAr4fMP9y+NUlMrmHxIhyDPc6p2lvIVmiz OsnzAcIiRCt2HWhxCaum5c3xHyT0Dd3Zafmv5ygv2FUK9pxlUzdbCFRPP2dPwOE9 m6RM5i9/rl4SP3sJXYINCyP4wX28Y0+iqiL+POK4m0Eq9VvXy8pi/GpBiz8FohaH PEXdeOdCxyHE+OwsojdpNBy6PJZuh7A2EtBl4EsYMB70fNgV2w4xvNfAWNapdso= =ZQxj -----END PGP SIGNATURE----- From targen at gmail.com Tue May 19 14:06:32 2015 From: targen at gmail.com (=?UTF-8?Q?Manuel_G=C3=B3mez?=) Date: Tue, 19 May 2015 09:36:32 -0430 Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: <555B41DD.4090407@tu-harburg.de> References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> <555B41DD.4090407@tu-harburg.de> Message-ID: On Tue, May 19, 2015 at 9:29 AM, Jonas Scholl wrote: > foreign import ccall unsafe "sendfile64" > c_sendfile64 :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > foreign import ccall unsafe "sendfile" > c_sendfile32 :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > c_sendfile = case sizeOf (undefined :: COff) of > 4 -> c_sendfile32 > 8 -> c_sendfile64 > _ -> error "COff has an unsupported size" This has the advantage of being nicer to cross-compilers. Perhaps it won?t degrade performance significantly. From lanablack at amok.cc Tue May 19 16:10:19 2015 From: lanablack at amok.cc (Lana Black) Date: Tue, 19 May 2015 16:10:19 +0000 Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> Message-ID: <20150519161019.GB1844@rhea> On 21:06 Tue 19 May , Kazu Yamamoto wrote: > Hi, > > I'm a maintainer of simple-sendfile and need to implement the > following is to rescue 32bit Linux: > > - If the COff size is 8, the following FFI is used: > > foreign import ccall unsafe "sendfile64" > c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > - Otherwise, the following FFI is used: > > foreign import ccall unsafe "sendfile" > c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > How can I implement this? > > I guess that Setup.hs should evaluate (sizeOf (1 :: COff)) and define > a C macro, say LARGE_OFFSET and write the following code. > > #ifdef LARGE_OFFSET > foreign import ccall unsafe "sendfile64" > #else > foreign import ccall unsafe "sendfile" > #endif > > I have no experience to use Build-Type: other than Simple in cabal > files. Would someone explain how to implement it concretely or > suggest examples which implement similar things? > > For more informaion, please read: > https://github.com/yesodweb/wai/issues/372 > > Thanks. > > --Kazu > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe I believe you could use __USE_FILE_OFFSET64 macro imported from sys/types.h. I'm not sure if it's present on other than linux/glibc systems though. From madhadron at gmail.com Tue May 19 16:22:43 2015 From: madhadron at gmail.com (Fred Ross) Date: Tue, 19 May 2015 09:22:43 -0700 Subject: [Haskell-cafe] Request for maintainers In-Reply-To: References: <59359F54-E9A8-461F-863E-C445E5C90EF6@gmail.com> Message-ID: <7D2507C5-34C2-4CAF-9E3D-B2AD375547A4@gmail.com> Thank you! I've added you to the maintainers list. You might want to go ahead and fork the repository at https://github.com/madhadron/serial, update serial.cabal with your info, and upload a new version. Fred Ross On May 18, 2015, at 11:05 AM, Jose Calderon wrote: > Hello, > > I'll happily take the serial library off your hands. > > My hackage username is jmct. > > Cheers, > > Jose > http://jmct.cc > > > > On 18 May 2015 at 02:34, Fred Ross wrote: > I have finally accepted that I won't be part of the Haskell community in any real sense in the foreseeable future. There are three libraries that I am still the maintainer of that I need to hand off. Is there anyone who would take over any of the following? > > hdaemonize - Utilities for writing Unix daemons in Haskell > serial - Serial port access library > hscamwire - FFI bindings to camwire to access IIDC1394 Firewire cameras > > Fred Ross > http://madhadron.com > From gale at sefer.org Tue May 19 16:51:46 2015 From: gale at sefer.org (Yitzchak Gale) Date: Tue, 19 May 2015 19:51:46 +0300 Subject: [Haskell-cafe] text-icu (and FFI in general) on Windows 64 bits Message-ID: I was finally successful in getting text-icu to work on Windows 64 bits. This is probably an indication of what to expect in general for packages requiring FFI on Windows 64 bits. In the past, on 32 bits, the standard Windows binary distribution from the ICU site could be used together with msys/mingw, even though it was officially only for MSVC. This no longer seems to be the case for 64 bits. When I build text-icu in that way with a 64 bit GHC and the Windows 64-bit binary ICU distribution for MSVC, the resulting EXEs segfault as soon as any function from text-icu is called. There is no official ICU download for mingw-w64 binaries. But happily, the MSYS2 project does provide a pre-built ICU binary distribution for mingw-w64. It tends to be quite up-to-date; the current version is ICU 55.1. Note, however, that I was *not* able to use the partial MSYS2 that comes with MinGHC, because pacman seems to be missing. So the solution is: 1. Download and install 64-bit MSYS2, following the instructions on the site: http://msys2.github.io 2. In the MSYS2 shell window, get the ICU package for mingw-w64: pacman -S mingw64/mingw-w64-x86_64-icu 3. Now you can build the Haskell text-icu library using this command: cabal install --extra-lib-dirs="c:\path\to\msys64\mingw64\lib" --extra-include-dirs="c:\path\to\msys64\mingw64\include" text-icu 4. Provide the following DLLs with your EXE that uses text-icu: libicudt55.dll libicuin55.dll libicuuc55.dll libgcc_s_seh-1.dll libstdc++-6.dll Get them from: c:\path\to\msys64\mingw64\bin This not only compiles, but EXEs produced using this library actually run without segfaulting. You can even compile native Windows EXEs from C using ICU this way, with the gcc that is put on your path by the Haskell Platform installer (and probably also MinGHC, but I didn't try that). Just include -L and -I options to gcc with the same paths as above, and make sure to specify -licuuc -licudt etc. as needed. -Yitz From alois.cochard at gmail.com Tue May 19 17:02:32 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 19 May 2015 19:02:32 +0200 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) Message-ID: Hi all, I am currently writing a tool to automate the release and version bump of cabal projects. Currently you can call the tool by giving as argument the rank of the branch you want to bump, for example given 0.0.0.0: - `cabal-release 0` bump to `1` - `cabal-release 1` bump to `0.1` - `cabal-release 2` bump to `0.0.1` - `cabal-release 3` bump to `0.0.0.1` As we are not all robots (yet), I thought that in addition to this it would be great if the user could give a human friendly name for the rank. For now, here is what I have for the different rank: 0 == --major 1 == --major-fix 2 == --minor 3 == --minor-fix I'm curious to know what you think of those names? any suggestions or known established convention about that? Thanks -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Tue May 19 17:19:10 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 19 May 2015 19:19:10 +0200 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) In-Reply-To: References: Message-ID: "major-fix" seems strange to me. I'd expect major to bump the 2nd component since it's part of the major version. Likewise the PVP uses "patch" for the 4th component. On Tue, May 19, 2015 at 7:02 PM, Alois Cochard wrote: > Hi all, > > I am currently writing a tool to automate the release and version bump of > cabal projects. > > Currently you can call the tool by giving as argument the rank of the > branch you want to bump, for example given 0.0.0.0: > > - `cabal-release 0` bump to `1` > - `cabal-release 1` bump to `0.1` > - `cabal-release 2` bump to `0.0.1` > - `cabal-release 3` bump to `0.0.0.1` > > As we are not all robots (yet), I thought that in addition to this it > would be great if the user could give a human friendly name for the rank. > > For now, here is what I have for the different rank: > 0 == --major > 1 == --major-fix > 2 == --minor > 3 == --minor-fix > > I'm curious to know what you think of those names? any suggestions or > known established convention about that? > > Thanks > > -- > *?\ois* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Tue May 19 17:22:31 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Tue, 19 May 2015 19:22:31 +0200 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) In-Reply-To: References: Message-ID: That sounds great thanks, and I agree about `major-fix` I was just out of inspiration. Any idea for the very first component? simply `release` maybe? release/major/minor/patch On 19 May 2015 at 19:19, Adam Bergmark wrote: > "major-fix" seems strange to me. I'd expect major to bump the 2nd > component since it's part of the major version. Likewise the PVP uses > "patch" for the 4th component. > > > > On Tue, May 19, 2015 at 7:02 PM, Alois Cochard > wrote: > >> Hi all, >> >> I am currently writing a tool to automate the release and version bump of >> cabal projects. >> >> Currently you can call the tool by giving as argument the rank of the >> branch you want to bump, for example given 0.0.0.0: >> >> - `cabal-release 0` bump to `1` >> - `cabal-release 1` bump to `0.1` >> - `cabal-release 2` bump to `0.0.1` >> - `cabal-release 3` bump to `0.0.0.1` >> >> As we are not all robots (yet), I thought that in addition to this it >> would be great if the user could give a human friendly name for the rank. >> >> For now, here is what I have for the different rank: >> 0 == --major >> 1 == --major-fix >> 2 == --minor >> 3 == --minor-fix >> >> I'm curious to know what you think of those names? any suggestions or >> known established convention about that? >> >> Thanks >> >> -- >> *?\ois* >> http://twitter.com/aloiscochard >> http://github.com/aloiscochard >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From rf at rufflewind.com Tue May 19 17:48:09 2015 From: rf at rufflewind.com (Phil Ruffwind) Date: Tue, 19 May 2015 13:48:09 -0400 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) In-Reply-To: References: Message-ID: > Any idea for the very first component? simply `release` maybe? 'release' is quite an overloaded term already; I would suggest something along the lines of "epoch" or "era" or similar. That being said, the official PVP calls both the first and second components "major", so you could just say something like "majorA/majorB" or similar. From oleg.grenrus at iki.fi Tue May 19 18:07:49 2015 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 19 May 2015 21:07:49 +0300 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) In-Reply-To: References: Message-ID: <311000CF-CBBD-475A-9206-7B155E856AFC@iki.fi> I don?t know if you are aware of https://www.npmjs.com/package/semantic-release project It?s built for npm packages, but the same idea could be used for Haskell/cabal too. The idea is to use SCM commit message to decide which version digit to bump. - you still have to annotate changes - and if you try to cheat, but semantic-release runs old test suite again new version of the library to detect obvious breaking changes Seems there is https://github.com/blitzcode/hackage-diff which can be used to make the task of detecting API changes even easier. Hopefully these pointers let you make even greater tool! - Oleg > On 19 May 2015, at 20:02, Alois Cochard wrote: > > Hi all, > > I am currently writing a tool to automate the release and version bump of cabal projects. > > Currently you can call the tool by giving as argument the rank of the branch you want to bump, for example given 0.0.0.0 : > > - `cabal-release 0` bump to `1` > - `cabal-release 1` bump to `0.1` > - `cabal-release 2` bump to `0.0.1` > - `cabal-release 3` bump to `0.0.0.1` > > As we are not all robots (yet), I thought that in addition to this it would be great if the user could give a human friendly name for the rank. > > For now, here is what I have for the different rank: > 0 == --major > 1 == --major-fix > 2 == --minor > 3 == --minor-fix > > I'm curious to know what you think of those names? any suggestions or known established convention about that? > > Thanks > > -- > ?\ois > http://twitter.com/aloiscochard > http://github.com/aloiscochard _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 842 bytes Desc: Message signed with OpenPGP using GPGMail URL: From kc1956 at gmail.com Tue May 19 18:35:31 2015 From: kc1956 at gmail.com (KC) Date: Tue, 19 May 2015 11:35:31 -0700 Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? Message-ID: I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? "Out of the Tar Pit" talks about FRP - Functional Relational Programming -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey -------------- next part -------------- An HTML attachment was scrubbed... URL: From kazu at iij.ad.jp Wed May 20 02:02:23 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 20 May 2015 11:02:23 +0900 (JST) Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: <555B41DD.4090407@tu-harburg.de> References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> <555B41DD.4090407@tu-harburg.de> Message-ID: <20150520.110223.481611839452528313.kazu@iij.ad.jp> Hi Jonas, > Couldn't you write something like this? > > foreign import ccall unsafe "sendfile64" > c_sendfile64 :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > foreign import ccall unsafe "sendfile" > c_sendfile32 :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > > c_sendfile :: Fd -> Fd -> Ptr COff -> CSize -> IO (#type ssize_t) > c_sendfile = case sizeOf (undefined :: COff) of > 4 -> c_sendfile32 > 8 -> c_sendfile64 > _ -> error "COff has an unsupported size" I think that this is possible. Thank you for your suggestion! --Kazu From kazu at iij.ad.jp Wed May 20 02:04:21 2015 From: kazu at iij.ad.jp (Kazu Yamamoto (=?iso-2022-jp?B?GyRCOzNLXE9CSScbKEI=?=)) Date: Wed, 20 May 2015 11:04:21 +0900 (JST) Subject: [Haskell-cafe] advanced cabal configuration In-Reply-To: <20150519161019.GB1844@rhea> References: <20150519.210645.1946144666497118273.kazu@iij.ad.jp> <20150519161019.GB1844@rhea> Message-ID: <20150520.110421.1933160453962568395.kazu@iij.ad.jp> Hi Lana, > I believe you could use __USE_FILE_OFFSET64 macro imported from > sys/types.h. I'm not sure if it's present on other than linux/glibc > systems though. I don't think that __USE_FILE_OFFSET64 is available from sys/types.h. --Kazu From briand at aracnet.com Wed May 20 04:04:26 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Tue, 19 May 2015 21:04:26 -0700 Subject: [Haskell-cafe] glfw demos ? Message-ID: <20150519210426.4383ec1e@cedar.deldotd.com> Hi, Looks like the demos, including the one on the wiki page, and the glfw-b-demo package, are suffering from bit-rot. I was hoping somebody could point me to a small get-started demo. Meanwhile I am working on trying to get the wiki demo running. Thanks, Brian From voldermort at hotmail.com Wed May 20 08:18:50 2015 From: voldermort at hotmail.com (Harry .) Date: Wed, 20 May 2015 08:18:50 +0000 Subject: [Haskell-cafe] NoOO languages Message-ID: Could we mimic the marketing success of NoSQL databases by branding functional languages as NoOO (or even NoIO)? From lars at hupel.info Wed May 20 08:23:10 2015 From: lars at hupel.info (Lars Hupel) Date: Wed, 20 May 2015 10:23:10 +0200 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: Message-ID: <555C446E.8090501@hupel.info> > Could we mimic the marketing success of NoSQL databases by branding functional languages as NoOO (or even NoIO)? How about this? From alois.cochard at gmail.com Wed May 20 09:02:25 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 20 May 2015 11:02:25 +0200 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) In-Reply-To: <311000CF-CBBD-475A-9206-7B155E856AFC@iki.fi> References: <311000CF-CBBD-475A-9206-7B155E856AFC@iki.fi> Message-ID: Hi Oleg, I was aware of similar tools thanks to Oliver Charles who pointed me to that great python tool: http://dzil.org/, seems like semantic-release have some interesting features as well! Thanks for the pointers, especially `hackage-diff` that I was not aware of. It will help me a lot to get an even more automated tool :-) On 19 May 2015 at 20:07, Oleg Grenrus wrote: > I don?t know if you are aware of > https://www.npmjs.com/package/semantic-release project > > It?s built for npm packages, but the same idea could be used for > Haskell/cabal too. > > The idea is to use SCM commit message to decide which version digit to > bump. > - you still have to annotate changes > - and if you try to cheat, but semantic-release runs old test suite again > new version of the library to detect obvious breaking changes > > Seems there is https://github.com/blitzcode/hackage-diff which can be > used to make the task of detecting API changes even easier. > > Hopefully these pointers let you make even greater tool! > > - Oleg > > On 19 May 2015, at 20:02, Alois Cochard wrote: > > Hi all, > > I am currently writing a tool to automate the release and version bump of > cabal projects. > > Currently you can call the tool by giving as argument the rank of the > branch you want to bump, for example given 0.0.0.0: > > - `cabal-release 0` bump to `1` > - `cabal-release 1` bump to `0.1` > - `cabal-release 2` bump to `0.0.1` > - `cabal-release 3` bump to `0.0.0.1` > > As we are not all robots (yet), I thought that in addition to this it > would be great if the user could give a human friendly name for the rank. > > For now, here is what I have for the different rank: > 0 == --major > 1 == --major-fix > 2 == --minor > 3 == --minor-fix > > I'm curious to know what you think of those names? any suggestions or > known established convention about that? > > Thanks > > -- > *?\ois* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Wed May 20 09:17:22 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Wed, 20 May 2015 11:17:22 +0200 Subject: [Haskell-cafe] Naming convention for version branches (Package versioning) In-Reply-To: References: <311000CF-CBBD-475A-9206-7B155E856AFC@iki.fi> Message-ID: I'd also recommend using a,b,c,d for the components instead of 0,1,2,3. Our tool `bumper` uses numbers and i always have to try to remember that the 1st component is 0... On Wed, May 20, 2015 at 11:02 AM, Alois Cochard wrote: > Hi Oleg, > > I was aware of similar tools thanks to Oliver Charles who pointed me to > that great python tool: http://dzil.org/, seems like semantic-release > have some interesting features as well! > > Thanks for the pointers, especially `hackage-diff` that I was not aware > of. It will help me a lot to get an even more automated tool :-) > > > > On 19 May 2015 at 20:07, Oleg Grenrus wrote: > >> I don?t know if you are aware of >> https://www.npmjs.com/package/semantic-release project >> >> It?s built for npm packages, but the same idea could be used for >> Haskell/cabal too. >> >> The idea is to use SCM commit message to decide which version digit to >> bump. >> - you still have to annotate changes >> - and if you try to cheat, but semantic-release runs old test suite again >> new version of the library to detect obvious breaking changes >> >> Seems there is https://github.com/blitzcode/hackage-diff which can be >> used to make the task of detecting API changes even easier. >> >> Hopefully these pointers let you make even greater tool! >> >> - Oleg >> >> On 19 May 2015, at 20:02, Alois Cochard wrote: >> >> Hi all, >> >> I am currently writing a tool to automate the release and version bump of >> cabal projects. >> >> Currently you can call the tool by giving as argument the rank of the >> branch you want to bump, for example given 0.0.0.0: >> >> - `cabal-release 0` bump to `1` >> - `cabal-release 1` bump to `0.1` >> - `cabal-release 2` bump to `0.0.1` >> - `cabal-release 3` bump to `0.0.0.1` >> >> As we are not all robots (yet), I thought that in addition to this it >> would be great if the user could give a human friendly name for the rank. >> >> For now, here is what I have for the different rank: >> 0 == --major >> 1 == --major-fix >> 2 == --minor >> 3 == --minor-fix >> >> I'm curious to know what you think of those names? any suggestions or >> known established convention about that? >> >> Thanks >> >> -- >> *?\ois* >> http://twitter.com/aloiscochard >> http://github.com/aloiscochard >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> >> > > > -- > *?\ois* > http://twitter.com/aloiscochard > http://github.com/aloiscochard > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From fhofmann at techfak.uni-bielefeld.de Wed May 20 09:55:52 2015 From: fhofmann at techfak.uni-bielefeld.de (Florian Hofmann) Date: Wed, 20 May 2015 11:55:52 +0200 Subject: [Haskell-cafe] Automated Differentiation of Matrices (again) In-Reply-To: References: Message-ID: Hi Adam, I had a look at that and from my understanding it should be compatible with the `conjugateGradientDescent` function which is fine for me. I am not sure yet how this works out, but I'll see where I can get with this. Thanks, Florian 2015-05-12 0:29 GMT+02:00 adam vogt : > Hi Florian, > > The restriction Edward described is gone: here's an unboxed vector of > ForwardDouble: > . But I don't think > there's been any work to make hmatrix's Field class have a ForwardDouble > instance. I don't know of a ReverseDouble either. > > Regards, > Adam > > On Mon, May 11, 2015 at 6:24 AM, Florian Hofmann < > fhofmann at techfak.uni-bielefeld.de> wrote: > >> In [1](this) email thread Edward Kmett and Dominic Steinitz discuss the >> state of interoperability of `ad` and `hmatric` (or `repa`) with Edward >> hinting that the 4.0 line of `ad` might improve on the situation. >> >> Could someone elaborate on the state of affairs two years later? >> >> Florian >> >> [1]: >> https://mail.haskell.org/pipermail/haskell-cafe/2013-April/107561.html >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From gale at sefer.org Wed May 20 11:00:17 2015 From: gale at sefer.org (Yitzchak Gale) Date: Wed, 20 May 2015 14:00:17 +0300 Subject: [Haskell-cafe] text-icu (and FFI in general) on Windows 64 bits In-Reply-To: References: Message-ID: On reddit, /u/awson (is that Kyra?) pointed out the problem with linking against vanilla DLLs on 64-bit Windows is caused by a recently-fixed bug in GNU binutils: http://www.gnu.org/software/binutils/ https://sourceware.org/bugzilla/show_bug.cgi?id=16598 If that is the only problem, this might be fixed in an upcoming version of GHC. -Yitz On Tue, May 19, 2015 at 7:51 PM, Yitzchak Gale wrote: > I was finally successful in getting text-icu to > work on Windows 64 bits. This is probably > an indication of what to expect in general > for packages requiring FFI on Windows > 64 bits. > > In the past, on 32 bits, the standard Windows > binary distribution from the ICU site could be > used together with msys/mingw, even though > it was officially only for MSVC. This no longer > seems to be the case for 64 bits. When I > build text-icu in that way with a 64 bit GHC and > the Windows 64-bit binary ICU distribution for > MSVC, the resulting EXEs segfault as soon as > any function from text-icu is called. > > There is no official ICU download for > mingw-w64 binaries. But happily, the MSYS2 > project does provide a pre-built ICU binary > distribution for mingw-w64. It tends to be quite > up-to-date; the current version is ICU 55.1. > > Note, however, that I was *not* able to use the > partial MSYS2 that comes with MinGHC, because > pacman seems to be missing. > > So the solution is: > > 1. Download and install 64-bit MSYS2, following the > instructions on the site: > > http://msys2.github.io > > 2. In the MSYS2 shell window, get the ICU package > for mingw-w64: > > pacman -S mingw64/mingw-w64-x86_64-icu > > 3. Now you can build the Haskell text-icu library > using this command: > > cabal install --extra-lib-dirs="c:\path\to\msys64\mingw64\lib" > --extra-include-dirs="c:\path\to\msys64\mingw64\include" text-icu > > 4. Provide the following DLLs with your EXE that uses > text-icu: > > libicudt55.dll > libicuin55.dll > libicuuc55.dll > libgcc_s_seh-1.dll > libstdc++-6.dll > > Get them from: c:\path\to\msys64\mingw64\bin > > This not only compiles, but EXEs produced using > this library actually run without segfaulting. > > You can even compile native Windows EXEs from > C using ICU this way, with the gcc that is put on your > path by the Haskell Platform installer (and probably > also MinGHC, but I didn't try that). Just include > -L and -I options to gcc with the same paths as > above, and make sure to specify -licuuc -licudt > etc. as needed. > > -Yitz From vilevin at gmail.com Wed May 20 11:51:16 2015 From: vilevin at gmail.com (Aaron Levin) Date: Wed, 20 May 2015 11:51:16 +0000 Subject: [Haskell-cafe] NoOO languages In-Reply-To: <555C446E.8090501@hupel.info> References: <555C446E.8090501@hupel.info> Message-ID: In some sense Typesafe is already doing this with "Reactive." On Wed, May 20, 2015 at 4:23 AM Lars Hupel wrote: > > Could we mimic the marketing success of NoSQL databases by branding > functional languages as NoOO (or even NoIO)? > > How about this? > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From acowley at seas.upenn.edu Wed May 20 13:48:34 2015 From: acowley at seas.upenn.edu (Anthony Cowley) Date: Wed, 20 May 2015 09:48:34 -0400 Subject: [Haskell-cafe] glfw demos ? In-Reply-To: <20150519210426.4383ec1e@cedar.deldotd.com> References: <20150519210426.4383ec1e@cedar.deldotd.com> Message-ID: > On May 20, 2015, at 12:04 AM, wrote: > > Hi, > > Looks like the demos, including the one on the wiki page, and the glfw-b-demo package, are suffering from bit-rot. > > I was hoping somebody could point me to a small get-started demo. > > Meanwhile I am working on trying to get the wiki demo running. > > Thanks, > > > Brian They?re not quite minimal, but I try to keep the vinyl-gl demos building. They can also serve as basic glfw-b examples. Anthony From alois.cochard at gmail.com Wed May 20 14:08:16 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 20 May 2015 16:08:16 +0200 Subject: [Haskell-cafe] [ANN] codex 0.3 Message-ID: Hello Caf?, I have released a new version of `codex`[1] (a ctags file generator for cabal project and their dependencies). It should be noted that *this version now fully support the windows operating system*, thanks to a great contribution from Ben James. This new version include: - Tagging of the current project can be turned-off - Fix/Enhance the `emacs` and `sublime` default format - Tags file name is now configurable - Replace `curl` with `wrep` - Misc fixes and portability enhancement Thanks to the contributors (Ben James, Tal Walter, Eyal Lotem). [1] https://github.com/aloiscochard/codex -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Wed May 20 14:17:08 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 20 May 2015 16:17:08 +0200 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: <555C446E.8090501@hupel.info> Message-ID: Well, I'm not sure to see how the "Reactive" marketing campaign would related to one about NoOO. If you look at akka source code (or even usage example), it's imo very far from the values you can read on the manifesto linked by Lars. That being said, one might find some similarities on marketing aspect of the two initiative... On 20 May 2015 at 13:51, Aaron Levin wrote: > In some sense Typesafe is already doing this with "Reactive." > On Wed, May 20, 2015 at 4:23 AM Lars Hupel wrote: > >> > Could we mimic the marketing success of NoSQL databases by branding >> functional languages as NoOO (or even NoIO)? >> >> How about this? >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben.ford at baml.com Wed May 20 14:27:59 2015 From: ben.ford at baml.com (Ford, Ben) Date: Wed, 20 May 2015 14:27:59 +0000 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: Message-ID: <4BE6D556240AFE488AAB90F9535FAD57A15AA7@smtp_mail.bankofamerica.com> I think Haskell already suffers enough in adoption without giving it the slogan Noooo :-) -----Original Message----- From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of Harry . Sent: 20 May 2015 09:19 To: haskell-cafe at haskell.org Subject: [Haskell-cafe] NoOO languages Could we mimic the marketing success of NoSQL databases by branding functional languages as NoOO (or even NoIO)? _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. From ben.ford at baml.com Wed May 20 14:29:09 2015 From: ben.ford at baml.com (Ford, Ben) Date: Wed, 20 May 2015 14:29:09 +0000 Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? In-Reply-To: References: Message-ID: <4BE6D556240AFE488AAB90F9535FAD57A15AB7@smtp_mail.bankofamerica.com> There?s https://github.com/khibino/haskell-relational-record and https://github.com/tomjaguarpaw/haskell-opaleye Ben From: Haskell-Cafe [mailto:haskell-cafe-bounces at haskell.org] On Behalf Of KC Sent: 19 May 2015 19:36 To: haskell-cafe Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? "Out of the Tar Pit" talks about FRP - Functional Relational Programming -- -- Sent from an expensive device which will be obsolete in a few months! :D Casey ---------------------------------------------------------------------- This message, and any attachments, is for the intended recipient(s) only, may contain information that is privileged, confidential and/or proprietary and subject to important terms and conditions available at http://www.bankofamerica.com/emaildisclaimer. If you are not the intended recipient, please delete this message. -------------- next part -------------- An HTML attachment was scrubbed... URL: From spam at scientician.net Wed May 20 14:30:59 2015 From: spam at scientician.net (Bardur Arantsson) Date: Wed, 20 May 2015 16:30:59 +0200 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: <555C446E.8090501@hupel.info> Message-ID: On 05/20/2015 04:17 PM, Alois Cochard wrote: > Well, I'm not sure to see how the "Reactive" marketing campaign would > related to one about NoOO. > > If you look at akka source code (or even usage example), it's imo very far > from the values you can read on the manifesto linked by Lars. > I think it's akka-streams[1] that's supposed to be following the Reactive hype-train. [1] Which is currently at 1.0-RC2, I think. Regards, From vilevin at gmail.com Wed May 20 14:48:39 2015 From: vilevin at gmail.com (Aaron Levin) Date: Wed, 20 May 2015 10:48:39 -0400 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: <555C446E.8090501@hupel.info> Message-ID: Marketing is rarely about truth. While you are correct that "Reactive" programming is not specific to Functional Programming, I believe it is being conflated with it by industry and non-FPers. Anyway, it was just a comment / observation I've had. As Ben said, we should steer clear of anything "Nooooooooooooo" related. Marketing is hard. People are confusing. Sloganeering is an art. NoOO is doomed to produce too many memes. NotOnlyOO makes me think of YOLO for some reason. Best, Aaron Levin On Wed, May 20, 2015 at 10:30 AM, Bardur Arantsson wrote: > On 05/20/2015 04:17 PM, Alois Cochard wrote: > > Well, I'm not sure to see how the "Reactive" marketing campaign would > > related to one about NoOO. > > > > If you look at akka source code (or even usage example), it's imo very > far > > from the values you can read on the manifesto linked by Lars. > > > > I think it's akka-streams[1] that's supposed to be following the > Reactive hype-train. > > [1] Which is currently at 1.0-RC2, I think. > > Regards, > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Aaron Levin / Weird Canada www.aaronlevin.ca / www.weirdcanada.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Wed May 20 15:14:32 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 20 May 2015 17:14:32 +0200 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: <555C446E.8090501@hupel.info> Message-ID: I could not agree more Aaron! Let's just avoid: success at all cost ;-) On 20 May 2015 at 16:48, Aaron Levin wrote: > Marketing is rarely about truth. While you are correct that "Reactive" > programming is not specific to Functional Programming, I believe it is > being conflated with it by industry and non-FPers. > > Anyway, it was just a comment / observation I've had. As Ben said, we > should steer clear of anything "Nooooooooooooo" related. > > Marketing is hard. People are confusing. Sloganeering is an art. NoOO is > doomed to produce too many memes. NotOnlyOO makes me think of YOLO for some > reason. > > Best, > > Aaron Levin > > On Wed, May 20, 2015 at 10:30 AM, Bardur Arantsson > wrote: > >> On 05/20/2015 04:17 PM, Alois Cochard wrote: >> > Well, I'm not sure to see how the "Reactive" marketing campaign would >> > related to one about NoOO. >> > >> > If you look at akka source code (or even usage example), it's imo very >> far >> > from the values you can read on the manifesto linked by Lars. >> > >> >> I think it's akka-streams[1] that's supposed to be following the >> Reactive hype-train. >> >> [1] Which is currently at 1.0-RC2, I think. >> >> Regards, >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > Aaron Levin / Weird Canada > www.aaronlevin.ca / www.weirdcanada.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From kane at kane.cx Wed May 20 15:42:11 2015 From: kane at kane.cx (David Kraeutmann) Date: Wed, 20 May 2015 17:42:11 +0200 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: <555C446E.8090501@hupel.info> Message-ID: OO is OOver. ...SCNR On May 20, 2015 4:48 PM, "Aaron Levin" wrote: > Marketing is rarely about truth. While you are correct that "Reactive" > programming is not specific to Functional Programming, I believe it is > being conflated with it by industry and non-FPers. > > Anyway, it was just a comment / observation I've had. As Ben said, we > should steer clear of anything "Nooooooooooooo" related. > > Marketing is hard. People are confusing. Sloganeering is an art. NoOO is > doomed to produce too many memes. NotOnlyOO makes me think of YOLO for some > reason. > > Best, > > Aaron Levin > > On Wed, May 20, 2015 at 10:30 AM, Bardur Arantsson > wrote: > >> On 05/20/2015 04:17 PM, Alois Cochard wrote: >> > Well, I'm not sure to see how the "Reactive" marketing campaign would >> > related to one about NoOO. >> > >> > If you look at akka source code (or even usage example), it's imo very >> far >> > from the values you can read on the manifesto linked by Lars. >> > >> >> I think it's akka-streams[1] that's supposed to be following the >> Reactive hype-train. >> >> [1] Which is currently at 1.0-RC2, I think. >> >> Regards, >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > > -- > Aaron Levin / Weird Canada > www.aaronlevin.ca / www.weirdcanada.com > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Wed May 20 19:09:33 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Wed, 20 May 2015 21:09:33 +0200 Subject: [Haskell-cafe] NoOO languages In-Reply-To: References: <555C446E.8090501@hupel.info> Message-ID: OOP is a kind of low level programming. At the heart, OOP is a sophisticated way to integrate state machines. The problem that OOP tried to solve was event handling (SIMULA and Smalltalk) The inversion of control aka. "state machine" is the standard solution for this problem. It is the model that drive web frameworks and GUIs. Whenever there are asynchronous things like HTTP requests, interruptions , mouse events, there are state machines. OOP just split the state machine in smaller states machines, encapsulating each small piece of state together with the methods that serve them. So OOP is a more controlled way to deal with the problem of inversion of control. But OOP is like integrating chips without a serial bus. the data is in the form of state embedded in each component. This state must be extracted with explicit calls from one element to another ,with one-to-one connections. With a serial bus the data flows and each element get its data on the fly. If a component need it he just catches it from the bus. Without a serial bus each element must explicitly connect to each other in precise ways, There is no composability. With a serial bus the hardware component can be plugged in a single socket. OOP is like creating custom hardware everytime for every problem. since there is no composability, everything must be done from scratch. there are no reusable objects beyond basic containers encapsulated in objects. The reactive concept is basically an state machine with a single method handler: the reactive expression, which is pure more or less. This expression is called to respond every asynchronous event. This single handler is preceded by an event preprocessor, that is called before calling the reactive expression. But by taming continuations, Monadic programming with the asynchronous effect can provide the software equivalent of the serial bus connector, and can let the programmer to express the flow of an entire application with asynchronous things happening all along the expression, not only on the top, like interruptions or events, that may trigger with multiple threads, all of this within in a single, seamless, monadic expression. And moreover, this application may be composable with others: https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers#the-oop-non-solution-half-solution 2015-05-20 17:42 GMT+02:00 David Kraeutmann : > OO is OOver. > > ...SCNR > On May 20, 2015 4:48 PM, "Aaron Levin" wrote: > >> Marketing is rarely about truth. While you are correct that "Reactive" >> programming is not specific to Functional Programming, I believe it is >> being conflated with it by industry and non-FPers. >> >> Anyway, it was just a comment / observation I've had. As Ben said, we >> should steer clear of anything "Nooooooooooooo" related. >> >> Marketing is hard. People are confusing. Sloganeering is an art. NoOO is >> doomed to produce too many memes. NotOnlyOO makes me think of YOLO for some >> reason. >> >> Best, >> >> Aaron Levin >> >> On Wed, May 20, 2015 at 10:30 AM, Bardur Arantsson >> wrote: >> >>> On 05/20/2015 04:17 PM, Alois Cochard wrote: >>> > Well, I'm not sure to see how the "Reactive" marketing campaign would >>> > related to one about NoOO. >>> > >>> > If you look at akka source code (or even usage example), it's imo very >>> far >>> > from the values you can read on the manifesto linked by Lars. >>> > >>> >>> I think it's akka-streams[1] that's supposed to be following the >>> Reactive hype-train. >>> >>> [1] Which is currently at 1.0-RC2, I think. >>> >>> Regards, >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> >> -- >> Aaron Levin / Weird Canada >> www.aaronlevin.ca / www.weirdcanada.com >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From zocca.marco at gmail.com Thu May 21 04:20:51 2015 From: zocca.marco at gmail.com (Marco Zocca) Date: Thu, 21 May 2015 06:20:51 +0200 Subject: [Haskell-cafe] Library design around FFI library Message-ID: I'm implementing the low-level interface to a large C library (using c2hs). The C functions can be broadly classified by: *) the main datastructure they operate on, e.g. returnType AFunction (A* a, ...); *) creation, modification, read access, destruction operations for each of these datastructures, following a common pattern: ACreate(), ASet1(), ASet2(), .., ARead(), ADestroy(), BCreate(), etc. The library rests on top of MPI, so there are e.g. AScatterBegin(), AScatterEnd() function pairs that account for potentially large delays associated with computing and moving data around. On the Haskell side, the C pointer types are represented as e.g. data Ah = Ah (Ptr Ah) deriving instance Storable Ah and e.g. a Create function returns the representation of the fresh pointer along with the usual integer error code: ahCreate :: MPIComm -> IO (Ah, Err) What abstraction may I use to capture logic such as: *) separate read-only functions from the potentially overwriting ones *) guarantee precedence relations (e.g. computation can only occur after initialization) *) collect or even compose error codes, letting computation go through iff Err==0 (e.g. a n-ary Maybe ?) Sequencing in the IO monad causes all effectful functions to run and return their result and/or error code. All feedback is welcome; Thank you in advance From zocca.marco at gmail.com Thu May 21 04:22:11 2015 From: zocca.marco at gmail.com (Marco Zocca) Date: Thu, 21 May 2015 06:22:11 +0200 Subject: [Haskell-cafe] Library design around FFI library In-Reply-To: References: Message-ID: I meant newtype Ah = Ah (Ptr Ah) not data Ah = Ah (Ptr Ah) Thanks On 21 May 2015 at 06:20, Marco Zocca wrote: > I'm implementing the low-level interface to a large C library (using c2hs). > > The C functions can be broadly classified by: > *) the main datastructure they operate on, e.g. > returnType AFunction (A* a, ...); > *) creation, modification, read access, destruction operations for > each of these datastructures, following a common pattern: > ACreate(), ASet1(), ASet2(), .., ARead(), ADestroy(), BCreate(), etc. > > The library rests on top of MPI, so there are e.g. AScatterBegin(), > AScatterEnd() function pairs that account for potentially large delays > associated with computing and moving data around. > > On the Haskell side, the C pointer types are represented as e.g. > data Ah = Ah (Ptr Ah) > deriving instance Storable Ah > > and e.g. a Create function returns the representation of the fresh > pointer along with the usual integer error code: > ahCreate :: MPIComm -> IO (Ah, Err) > > > What abstraction may I use to capture logic such as: > *) separate read-only functions from the potentially overwriting ones > *) guarantee precedence relations (e.g. computation can only occur > after initialization) > *) collect or even compose error codes, letting computation go through > iff Err==0 (e.g. a n-ary Maybe ?) Sequencing in the IO monad causes > all effectful functions to run and return their result and/or error > code. > > All feedback is welcome; > Thank you in advance From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu May 21 09:31:58 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 21 May 2015 10:31:58 +0100 Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? In-Reply-To: References: Message-ID: <20150521093158.GZ13983@weber> On Tue, May 19, 2015 at 11:35:31AM -0700, KC wrote: > I'm reading #OutOfTheTarPit does ghc have a relational model built in for > state? > > "Out of the Tar Pit" talks about FRP - Functional Relational Programming I guess you're looking for an "in memory" relational implementation. Opaleye and Relational Record, that Ben Ford mentioned, are for building queries for external SQL databases. For some time now I've been thinking about implementing such an "in memory" database with the same API as Opaleye, and I know Edward Kmett has thought about efficient ways to implement such a thing using the techniques of "discrimination" that he is fond of. I for one don't have anything to show yet, but I will certainly announce it here if and when I do. Tom From ollie at ocharles.org.uk Thu May 21 11:55:53 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 21 May 2015 12:55:53 +0100 Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? In-Reply-To: <20150521093158.GZ13983@weber> References: <20150521093158.GZ13983@weber> Message-ID: The https://hackage.haskell.org/package/tables library is one way to get a somewhat relational view of in-memory data. - Ollie On Thu, May 21, 2015 at 10:31 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > On Tue, May 19, 2015 at 11:35:31AM -0700, KC wrote: > > I'm reading #OutOfTheTarPit does ghc have a relational model built in for > > state? > > > > "Out of the Tar Pit" talks about FRP - Functional Relational Programming > > I guess you're looking for an "in memory" relational implementation. > Opaleye and Relational Record, that Ben Ford mentioned, are for building > queries for external SQL databases. > > For some time now I've been thinking about implementing such an "in memory" > database with the same API as Opaleye, and I know Edward Kmett has thought > about efficient ways to implement such a thing using the techniques of > "discrimination" that he is fond of. I for one don't have anything to show > yet, but I will certainly announce it here if and when I do. > > Tom > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From agocorona at gmail.com Thu May 21 13:52:38 2015 From: agocorona at gmail.com (Alberto G. Corona ) Date: Thu, 21 May 2015 15:52:38 +0200 Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? In-Reply-To: References: <20150521093158.GZ13983@weber> Message-ID: There was the long forgotten generalised List Comprehensions. Is it still working in the last versions? -XTransformListComp 2015-05-21 13:55 GMT+02:00 Oliver Charles : > The https://hackage.haskell.org/package/tables library is one way to get > a somewhat relational view of in-memory data. > > - Ollie > > On Thu, May 21, 2015 at 10:31 AM, Tom Ellis < > tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > >> On Tue, May 19, 2015 at 11:35:31AM -0700, KC wrote: >> > I'm reading #OutOfTheTarPit does ghc have a relational model built in >> for >> > state? >> > >> > "Out of the Tar Pit" talks about FRP - Functional Relational Programming >> >> I guess you're looking for an "in memory" relational implementation. >> Opaleye and Relational Record, that Ben Ford mentioned, are for building >> queries for external SQL databases. >> >> For some time now I've been thinking about implementing such an "in >> memory" >> database with the same API as Opaleye, and I know Edward Kmett has thought >> about efficient ways to implement such a thing using the techniques of >> "discrimination" that he is fond of. I for one don't have anything to >> show >> yet, but I will certainly announce it here if and when I do. >> >> Tom >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -- Alberto. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ollie at ocharles.org.uk Thu May 21 14:02:48 2015 From: ollie at ocharles.org.uk (Oliver Charles) Date: Thu, 21 May 2015 15:02:48 +0100 Subject: [Haskell-cafe] I'm reading #OutOfTheTarPit does ghc have a relational model built in for state? In-Reply-To: References: <20150521093158.GZ13983@weber> Message-ID: It still works and I use it, but when you start using grouping you have to rely on partial functions (`the`, which is basically `head`), which makes me a little uncomfortable. On Thu, May 21, 2015 at 2:52 PM, Alberto G. Corona wrote: > There was the long forgotten generalised List Comprehensions. Is it still > working in the last versions? > > -XTransformListComp > > > 2015-05-21 13:55 GMT+02:00 Oliver Charles : > >> The https://hackage.haskell.org/package/tables library is one way to get >> a somewhat relational view of in-memory data. >> >> - Ollie >> >> On Thu, May 21, 2015 at 10:31 AM, Tom Ellis < >> tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: >> >>> On Tue, May 19, 2015 at 11:35:31AM -0700, KC wrote: >>> > I'm reading #OutOfTheTarPit does ghc have a relational model built in >>> for >>> > state? >>> > >>> > "Out of the Tar Pit" talks about FRP - Functional Relational >>> Programming >>> >>> I guess you're looking for an "in memory" relational implementation. >>> Opaleye and Relational Record, that Ben Ford mentioned, are for building >>> queries for external SQL databases. >>> >>> For some time now I've been thinking about implementing such an "in >>> memory" >>> database with the same API as Opaleye, and I know Edward Kmett has >>> thought >>> about efficient ways to implement such a thing using the techniques of >>> "discrimination" that he is fond of. I for one don't have anything to >>> show >>> yet, but I will certainly announce it here if and when I do. >>> >>> Tom >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > > -- > Alberto. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu May 21 14:56:50 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 21 May 2015 16:56:50 +0200 Subject: [Haskell-cafe] 23% of calls to map fuse away Message-ID: <1432220210.20141.6.camel@joachim-breitner.de> Hi, I just compiled all? of Stackage LTS 2.9 with GHC 7.8.4 with -ddump-rule-firings, and counted the occurrences of the rules. Here is a fun fact: 23% of all (static) occurrences of "map" fuse away?. And 50387 lists are fused away in total? Full data at https://gist.github.com/nomeata/071c1f87450cf668bbeb Greetings, Joachim ? but the SDL2 bindings ? 16925 ? rule map 12904 ? rule mapList, which fires if no fusion happened. ? 27846 ? rule fold/build 11293 ? rule foldr/single 11248 ? rule augment/build -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From felipe.lessa at gmail.com Thu May 21 18:57:59 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 21 May 2015 15:57:59 -0300 Subject: [Haskell-cafe] 23% of calls to map fuse away In-Reply-To: <1432220210.20141.6.camel@joachim-breitner.de> References: <1432220210.20141.6.camel@joachim-breitner.de> Message-ID: <555E2AB7.6020402@gmail.com> Very interesting. I imagine most of those were not crafted to be fused. Out of curiosity, why 7.8 instead of 7.10 or HEAD? Cheers, :) -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From matthewtpickering at gmail.com Thu May 21 19:15:34 2015 From: matthewtpickering at gmail.com (Matthew Pickering) Date: Thu, 21 May 2015 20:15:34 +0100 Subject: [Haskell-cafe] 23% of calls to map fuse away In-Reply-To: <555E2AB7.6020402@gmail.com> References: <1432220210.20141.6.camel@joachim-breitner.de> <555E2AB7.6020402@gmail.com> Message-ID: Speculating, LTS Haskell 2.9 is designed to build with GHC 7.8.4 but no such guarantees are made for GHC 7.10/HEAD. On Thu, May 21, 2015 at 7:57 PM, Felipe Lessa wrote: > Very interesting. I imagine most of those were not crafted to be fused. > > Out of curiosity, why 7.8 instead of 7.10 or HEAD? > > Cheers, :) > > -- > Felipe. > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From alan.zimm at gmail.com Thu May 21 19:24:04 2015 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Thu, 21 May 2015 21:24:04 +0200 Subject: [Haskell-cafe] 23% of calls to map fuse away In-Reply-To: References: <1432220210.20141.6.camel@joachim-breitner.de> <555E2AB7.6020402@gmail.com> Message-ID: The stackage nightlies recently switching to building with 7.10.1 https://www.stackage.org/nightly Alan On Thu, May 21, 2015 at 9:15 PM, Matthew Pickering < matthewtpickering at gmail.com> wrote: > Speculating, LTS Haskell 2.9 is designed to build with GHC 7.8.4 but > no such guarantees are made for GHC 7.10/HEAD. > > On Thu, May 21, 2015 at 7:57 PM, Felipe Lessa > wrote: > > Very interesting. I imagine most of those were not crafted to be fused. > > > > Out of curiosity, why 7.8 instead of 7.10 or HEAD? > > > > Cheers, :) > > > > -- > > Felipe. > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mail at joachim-breitner.de Thu May 21 20:13:38 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 21 May 2015 22:13:38 +0200 Subject: [Haskell-cafe] 23% of calls to map fuse away In-Reply-To: References: <1432220210.20141.6.camel@joachim-breitner.de> <555E2AB7.6020402@gmail.com> Message-ID: <1432239218.22612.1.camel@joachim-breitner.de> Hi, Am Donnerstag, den 21.05.2015, 20:15 +0100 schrieb Matthew Pickering: > Speculating, LTS Haskell 2.9 is designed to build with GHC 7.8.4 but > no such guarantees are made for GHC 7.10/HEAD. correct speculation. Although I only noticed midway that I actually need GHC 7.10 to get the numbers I care about (namely map/coerce), which wasn?t in GHC 7.8 to start with. But it was a good exercise. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From mail at joachim-breitner.de Thu May 21 20:14:35 2015 From: mail at joachim-breitner.de (Joachim Breitner) Date: Thu, 21 May 2015 22:14:35 +0200 Subject: [Haskell-cafe] 23% of calls to map fuse away In-Reply-To: References: <1432220210.20141.6.camel@joachim-breitner.de> <555E2AB7.6020402@gmail.com> Message-ID: <1432239275.22612.2.camel@joachim-breitner.de> Hi, Am Donnerstag, den 21.05.2015, 21:24 +0200 schrieb Alan & Kim Zimmerman: > The stackage nightlies recently switching to building with 7.10.1 > > https://www.stackage.org/nightly so I thought, but I looked at https://www.stackage.org/, which still says ?The above releases require GHC 7.8.?, confusing me and making me use the LTS release. I?ll re-run this with a nightly and GHC-7.10 soon. Greetings, Joachim -- Joachim ?nomeata? Breitner mail at joachim-breitner.de ? http://www.joachim-breitner.de/ Jabber: nomeata at joachim-breitner.de ? GPG-Key: 0xF0FBF51F Debian Developer: nomeata at debian.org -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: This is a digitally signed message part URL: From apauley at gmail.com Thu May 21 21:08:01 2015 From: apauley at gmail.com (Andreas Pauley) Date: Thu, 21 May 2015 23:08:01 +0200 Subject: [Haskell-cafe] Increasing parallelism in a frequency counter Message-ID: Hi everyone, I've started playing with some parallel programming in Haskell, mostly by applying the first few examples from Simon Marlow's book to my own toy problem: https://github.com/apauley/parallel-frequency I'm quite pleased with the speedup I have so far, the fastest parallel implementation is just over twice as fast as its sequential counterpart. But looking at the threadscope images from the generated event logs I can see that there are still significant portions of my program that runs on only one core. Is anyone interested to see if we can increase the parallelism in this frequency counter? Kind regards, Andreas -- https://keybase.io/apauley http://za.linkedin.com/in/apauley http://www.meetup.com/lambda-luminaries http://www.meetup.com/Bitcoins-Baby-Bitcoins GPG Public Key: https://keybase.io/apauley/key.asc From semen at trygub.com Thu May 21 23:49:52 2015 From: semen at trygub.com (Semen Trygubenko / =?utf-8?B?0KHQtdC80LXQvSDQotGA0LjQs9GD0LHQtdC9?= =?utf-8?B?0LrQvg==?=) Date: Fri, 22 May 2015 00:49:52 +0100 Subject: [Haskell-cafe] Haskell Weekly News: Issue 330 In-Reply-To: <20150507232926.GA3288@inanna.trygub.com> References: <20150326222444.GA91822@inanna.trygub.com> <20150409225936.GA1070@inanna.trygub.com> <20150423225841.GA8001@inanna.trygub.com> <20150507232926.GA3288@inanna.trygub.com> Message-ID: <20150521234952.GA57183@inanna.trygub.com> New Releases inline-c Francesco Mazzoli and Mathieu Boespflug release a library that allows to freely mix Haskell and C in the same source file and pass data from one language to the other with minimal overhead. http://hackage.haskell.org/package/inline-c https://github.com/fpco/inline-c/ https://www.fpcomplete.com/blog/2015/05/inline-c Books The Little Prover by Daniel P. Friedman and Carl Eastlund This book will come out in July 2015 and teaches how to use inductive proofs to determine facts about computer programs. http://mitpress.mit.edu/books/little-prover Haskell Programming by Christopher Allen and Julie Moronuki Half of the book is written and is available for early access. http://haskellbook.com/ https://gumroad.com/l/haskellbook?getthebook=Get+Haskell+Programming+now+from+Gumroad https://news.ycombinator.com/item?id=9580746 http://haskellbook.com/images/sample_pdf_v1.pdf Talks Workshop on Type Inference and Automated Proving Videos and slides are now available. http://staff.computing.dundee.ac.uk/frantisekfarka/tiap/ Discussion Against the definition of types Tomas Petricek argues that definition of what is a type does not exist and we should look for innovative ways of working with types without formal definition. http://tomasp.net/blog/2015/against-types/ http://www.reddit.com/r/haskell/comments/35zzvu/against_the_definition_of_types_by_tomas_petricek/ Effects encoded in types break encapsulation Yuras Shumovich notes that being too fine-grained in specification of side effects is in some ways equivalent to leaking implementation detail. http://blog.haskell-exists.com/yuras/posts/effects-encoded-in-types-break-encapsulation.html http://www.reddit.com/r/haskell/comments/36agmf/effects_encoded_in_types_break_encapsulation/ Quotes of the Week klaxion> "? My impression is that haskellers tend to be seen as head-in-the-clouds-impractical, purists to the point of fanaticism, and annoyingly prone to proselytizing. I'd like to change that and honestly I haven't met anyone who fits that (then again, I've yet to meet another haskeller IRL). Maybe this is a holdover from the earlier days when Haskell was a very marginalized community." kqr> "I wouldn't be too hopeful. Despite the fact that I'm one of the most practical, pragmatic members of one little social group I belong to (and this is clearly obvious quite often when others get into arguments over insignificant things) I'm still seen as a puristic, impractical hipster because I like Haskell. :( They don't seem to understand that a desire for good type systems and immutability come from a practical perspective. They equate things like Node.js with productivity and practicality. It's hard to change that image as long as that is the case." http://www.reddit.com/r/haskell/comments/36j3au/how_haskellers_are_seen_and_see_themselves/ "Everyone knows that the awesome Iron Man suit is actually dependent types." (psygnisfive) http://www.reddit.com/r/haskell/comments/36j3au/how_haskellers_are_seen_and_see_themselves/cremooe "The haskell applicative, alternative, monoidal and monadic combinators when applied to a monad that manage asynchronous IO permits multithreaded programming with little plumbing that is close to the specification level with great composability. No inversion of control means no need to deconstruct the specifications and no state machines. This, together with the uniform and composable thread management, narrow the design space and makes the application more understandable from the requirements, and thus the technical documentation and maintenance costs are reduced to a minimum." (Alberto G?mez Corona) "OOP is like creating custom hardware everytime for every problem. since there is no composability, everything must be done from scratch. there are no reusable objects beyond basic containers encapsulated in objects." (Alberto G?mez Corona) https://www.fpcomplete.com/user/agocorona/EDSL-for-hard-working-IT-programmers#the-oop-non-solution-half-solution http://haskell.1045720.n5.nabble.com/NoOO-languages-td5809663.html "if it's abstract (say, map) then x is as informative as element: a thing you know nothing further about" (cameleon) http://www.reddit.com/r/haskell/comments/36j3au/how_haskellers_are_seen_and_see_themselves/crf47tg "Add `terror`, a Text version of `error`" (Jonathan Lange) https://github.com/jml/basic-prelude/commit/11e936d6484ddbe9d403d40aa2bfbd3594b3a2b1 "If you take away my laziness, your language better bloody well be total and have a good accounting of codata." (kamatsu) http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgm71x "Turing completeness is entirely compatible with totality. It is only bullshit completeness that totality excludes." (pigworker) http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgqbah "The best way to encapsulate effects is not to restrict them." (Yuras Shumovich) http://blog.haskell-exists.com/yuras/posts/effects-encoded-in-types-break-encapsulation.html "I wouldn't use Haskell if I felt bad about laziness. It'd be like eating an apple pie while complaining that it contains apples..." (hagda) http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgmcbl "Lazy evaluation gives the compiler more leverage in the optimiser than in a strict language. There are more equalities that apply (e.g. beta reduction, and let x = E in y ==> y, if y /= x) and therefore the compiler can do more code transformations." (simonmar) http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgntwq "Seeing arguments from both sides, it's obvious to me that laziness-by-default is not better or worse than strictness-by-default; it's just a matter of taste and thinking habits. You can't please everyone: some people like looking at code more equationally and mathy, while some like it more down-to-earthy and predictable. ? The bottom line, however, is that, as SPJ said, laziness was good for Haskell because it helped them keep it pure." (SkoomaMudcrab) http://www.reddit.com/r/haskell/comments/36s0ii/how_do_we_all_feel_about_laziness/crgn2q5 -------------- next part -------------- A non-text attachment was scrubbed... Name: not available Type: application/pgp-signature Size: 181 bytes Desc: not available URL: From briand at aracnet.com Fri May 22 05:13:59 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Thu, 21 May 2015 22:13:59 -0700 Subject: [Haskell-cafe] open gl type conversions Message-ID: <20150521221359.11509566@cedar.deldotd.com> Following code GLFW.setWindowSizeCallback w (Just (\window w h -> do GL.viewport $= (GL.Position 0 0, GL.Size w h) emo1.hs:42:50: Couldn't match type ?Int? with ?Foreign.C.Types.CInt? Expected type: GLsizei Actual type: Int In the first argument of ?Size?, namely ?w? In the expression: Size w h I can never seem to figure out if i really need to do a type conversion, or just the make the appropriate type declarations. Sometimes it seems to be a combination of both. Part of the complication here is that w and h are, in fact, `Int` because that's there type in the type signature of WindowSizeCallback (Window -> Int -> Int -> IO () ). GL.Size really needs a CInt so it seems like I have to do some sort of explicit conversion, but I can never seem to figure out exactly how to find the necessary function. Humorously i tried putting Int->CInt in hoogle, and the only thing that looked like it might be useful was unsafeCoerce, but I'm pretty sure that's not the right answer. I was wondering if someone could enlighten me on exactly how you can trace out the solution to this sort of problem because it seeems to come up often (see, for example my confusion over FFTW r). Brian From svenpanne at gmail.com Fri May 22 06:56:59 2015 From: svenpanne at gmail.com (Sven Panne) Date: Fri, 22 May 2015 08:56:59 +0200 Subject: [Haskell-cafe] open gl type conversions In-Reply-To: <20150521221359.11509566@cedar.deldotd.com> References: <20150521221359.11509566@cedar.deldotd.com> Message-ID: 2015-05-22 7:13 GMT+02:00 : > [...] GL.Size really needs a CInt so it seems like I have to do some sort of explicit conversion, but I can never seem to figure out exactly how to find the necessary function. To be exact, Size expects 2 GLsizei arguments, and GLsizei is a type synonym for CInt , but what this latter type actually is shouldn't matter most of the time. The only thing you need to know here is that it's an integral number, and your swiss army knife for conversion between integral numerical types is: fromIntegral :: (Integral a, Num b) => a -> b Don't be scared by its canonical definition (fromInteger . toInteger), GHC has enough RULES to make this very efficient most of the time or even a no-op. Cheers, S. -------------- next part -------------- An HTML attachment was scrubbed... URL: From info at lars-petersen.net Fri May 22 11:55:41 2015 From: info at lars-petersen.net (Lars Petersen) Date: Fri, 22 May 2015 13:55:41 +0200 Subject: [Haskell-cafe] Threads and critical sections (threadWaitRead) Message-ID: <555F193D.1010809@lars-petersen.net> Hello cafe, I'm currently trying to understand Haskell's threading model and GHC's implementation of it. Specifically I wondered about the safety of file IO. Consider this piece of code: > newtype Socket = Socket (MVar Fd) > > read :: Socket -> IO ByteString > read (Socket mfd) = do > fd <- readMVar mfd > -- (1) > threadWaitRead fd > -- (2) > withMVar mfd $ \fd'-> do > -- (3) the actual read... Context: - The socket is configured non-blocking. - No other operation will hold the MVar over a blocking call (because this would make it impossible to close it while it's blocking). - My close operation will fill the MVar with -1 after it's closed and will hold the MVar during the close operation. Questions: - Is it theoretically possible that my thread gets paused at (1) or within threadWaitRead, another thread closes the socket (or even worse opens another file with the same fd) _and_ my thread is resumed afterwards (I'm not asking about async exceptions)? - What constructs contain safepoints and which are guaranteed to be executed without interruption? Considerations (so far): - It is unlikely that (1) is a safepoint as no memory allocations occur, but is it guaranteed? - If the socket were closed during (1), threadWaitRead throws an exception complaining about a bad file descriptor which is unexpected but not harmful. - I found this thread (https://mail.haskell.org/pipermail/haskell-cafe/2014-September/115841.html) which is somewhat related, but I couldn't extract a clear answer from it. Best, Lars From r.wobben at home.nl Fri May 22 12:06:07 2015 From: r.wobben at home.nl (Roelof Wobben) Date: Fri, 22 May 2015 14:06:07 +0200 Subject: [Haskell-cafe] cabal problem with Digits Message-ID: <555F1BAF.7020404@home.nl> Hello, When I want to install digits I see this output: cabal install digits Resolving dependencies.. [1 of 1] Compiling Main ( /tmp/digits-0.2-415/digits-0.2/Setup.lhs, /tmp/digits-0.2-415/digits-0.2/dist/setup/Main.o ) /tmp/digits-0.2-415/digits-0.2/Setup.lhs:3:3: Warning: Module ?System.Cmd? is deprecated: Use "System.Process" instead /tmp/digits-0.2-415/digits-0.2/Setup.lhs:5:49: Warning: In the use of ?runTests? (imported from Distribution.Simple, but defined in Distribution.Simple.UserHooks): Deprecated: "Please use the new testing interface instead!" Linking /tmp/digits-0.2-415/digits-0.2/dist/setup/setup ... Warning: digits.cabal: A package using 'cabal-version: >=1.2' must use section syntax. See the Cabal user guide for details. Configuring digits-0.2... Building digits-0.2... Preprocessing library digits-0.2... [1 of 1] Compiling Data.Digits ( src/Data/Digits.hs, dist/build/Data/Digits.o ) ****/usr/bin/ld: cannot find -lHSQuickCheck-2.8.1-ghc7.8.3 /usr/bin/ld: cannot find -lHStf-random-0.5-ghc7.8.3 /usr/bin/ld: cannot find -lHSprimitive-0.6-ghc7.8.3 /usr/bin/ld: cannot find -lHSrandom-1.1-ghc7.8.3**** How to soilve this one ? Roelof --- Dit e-mailbericht is gecontroleerd op virussen met Avast antivirussoftware. http://www.avast.com From toby at paccrat.org Fri May 22 14:06:42 2015 From: toby at paccrat.org (Toby Goodwin) Date: 22 May 2015 14:06:42 -0000 Subject: [Haskell-cafe] cabal problem with Digits In-Reply-To: <555F1BAF.7020404@home.nl> References: <555F1BAF.7020404@home.nl> Message-ID: <1432303602.763.lithium.flare.email@hydrogen.mpv6.com> >When I want to install digits I see this output: >... >/usr/bin/ld: cannot find -lHSQuickCheck-2.8.1-ghc7.8.3 >/usr/bin/ld: cannot find -lHStf-random-0.5-ghc7.8.3 Looks like a mismatch between cabal and ghc. I wrote about this on my blog recently: http://tobold.org/entry/2015-04-24 Note the section called "Bootstrap cabal". Cheers, Toby. From mblazevic at stilo.com Fri May 22 14:29:31 2015 From: mblazevic at stilo.com (=?UTF-8?B?TWFyaW8gQmxhxb5ldmnEhw==?=) Date: Fri, 22 May 2015 10:29:31 -0400 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: Message-ID: <555F3D4B.5030804@stilo.com> On 15-05-18 06:44 PM, Andrew Gibiansky wrote: > Hey all, > > In the earlier haskell-cafe discussion of IsString, someone mentioned > that it would be nice to abandon [Char] as the blessed string type in > Haskell. I've thought about this on and off for a while now, and think > that the fact that [Char] is the default string type is a really big > issue (for example, it gives beginners the idea that Haskell is > incredibly slow, because everything that involves string processing is > using linked lists). > > I am not proposing anything, but am curious as to what already has been > discussed: > > 1. Has the possibility of migrating away from [Char] been investigated > before? No, not seriously as far as I'm aware. That ship has sailed a long time ago. Still, as I have actually thought about that, I'll give you an outline of a possible process. > 2. What gains could we see in ease of use, performance, etc, if [Char] > was deprecated? They could be very significant for any code that took advantage of the new type, but the existing code would not benefit that much. But then, any new Haskell code can already use Text where performance matters. > 3. What could replace [Char], while retaining the same ease of use for > writing string manipulation functions (pattern matching, etc)? You would not have the same ease of use exactly. The options would lie between two extremes. At one end, you can have a completely opaque String type with fromChars/toChars operations and nothing else. At the other end, you'd implement all operations useful on strings so there would never be any need to convert between String and [Char]. The first extreme would be mostly useless from the performance point of view, but with some GHC magic perhaps it could be made a viable upgrade path. The compiler would have to automatically insert the implicit fromChars/toChars conversion whenever necessary, and I expect that some of the existing Haskell code would still be broken. Once you have an opaque String type, you can think about improving the performance. A more efficient instance of Monoid String would be a good start, especially since it wouldn't break backward compatibility. Unfortunately that is the only [Char] instance in wide use that can be easily optimized. Perhaps Foldable could be made to work with even more compiler magic, but I doubt it would be worth the effort. If you add more operations on String that don't require > 4. Is there any sort of migration path that would make this change > feasible in mainline Haskell in the medium term (2-5 years)? Suppose GHC 7.12 were to bring Text into the core libraries, change Prelude to declare type String = Text, and sprinkle some magic compiler dust to make the explicit Text <-> Char conversions unnecessary. The existing Haskell code would almost certainly perform worse overall. The only improved operations would be mappend on String, and possibly the string literal instantiation. I don't think there's any chance to get this kind of change proposal accepted today. You'd have to make the pain worth the gain. The only viable path is to ensure beforehand that the change improves more than just the mappend operation. In other words, you'd have to get today's String to instantiate more classes in common with tomorrow's String, and you'd have to get the everyday Haskell code to use those classes instead of list manipulations. The first tentative step towards the String type change would then be either the mono-traversable or my own monoid-subclasses package. They both define new type classes that are instantiated by both [Char] and Text. The main difference is that the former builds upon the Foldable foundation, the latter upon Monoid. They are both far from being a complete replacement for list manipulations. But any new code that used their operations would see a big improvement from the String type change. Here, then, is the five-year plan you're asking for: Year one: Agree on the ideal set of type classes to bridge the gap between [Char] and Text. Year two: Bring the new type classes into the Prelude. Have all relevant types instantiate them. Everybody's updating their code in delight to use the new class methods. Year three: GHC issues warnings about using List-specific [], ++, null, take, drop, span, drop, etc, on String. Everybody's furiously updating their code. Year four: Add Text to the core libraries. The GHC magic to make the Text <-> [Char] convertions implicit is implemented and ready for testing but requires a pragma. Year five: Update Haskell language report. Flip the switch. So there. How feasible does that sound? From anakreonmejdi at gmail.com Fri May 22 15:06:31 2015 From: anakreonmejdi at gmail.com (Anakreontas) Date: Fri, 22 May 2015 08:06:31 -0700 (PDT) Subject: [Haskell-cafe] Installing ghc-mod on Windows Message-ID: <1cd18995-9e54-4e76-9a72-e08a32b2f560@googlegroups.com> I tried to instal ghc-mod on Windows with cabal. Two dependencies fail to compile because of missing native libraries. ansi-terminal requires kernel32 and lifted-base requires inlinable.h. Have you solved a similar problem? In Linux it would be easy to install the native libraries but in Windows I do not know which programs I should install and where to find them. -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Fri May 22 16:07:47 2015 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Fri, 22 May 2015 12:07:47 -0400 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: <555F3D4B.5030804@stilo.com> References: <555F3D4B.5030804@stilo.com> Message-ID: Mario, thanks for that great writeup. The switch can only happen if there's a way to make the old code somehow transparently work the same or better in the new setup. Maybe some GHC magic could bring the string operations to Prim Ops and transparently switch the underlying representation to Text from [Char]. Basically, Text would have to become a built in primitive, not a library. Micha? On Fri, May 22, 2015 at 10:29 AM, Mario Bla?evi? wrote: > On 15-05-18 06:44 PM, Andrew Gibiansky wrote: > >> Hey all, >> >> In the earlier haskell-cafe discussion of IsString, someone mentioned >> that it would be nice to abandon [Char] as the blessed string type in >> Haskell. I've thought about this on and off for a while now, and think >> that the fact that [Char] is the default string type is a really big >> issue (for example, it gives beginners the idea that Haskell is >> incredibly slow, because everything that involves string processing is >> using linked lists). >> >> I am not proposing anything, but am curious as to what already has been >> discussed: >> >> 1. Has the possibility of migrating away from [Char] been investigated >> before? >> > > No, not seriously as far as I'm aware. That ship has sailed a long > time ago. Still, as I have actually thought about that, I'll give you an > outline of a possible process. > > > 2. What gains could we see in ease of use, performance, etc, if [Char] >> was deprecated? >> > > They could be very significant for any code that took advantage of > the new type, but the existing code would not benefit that much. But then, > any new Haskell code can already use Text where performance matters. > > > 3. What could replace [Char], while retaining the same ease of use for >> writing string manipulation functions (pattern matching, etc)? >> > > You would not have the same ease of use exactly. The options would > lie between two extremes. At one end, you can have a completely opaque > String type with fromChars/toChars operations and nothing else. At the > other end, you'd implement all operations useful on strings so there would > never be any need to convert between String and [Char]. > > The first extreme would be mostly useless from the performance > point of view, but with some GHC magic perhaps it could be made a viable > upgrade path. The compiler would have to automatically insert the implicit > fromChars/toChars conversion whenever necessary, and I expect that some of > the existing Haskell code would still be broken. > > Once you have an opaque String type, you can think about improving > the performance. A more efficient instance of Monoid String would be a good > start, especially since it wouldn't break backward compatibility. > Unfortunately that is the only [Char] instance in wide use that can be > easily optimized. Perhaps Foldable could be made to work with even more > compiler magic, but I doubt it would be worth the effort. > > If you add more operations on String that don't require > > > 4. Is there any sort of migration path that would make this change >> feasible in mainline Haskell in the medium term (2-5 years)? >> > > Suppose GHC 7.12 were to bring Text into the core libraries, > change Prelude to declare type String = Text, and sprinkle some magic > compiler dust to make the explicit Text <-> Char conversions unnecessary. > > The existing Haskell code would almost certainly perform worse > overall. The only improved operations would be mappend on String, and > possibly the string literal instantiation. > > I don't think there's any chance to get this kind of change > proposal accepted today. You'd have to make the pain worth the gain. > The only viable path is to ensure beforehand that the change improves more > than just the mappend operation. > > In other words, you'd have to get today's String to instantiate > more classes in common with tomorrow's String, and you'd have to get the > everyday Haskell code to use those classes instead of list manipulations. > > The first tentative step towards the String type change would then > be either the mono-traversable or my own monoid-subclasses package. They > both define new type classes that are instantiated by both [Char] and Text. > The main difference is that the former builds upon the Foldable foundation, > the latter upon Monoid. They are both far from being a complete replacement > for list manipulations. But any new code that used their operations would > see a big improvement from the String type change. > > Here, then, is the five-year plan you're asking for: > > Year one: Agree on the ideal set of type classes to bridge the gap between > [Char] and Text. > > Year two: Bring the new type classes into the Prelude. Have all relevant > types instantiate them. Everybody's updating their code in delight to use > the new class methods. > > Year three: GHC issues warnings about using List-specific [], ++, null, > take, drop, span, drop, etc, on String. Everybody's furiously updating > their code. > > Year four: Add Text to the core libraries. The GHC magic to make the Text > <-> [Char] convertions implicit is implemented and ready for testing but > requires a pragma. > > Year five: Update Haskell language report. Flip the switch. > > So there. How feasible does that sound? > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From roma at ro-che.info Fri May 22 16:09:11 2015 From: roma at ro-che.info (Roman Cheplyaka) Date: Fri, 22 May 2015 19:09:11 +0300 Subject: [Haskell-cafe] Installing ghc-mod on Windows In-Reply-To: <1cd18995-9e54-4e76-9a72-e08a32b2f560@googlegroups.com> References: <1cd18995-9e54-4e76-9a72-e08a32b2f560@googlegroups.com> Message-ID: <555F54A7.7090103@ro-che.info> On 22/05/15 18:06, Anakreontas wrote: > I tried to instal ghc-mod on Windows with cabal. Two dependencies fail > to compile because of missing native libraries. > ansi-terminal requires kernel32 and > lifted-base requires inlinable.h. > > Have you solved a similar problem? In Linux it would be easy to install > the native libraries but in Windows I do not know which programs I > should install and where to find them. You should be able to install ansi-terminal by patching its cabal file, see https://github.com/feuerbach/ansi-terminal/issues/6 Once again, I'm asking Windows users and developers for their input on this issue. Roman -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From mantkiew at gsd.uwaterloo.ca Fri May 22 17:30:50 2015 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Fri, 22 May 2015 13:30:50 -0400 Subject: [Haskell-cafe] Installing ghc-mod on Windows In-Reply-To: <555F54A7.7090103@ro-che.info> References: <1cd18995-9e54-4e76-9a72-e08a32b2f560@googlegroups.com> <555F54A7.7090103@ro-che.info> Message-ID: Hi, are you using msys and MinGHC? For now, I clone ghc-mod @ master and just cabal install it (with MinGHC 0.7.10 and cabal 1.22) within msys. It has not been released yet. Micha? On Fri, May 22, 2015 at 12:09 PM, Roman Cheplyaka wrote: > On 22/05/15 18:06, Anakreontas wrote: > > I tried to instal ghc-mod on Windows with cabal. Two dependencies fail > > to compile because of missing native libraries. > > ansi-terminal requires kernel32 and > > lifted-base requires inlinable.h. > > > > Have you solved a similar problem? In Linux it would be easy to install > > the native libraries but in Windows I do not know which programs I > > should install and where to find them. > > You should be able to install ansi-terminal by patching its cabal file, > see https://github.com/feuerbach/ansi-terminal/issues/6 > > Once again, I'm asking Windows users and developers for their input on > this issue. > > Roman > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Fri May 22 17:37:52 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Fri, 22 May 2015 19:37:52 +0200 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: <555F3D4B.5030804@stilo.com> Message-ID: Mario, Thank you for that detailed write-up. That's exactly the sort of thing I was looking for. I imagine a path like the one you describe is possible, but very, very difficult, and likely the effort could be better spent elsewhere. I imagine an alternate route (that would have immediate gains in the near future, and wouldn't be a long-term transition plan) would be to have a `text-base` package, which exports everything `base` does, exporting `Text` instead of `String`. Then base packages off that instead of `base`, thus ensuring you do not rely on []-manipulation for `String` (you should still have full compatibility with normal `base`). Anyway, hard choices all around, for no 100% clear gain, so I personally do not envision this happening any time soon. Oh well... -- Andrew On Fri, May 22, 2015 at 6:07 PM, Michal Antkiewicz < mantkiew at gsd.uwaterloo.ca> wrote: > Mario, thanks for that great writeup. > > The switch can only happen if there's a way to make the old code somehow > transparently work the same or better in the new setup. > > Maybe some GHC magic could bring the string operations to Prim Ops and > transparently switch the underlying representation to Text from [Char]. > Basically, Text would have to become a built in primitive, not a library. > > Micha? > > On Fri, May 22, 2015 at 10:29 AM, Mario Bla?evi? > wrote: > >> On 15-05-18 06:44 PM, Andrew Gibiansky wrote: >> >>> Hey all, >>> >>> In the earlier haskell-cafe discussion of IsString, someone mentioned >>> that it would be nice to abandon [Char] as the blessed string type in >>> Haskell. I've thought about this on and off for a while now, and think >>> that the fact that [Char] is the default string type is a really big >>> issue (for example, it gives beginners the idea that Haskell is >>> incredibly slow, because everything that involves string processing is >>> using linked lists). >>> >>> I am not proposing anything, but am curious as to what already has been >>> discussed: >>> >>> 1. Has the possibility of migrating away from [Char] been investigated >>> before? >>> >> >> No, not seriously as far as I'm aware. That ship has sailed a >> long time ago. Still, as I have actually thought about that, I'll give you >> an outline of a possible process. >> >> >> 2. What gains could we see in ease of use, performance, etc, if [Char] >>> was deprecated? >>> >> >> They could be very significant for any code that took advantage >> of the new type, but the existing code would not benefit that much. But >> then, any new Haskell code can already use Text where performance matters. >> >> >> 3. What could replace [Char], while retaining the same ease of use for >>> writing string manipulation functions (pattern matching, etc)? >>> >> >> You would not have the same ease of use exactly. The options >> would lie between two extremes. At one end, you can have a completely >> opaque String type with fromChars/toChars operations and nothing else. At >> the other end, you'd implement all operations useful on strings so there >> would never be any need to convert between String and [Char]. >> >> The first extreme would be mostly useless from the performance >> point of view, but with some GHC magic perhaps it could be made a viable >> upgrade path. The compiler would have to automatically insert the implicit >> fromChars/toChars conversion whenever necessary, and I expect that some of >> the existing Haskell code would still be broken. >> >> Once you have an opaque String type, you can think about >> improving the performance. A more efficient instance of Monoid String would >> be a good start, especially since it wouldn't break backward compatibility. >> Unfortunately that is the only [Char] instance in wide use that can be >> easily optimized. Perhaps Foldable could be made to work with even more >> compiler magic, but I doubt it would be worth the effort. >> >> If you add more operations on String that don't require >> >> >> 4. Is there any sort of migration path that would make this change >>> feasible in mainline Haskell in the medium term (2-5 years)? >>> >> >> Suppose GHC 7.12 were to bring Text into the core libraries, >> change Prelude to declare type String = Text, and sprinkle some magic >> compiler dust to make the explicit Text <-> Char conversions unnecessary. >> >> The existing Haskell code would almost certainly perform worse >> overall. The only improved operations would be mappend on String, and >> possibly the string literal instantiation. >> >> I don't think there's any chance to get this kind of change >> proposal accepted today. You'd have to make the pain worth the gain. >> The only viable path is to ensure beforehand that the change improves >> more than just the mappend operation. >> >> In other words, you'd have to get today's String to instantiate >> more classes in common with tomorrow's String, and you'd have to get the >> everyday Haskell code to use those classes instead of list manipulations. >> >> The first tentative step towards the String type change would >> then be either the mono-traversable or my own monoid-subclasses package. >> They both define new type classes that are instantiated by both [Char] and >> Text. The main difference is that the former builds upon the Foldable >> foundation, the latter upon Monoid. They are both far from being a complete >> replacement for list manipulations. But any new code that used their >> operations would see a big improvement from the String type change. >> >> Here, then, is the five-year plan you're asking for: >> >> Year one: Agree on the ideal set of type classes to bridge the gap >> between [Char] and Text. >> >> Year two: Bring the new type classes into the Prelude. Have all relevant >> types instantiate them. Everybody's updating their code in delight to use >> the new class methods. >> >> Year three: GHC issues warnings about using List-specific [], ++, null, >> take, drop, span, drop, etc, on String. Everybody's furiously updating >> their code. >> >> Year four: Add Text to the core libraries. The GHC magic to make the Text >> <-> [Char] convertions implicit is implemented and ready for testing but >> requires a pragma. >> >> Year five: Update Haskell language report. Flip the switch. >> >> So there. How feasible does that sound? >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Fri May 22 17:55:14 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 22 May 2015 12:55:14 -0500 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: <555F3D4B.5030804@stilo.com> Message-ID: Having just finished converting my Haskell shell-scripting tool from Strjng to Text/ByteString, might I suggest that such a change would create fewer problems after a Prelude rework to something like ClassyPrelude? Using ClassyPrelude meant that a lot of the code that worked with String worked just fine with Text and ByteString. I had more fixes due to having used partial function than with no longer having List's of chars. On Fri, May 22, 2015 at 12:37 PM, Andrew Gibiansky < andrew.gibiansky at gmail.com> wrote: > Mario, > > Thank you for that detailed write-up. That's exactly the sort of thing I > was looking for. > > I imagine a path like the one you describe is possible, but very, very > difficult, and likely the effort could be better spent elsewhere. > > I imagine an alternate route (that would have immediate gains in the near > future, and wouldn't be a long-term transition plan) would be to have a > `text-base` package, which exports everything `base` does, exporting `Text` > instead of `String`. Then base packages off that instead of `base`, thus > ensuring you do not rely on []-manipulation for `String` (you should still > have full compatibility with normal `base`). > > Anyway, hard choices all around, for no 100% clear gain, so I personally > do not envision this happening any time soon. Oh well... > > -- Andrew > > On Fri, May 22, 2015 at 6:07 PM, Michal Antkiewicz < > mantkiew at gsd.uwaterloo.ca> wrote: > >> Mario, thanks for that great writeup. >> >> The switch can only happen if there's a way to make the old code somehow >> transparently work the same or better in the new setup. >> >> Maybe some GHC magic could bring the string operations to Prim Ops and >> transparently switch the underlying representation to Text from [Char]. >> Basically, Text would have to become a built in primitive, not a library. >> >> Micha? >> >> On Fri, May 22, 2015 at 10:29 AM, Mario Bla?evi? >> wrote: >> >>> On 15-05-18 06:44 PM, Andrew Gibiansky wrote: >>> >>>> Hey all, >>>> >>>> In the earlier haskell-cafe discussion of IsString, someone mentioned >>>> that it would be nice to abandon [Char] as the blessed string type in >>>> Haskell. I've thought about this on and off for a while now, and think >>>> that the fact that [Char] is the default string type is a really big >>>> issue (for example, it gives beginners the idea that Haskell is >>>> incredibly slow, because everything that involves string processing is >>>> using linked lists). >>>> >>>> I am not proposing anything, but am curious as to what already has been >>>> discussed: >>>> >>>> 1. Has the possibility of migrating away from [Char] been investigated >>>> before? >>>> >>> >>> No, not seriously as far as I'm aware. That ship has sailed a >>> long time ago. Still, as I have actually thought about that, I'll give you >>> an outline of a possible process. >>> >>> >>> 2. What gains could we see in ease of use, performance, etc, if [Char] >>>> was deprecated? >>>> >>> >>> They could be very significant for any code that took advantage >>> of the new type, but the existing code would not benefit that much. But >>> then, any new Haskell code can already use Text where performance matters. >>> >>> >>> 3. What could replace [Char], while retaining the same ease of use for >>>> writing string manipulation functions (pattern matching, etc)? >>>> >>> >>> You would not have the same ease of use exactly. The options >>> would lie between two extremes. At one end, you can have a completely >>> opaque String type with fromChars/toChars operations and nothing else. At >>> the other end, you'd implement all operations useful on strings so there >>> would never be any need to convert between String and [Char]. >>> >>> The first extreme would be mostly useless from the performance >>> point of view, but with some GHC magic perhaps it could be made a viable >>> upgrade path. The compiler would have to automatically insert the implicit >>> fromChars/toChars conversion whenever necessary, and I expect that some of >>> the existing Haskell code would still be broken. >>> >>> Once you have an opaque String type, you can think about >>> improving the performance. A more efficient instance of Monoid String would >>> be a good start, especially since it wouldn't break backward compatibility. >>> Unfortunately that is the only [Char] instance in wide use that can be >>> easily optimized. Perhaps Foldable could be made to work with even more >>> compiler magic, but I doubt it would be worth the effort. >>> >>> If you add more operations on String that don't require >>> >>> >>> 4. Is there any sort of migration path that would make this change >>>> feasible in mainline Haskell in the medium term (2-5 years)? >>>> >>> >>> Suppose GHC 7.12 were to bring Text into the core libraries, >>> change Prelude to declare type String = Text, and sprinkle some magic >>> compiler dust to make the explicit Text <-> Char conversions unnecessary. >>> >>> The existing Haskell code would almost certainly perform worse >>> overall. The only improved operations would be mappend on String, and >>> possibly the string literal instantiation. >>> >>> I don't think there's any chance to get this kind of change >>> proposal accepted today. You'd have to make the pain worth the gain. >>> The only viable path is to ensure beforehand that the change improves >>> more than just the mappend operation. >>> >>> In other words, you'd have to get today's String to instantiate >>> more classes in common with tomorrow's String, and you'd have to get the >>> everyday Haskell code to use those classes instead of list manipulations. >>> >>> The first tentative step towards the String type change would >>> then be either the mono-traversable or my own monoid-subclasses package. >>> They both define new type classes that are instantiated by both [Char] and >>> Text. The main difference is that the former builds upon the Foldable >>> foundation, the latter upon Monoid. They are both far from being a complete >>> replacement for list manipulations. But any new code that used their >>> operations would see a big improvement from the String type change. >>> >>> Here, then, is the five-year plan you're asking for: >>> >>> Year one: Agree on the ideal set of type classes to bridge the gap >>> between [Char] and Text. >>> >>> Year two: Bring the new type classes into the Prelude. Have all relevant >>> types instantiate them. Everybody's updating their code in delight to use >>> the new class methods. >>> >>> Year three: GHC issues warnings about using List-specific [], ++, null, >>> take, drop, span, drop, etc, on String. Everybody's furiously updating >>> their code. >>> >>> Year four: Add Text to the core libraries. The GHC magic to make the >>> Text <-> [Char] convertions implicit is implemented and ready for testing >>> but requires a pragma. >>> >>> Year five: Update Haskell language report. Flip the switch. >>> >>> So there. How feasible does that sound? >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Fri May 22 21:57:39 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Fri, 22 May 2015 17:57:39 -0400 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: <555F3D4B.5030804@stilo.com> Message-ID: one direction that this thread has *COMPLETELY* overlooked is the following: could we use pattern synonyms or something along those lines to make the migration to Text or the like more seemless? On Fri, May 22, 2015 at 1:55 PM, Mike Meyer wrote: > Having just finished converting my Haskell shell-scripting tool from > Strjng to Text/ByteString, might I suggest that such a change would create > fewer problems after a Prelude rework to something like ClassyPrelude? > Using ClassyPrelude meant that a lot of the code that worked with String > worked just fine with Text and ByteString. I had more fixes due to having > used partial function than with no longer having List's of chars. > > On Fri, May 22, 2015 at 12:37 PM, Andrew Gibiansky < > andrew.gibiansky at gmail.com> wrote: > >> Mario, >> >> Thank you for that detailed write-up. That's exactly the sort of thing I >> was looking for. >> >> I imagine a path like the one you describe is possible, but very, very >> difficult, and likely the effort could be better spent elsewhere. >> >> I imagine an alternate route (that would have immediate gains in the near >> future, and wouldn't be a long-term transition plan) would be to have a >> `text-base` package, which exports everything `base` does, exporting `Text` >> instead of `String`. Then base packages off that instead of `base`, thus >> ensuring you do not rely on []-manipulation for `String` (you should still >> have full compatibility with normal `base`). >> >> Anyway, hard choices all around, for no 100% clear gain, so I personally >> do not envision this happening any time soon. Oh well... >> >> -- Andrew >> >> On Fri, May 22, 2015 at 6:07 PM, Michal Antkiewicz < >> mantkiew at gsd.uwaterloo.ca> wrote: >> >>> Mario, thanks for that great writeup. >>> >>> The switch can only happen if there's a way to make the old code somehow >>> transparently work the same or better in the new setup. >>> >>> Maybe some GHC magic could bring the string operations to Prim Ops and >>> transparently switch the underlying representation to Text from [Char]. >>> Basically, Text would have to become a built in primitive, not a library. >>> >>> Micha? >>> >>> On Fri, May 22, 2015 at 10:29 AM, Mario Bla?evi? >>> wrote: >>> >>>> On 15-05-18 06:44 PM, Andrew Gibiansky wrote: >>>> >>>>> Hey all, >>>>> >>>>> In the earlier haskell-cafe discussion of IsString, someone mentioned >>>>> that it would be nice to abandon [Char] as the blessed string type in >>>>> Haskell. I've thought about this on and off for a while now, and think >>>>> that the fact that [Char] is the default string type is a really big >>>>> issue (for example, it gives beginners the idea that Haskell is >>>>> incredibly slow, because everything that involves string processing is >>>>> using linked lists). >>>>> >>>>> I am not proposing anything, but am curious as to what already has been >>>>> discussed: >>>>> >>>>> 1. Has the possibility of migrating away from [Char] been investigated >>>>> before? >>>>> >>>> >>>> No, not seriously as far as I'm aware. That ship has sailed a >>>> long time ago. Still, as I have actually thought about that, I'll give you >>>> an outline of a possible process. >>>> >>>> >>>> 2. What gains could we see in ease of use, performance, etc, if [Char] >>>>> was deprecated? >>>>> >>>> >>>> They could be very significant for any code that took advantage >>>> of the new type, but the existing code would not benefit that much. But >>>> then, any new Haskell code can already use Text where performance matters. >>>> >>>> >>>> 3. What could replace [Char], while retaining the same ease of use for >>>>> writing string manipulation functions (pattern matching, etc)? >>>>> >>>> >>>> You would not have the same ease of use exactly. The options >>>> would lie between two extremes. At one end, you can have a completely >>>> opaque String type with fromChars/toChars operations and nothing else. At >>>> the other end, you'd implement all operations useful on strings so there >>>> would never be any need to convert between String and [Char]. >>>> >>>> The first extreme would be mostly useless from the performance >>>> point of view, but with some GHC magic perhaps it could be made a viable >>>> upgrade path. The compiler would have to automatically insert the implicit >>>> fromChars/toChars conversion whenever necessary, and I expect that some of >>>> the existing Haskell code would still be broken. >>>> >>>> Once you have an opaque String type, you can think about >>>> improving the performance. A more efficient instance of Monoid String would >>>> be a good start, especially since it wouldn't break backward compatibility. >>>> Unfortunately that is the only [Char] instance in wide use that can be >>>> easily optimized. Perhaps Foldable could be made to work with even more >>>> compiler magic, but I doubt it would be worth the effort. >>>> >>>> If you add more operations on String that don't require >>>> >>>> >>>> 4. Is there any sort of migration path that would make this change >>>>> feasible in mainline Haskell in the medium term (2-5 years)? >>>>> >>>> >>>> Suppose GHC 7.12 were to bring Text into the core libraries, >>>> change Prelude to declare type String = Text, and sprinkle some magic >>>> compiler dust to make the explicit Text <-> Char conversions unnecessary. >>>> >>>> The existing Haskell code would almost certainly perform worse >>>> overall. The only improved operations would be mappend on String, and >>>> possibly the string literal instantiation. >>>> >>>> I don't think there's any chance to get this kind of change >>>> proposal accepted today. You'd have to make the pain worth the gain. >>>> The only viable path is to ensure beforehand that the change improves >>>> more than just the mappend operation. >>>> >>>> In other words, you'd have to get today's String to instantiate >>>> more classes in common with tomorrow's String, and you'd have to get the >>>> everyday Haskell code to use those classes instead of list manipulations. >>>> >>>> The first tentative step towards the String type change would >>>> then be either the mono-traversable or my own monoid-subclasses package. >>>> They both define new type classes that are instantiated by both [Char] and >>>> Text. The main difference is that the former builds upon the Foldable >>>> foundation, the latter upon Monoid. They are both far from being a complete >>>> replacement for list manipulations. But any new code that used their >>>> operations would see a big improvement from the String type change. >>>> >>>> Here, then, is the five-year plan you're asking for: >>>> >>>> Year one: Agree on the ideal set of type classes to bridge the gap >>>> between [Char] and Text. >>>> >>>> Year two: Bring the new type classes into the Prelude. Have all >>>> relevant types instantiate them. Everybody's updating their code in delight >>>> to use the new class methods. >>>> >>>> Year three: GHC issues warnings about using List-specific [], ++, null, >>>> take, drop, span, drop, etc, on String. Everybody's furiously updating >>>> their code. >>>> >>>> Year four: Add Text to the core libraries. The GHC magic to make the >>>> Text <-> [Char] convertions implicit is implemented and ready for testing >>>> but requires a pragma. >>>> >>>> Year five: Update Haskell language report. Flip the switch. >>>> >>>> So there. How feasible does that sound? >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From andrew.gibiansky at gmail.com Fri May 22 22:20:32 2015 From: andrew.gibiansky at gmail.com (Andrew Gibiansky) Date: Sat, 23 May 2015 00:20:32 +0200 Subject: [Haskell-cafe] Abandoning String = [Char]? In-Reply-To: References: <555F3D4B.5030804@stilo.com> Message-ID: Carter, that is a very good suggestion! I imagine that a combination of PatternSynonyms and OverloadedLists could be used to completely abstract the list notation. This would have to happen to *all* Haskell source code, though. Right now we have the following elements of list syntax: - Types, e.g. [Char] - Construction via literals, [1, 2, 3] - Construction via pattern matching, 1 : 2 : [] - Enumerations, [1..3], [1..], [1,3..] - Pattern matching, let (x:xs) = [1..] These are currently somewhat handled by - OverloadedLists: Construction via literals - Enum typeclass: Enumerations We could handle the others partially, by allowing PatternSynonyms to replace (:) somehow, both for construction and pattern matching. The [Char] usage does not need to be replaced. Then String could be changed to something else easily. Looking at it this way, it makes the proposal seem much more doable. These could be bundled into a single extension -XPackedString, or something like that. It would be interesting to formulate this into a full-fledged proposal, if only as an exploratory venture (I certainly do not have the time to follow through on this myself). -- Andrew On Fri, May 22, 2015 at 11:57 PM, Carter Schonwald < carter.schonwald at gmail.com> wrote: > one direction that this thread has *COMPLETELY* overlooked is the > following: > > could we use pattern synonyms or something along those lines to make the > migration to Text or the like more seemless? > > On Fri, May 22, 2015 at 1:55 PM, Mike Meyer wrote: > >> Having just finished converting my Haskell shell-scripting tool from >> Strjng to Text/ByteString, might I suggest that such a change would create >> fewer problems after a Prelude rework to something like ClassyPrelude? >> Using ClassyPrelude meant that a lot of the code that worked with String >> worked just fine with Text and ByteString. I had more fixes due to having >> used partial function than with no longer having List's of chars. >> >> On Fri, May 22, 2015 at 12:37 PM, Andrew Gibiansky < >> andrew.gibiansky at gmail.com> wrote: >> >>> Mario, >>> >>> Thank you for that detailed write-up. That's exactly the sort of thing I >>> was looking for. >>> >>> I imagine a path like the one you describe is possible, but very, very >>> difficult, and likely the effort could be better spent elsewhere. >>> >>> I imagine an alternate route (that would have immediate gains in the >>> near future, and wouldn't be a long-term transition plan) would be to have >>> a `text-base` package, which exports everything `base` does, exporting >>> `Text` instead of `String`. Then base packages off that instead of `base`, >>> thus ensuring you do not rely on []-manipulation for `String` (you should >>> still have full compatibility with normal `base`). >>> >>> Anyway, hard choices all around, for no 100% clear gain, so I personally >>> do not envision this happening any time soon. Oh well... >>> >>> -- Andrew >>> >>> On Fri, May 22, 2015 at 6:07 PM, Michal Antkiewicz < >>> mantkiew at gsd.uwaterloo.ca> wrote: >>> >>>> Mario, thanks for that great writeup. >>>> >>>> The switch can only happen if there's a way to make the old code >>>> somehow transparently work the same or better in the new setup. >>>> >>>> Maybe some GHC magic could bring the string operations to Prim Ops and >>>> transparently switch the underlying representation to Text from [Char]. >>>> Basically, Text would have to become a built in primitive, not a library. >>>> >>>> Micha? >>>> >>>> On Fri, May 22, 2015 at 10:29 AM, Mario Bla?evi? >>>> wrote: >>>> >>>>> On 15-05-18 06:44 PM, Andrew Gibiansky wrote: >>>>> >>>>>> Hey all, >>>>>> >>>>>> In the earlier haskell-cafe discussion of IsString, someone mentioned >>>>>> that it would be nice to abandon [Char] as the blessed string type in >>>>>> Haskell. I've thought about this on and off for a while now, and think >>>>>> that the fact that [Char] is the default string type is a really big >>>>>> issue (for example, it gives beginners the idea that Haskell is >>>>>> incredibly slow, because everything that involves string processing is >>>>>> using linked lists). >>>>>> >>>>>> I am not proposing anything, but am curious as to what already has >>>>>> been >>>>>> discussed: >>>>>> >>>>>> 1. Has the possibility of migrating away from [Char] been investigated >>>>>> before? >>>>>> >>>>> >>>>> No, not seriously as far as I'm aware. That ship has sailed a >>>>> long time ago. Still, as I have actually thought about that, I'll give you >>>>> an outline of a possible process. >>>>> >>>>> >>>>> 2. What gains could we see in ease of use, performance, etc, if [Char] >>>>>> was deprecated? >>>>>> >>>>> >>>>> They could be very significant for any code that took >>>>> advantage of the new type, but the existing code would not benefit that >>>>> much. But then, any new Haskell code can already use Text where performance >>>>> matters. >>>>> >>>>> >>>>> 3. What could replace [Char], while retaining the same ease of use for >>>>>> writing string manipulation functions (pattern matching, etc)? >>>>>> >>>>> >>>>> You would not have the same ease of use exactly. The options >>>>> would lie between two extremes. At one end, you can have a completely >>>>> opaque String type with fromChars/toChars operations and nothing else. At >>>>> the other end, you'd implement all operations useful on strings so there >>>>> would never be any need to convert between String and [Char]. >>>>> >>>>> The first extreme would be mostly useless from the performance >>>>> point of view, but with some GHC magic perhaps it could be made a viable >>>>> upgrade path. The compiler would have to automatically insert the implicit >>>>> fromChars/toChars conversion whenever necessary, and I expect that some of >>>>> the existing Haskell code would still be broken. >>>>> >>>>> Once you have an opaque String type, you can think about >>>>> improving the performance. A more efficient instance of Monoid String would >>>>> be a good start, especially since it wouldn't break backward compatibility. >>>>> Unfortunately that is the only [Char] instance in wide use that can be >>>>> easily optimized. Perhaps Foldable could be made to work with even more >>>>> compiler magic, but I doubt it would be worth the effort. >>>>> >>>>> If you add more operations on String that don't require >>>>> >>>>> >>>>> 4. Is there any sort of migration path that would make this change >>>>>> feasible in mainline Haskell in the medium term (2-5 years)? >>>>>> >>>>> >>>>> Suppose GHC 7.12 were to bring Text into the core libraries, >>>>> change Prelude to declare type String = Text, and sprinkle some magic >>>>> compiler dust to make the explicit Text <-> Char conversions unnecessary. >>>>> >>>>> The existing Haskell code would almost certainly perform worse >>>>> overall. The only improved operations would be mappend on String, and >>>>> possibly the string literal instantiation. >>>>> >>>>> I don't think there's any chance to get this kind of change >>>>> proposal accepted today. You'd have to make the pain worth the gain. >>>>> The only viable path is to ensure beforehand that the change improves >>>>> more than just the mappend operation. >>>>> >>>>> In other words, you'd have to get today's String to >>>>> instantiate more classes in common with tomorrow's String, and you'd have >>>>> to get the everyday Haskell code to use those classes instead of list >>>>> manipulations. >>>>> >>>>> The first tentative step towards the String type change would >>>>> then be either the mono-traversable or my own monoid-subclasses package. >>>>> They both define new type classes that are instantiated by both [Char] and >>>>> Text. The main difference is that the former builds upon the Foldable >>>>> foundation, the latter upon Monoid. They are both far from being a complete >>>>> replacement for list manipulations. But any new code that used their >>>>> operations would see a big improvement from the String type change. >>>>> >>>>> Here, then, is the five-year plan you're asking for: >>>>> >>>>> Year one: Agree on the ideal set of type classes to bridge the gap >>>>> between [Char] and Text. >>>>> >>>>> Year two: Bring the new type classes into the Prelude. Have all >>>>> relevant types instantiate them. Everybody's updating their code in delight >>>>> to use the new class methods. >>>>> >>>>> Year three: GHC issues warnings about using List-specific [], ++, >>>>> null, take, drop, span, drop, etc, on String. Everybody's furiously >>>>> updating their code. >>>>> >>>>> Year four: Add Text to the core libraries. The GHC magic to make the >>>>> Text <-> [Char] convertions implicit is implemented and ready for testing >>>>> but requires a pragma. >>>>> >>>>> Year five: Update Haskell language report. Flip the switch. >>>>> >>>>> So there. How feasible does that sound? >>>>> >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>> >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Fri May 22 23:06:18 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Fri, 22 May 2015 20:06:18 -0300 Subject: [Haskell-cafe] ANN: nonce package Message-ID: <555FB66A.9000904@gmail.com> (Please forgive me if you received multiple copies of this e-mail.) Hello, The nonce package [1] contains functions to easily generate cryptographic nonces for many situations. Some places where these generated nonces can be used include: - Password recovery e-mail tokens. - XSRF protection tokens. - Session IDs sent on cookies. - Initialization vectors. It uses an AES CPRNG periodically reseeded from /dev/urandom (or equivalent). It has no frills, no knobs, so it's hard to misuse. It's been available for an year but I just realized I've never properly announced it. Regrettably, I've seen many uses of the random package (System.Random) when generating nonces. It's a bad choice: it is not a cryptographically secure PRNG, contains low entropy (64-bit state), and its default usage is seeded predictably (using a constant seed). Please avoid using the random package for generating nonces at all costs. In its stead, use the nonce package or something similar. Cheers, [1] http://hackage.haskell.org/package/nonce -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From briand at aracnet.com Sat May 23 04:23:45 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Fri, 22 May 2015 21:23:45 -0700 Subject: [Haskell-cafe] open gl type conversions In-Reply-To: References: <20150521221359.11509566@cedar.deldotd.com> Message-ID: <20150522212345.525226a9@cedar.deldotd.com> On Fri, 22 May 2015 08:56:59 +0200 Sven Panne wrote: > 2015-05-22 7:13 GMT+02:00 : > > [...] GL.Size really needs a CInt so it seems like I have to do some sort > of explicit conversion, but I can never seem to figure out exactly how to > find the necessary function. > > To be exact, Size expects 2 GLsizei > > arguments, > and GLsizei is a type synonym for CInt > , > but what this latter type actually is shouldn't matter most of the time. > The only thing you need to know here is that it's an integral number, and > your swiss army knife for conversion between integral numerical types is: > > fromIntegral > > :: (Integral a, Num b) => a -> b > > Don't be scared by its canonical definition (fromInteger . toInteger), GHC > has enough RULES to make this very efficient most of the time or even a > no-op. > aha. thanks very much. I wanted to get a complete end-to-end understanding of this, so forgive the blabbering, but it might be useful to some random reader of the list. viewport :: StateVar (Position, Size) data Size = Size !GLsizei !GLsizei type GLsizei = CInt as you said- Size eventually resolves to Size CInt CInt and then, I think this is the part that has been tripping me up in general, because i'm still not quite getting how the whole typeclass qualification of arguments thing, CInt : Instances -> Integral CInt and Int : Instances -> Integral Int so Int and CInt are both instances of Integral. fromIntegral :: (Integral a, Num b) => a -> b but wait! it's not over. fromIntegral restricts (is that the right way to phrase it ?) the first argument to be instance of Integral and the second argument to an instance of Num. So checking the Num typeclass I find that both Int AND CInt are instances. So truly fromIntegral is a swiss army knife... It turns out hoogle is not your friend. It doesn't figure out that fromIntegral will work, unless of course, you put in the _exact_ type signature. Given the number of other options it provides it's really kind of weird that it doesn't list fromIntegral too. Is that a bug ? Eventually if you keep perusing the Numeric section of the prelude you will run across it. Quite a bit of work to convert an int to an int. lol. Thanks again for your help. Brian From david.feuer at gmail.com Sat May 23 04:30:49 2015 From: david.feuer at gmail.com (David Feuer) Date: Sat, 23 May 2015 00:30:49 -0400 Subject: [Haskell-cafe] Fwd: Abandoning String = [Char]? In-Reply-To: References: <555F3D4B.5030804@stilo.com> Message-ID: Performance will go utterly out the window if you use pattern synonyms and the like to pretend that Text is [Char]. It would probably work fine (great, even) when matching, but code that assumes String=[Char] would be completely killed on the construction side, because building Text by consing, or repeatedly prepending small chunks, is ridiculously inefficient. These are the very things that are *efficient* with [Char], and that people have assumed to be efficient when writing code that uses it. On May 22, 2015 5:58 PM, "Carter Schonwald" wrote: > > one direction that this thread has *COMPLETELY* overlooked is the following: > > could we use pattern synonyms or something along those lines to make the migration to Text or the like more seemless? From thomas at koch.ro Sat May 23 13:49:07 2015 From: thomas at koch.ro (Thomas Koch) Date: Sat, 23 May 2015 15:49:07 +0200 Subject: [Haskell-cafe] no Web-Security component in Haskell? In-Reply-To: <2608800.UApO9Nzphg@x121e> References: <2608800.UApO9Nzphg@x121e> Message-ID: <3365849.1UF3EEsXps@x121e> // moving the question with more info from haskell-cafe to web-devel Hallo, I already wrote a message with the same subject to haskell-cafe without reply. I did not found anything comparable to Spring Security[1][2] (Java) or Symfony Security[3] (PHP) in Haskell. Both components are used in web applications to grant or deny access to resources based on roles, ACLs or custom voters. [1] http://projects.spring.io/spring-security [2] http://docs.spring.io/autorepo/docs/spring-security/3.1.7.RELEASE/apidocs [3] http://api.symfony.com/master/Symfony/Component/Security/Core/SecurityContext.html A naive strategy would be to port the concepts of both components, which are very similar, to Haskell. They represent a lot of accumulated knowledge from many experts about web security. Or are there better ways to do web security in a powerful language like Haskell? There was some unfinished role-based-access-control effort in snap[4] that has been removed from git now. [4] https://groups.google.com/forum/#!topic/snap_framework/yUgSEVpP2GE There seem to be a more modern (and more complex) thing than Role-Based- Access-Control now, XACML[5] which is used inside Red Hats JBoss[6]. [5] http://en.wikipedia.org/wiki/XACML [6] http://picketlink.org/about Regards, Thomas Koch From claude at mathr.co.uk Sat May 23 15:12:19 2015 From: claude at mathr.co.uk (Claude Heiland-Allen) Date: Sat, 23 May 2015 16:12:19 +0100 Subject: [Haskell-cafe] Increasing parallelism in a frequency counter In-Reply-To: References: Message-ID: <556098D3.8050003@mathr.co.uk> Hi Andreas, all, On 21/05/15 22:08, Andreas Pauley wrote: > Hi everyone, > > I've started playing with some parallel programming in Haskell, mostly > by applying the first few examples from Simon Marlow's book to my own > toy problem: > https://github.com/apauley/parallel-frequency Nice. > I'm quite pleased with the speedup I have so far, the fastest parallel > implementation is just over twice as fast as its sequential > counterpart. > > But looking at the threadscope images from the generated event logs I > can see that there are still significant portions of my program that > runs on only one core. > > Is anyone interested to see if we can increase the parallelism in this > frequency counter? If the problem is specified as taking the N most frequently occuring items in a list: f :: Ord a => Int -> [a] -> [(a, Int)] then I cheated, I assume the input is pre-chunked into a sensible number of pieces: f' :: Ord a => Int -> [[a]] -> [(a, Int)] with which it is much easier to get good parallel speedups. Anyway, some general optimisation points, not all directly related to the parallel part of the problem: 0. profile to see what is taking time (and space, it increases GC time) you can use +RTS -h without having to recompile for profiling 1. lists are memory inefficient (eg: Map keys): replace String with Text 2. lists and Text are bad at random access (eg: splitting at an index) 3. use Data.Map.Strict to avoid building up (+) thunks 4. (take n . sort) is possibly taking a lot of sequential time (see 0) 5. perhaps try parallel reductions instead of linear folds: a * b * c * d * ... -> ((a * b) * (c * d)) * ... though the overhead didn't seem worth it in my tests 6. not optimisation related, but consider writing a defaultMain then each executable source can be reduce to import DefaultMain (defaultMain) import FrequencyImplementation (frequency) main :: IO () main = defaultMain frequency you could even have all the implementations with the same module name but in different directories, and use hs-src-dirs: to select, then you would be able to use an identical Main module. more on 2: A bit of a low-level hack, this: I read the whole input file as a ByteString and split it into an appropriate number of chunks, taking care not to split UTF-8 sequences, also taking care not to split mid-word. Each output chunk references the original input without copying the data. Then I decodeUtf8 each ByteString chunk to a Text. This reduced peak memory usage (as reported by +RTS -h graphed with hp2ps) from ~400MB of (:) to ~30MB of ARR_WORDS for the 11MB artamene.txt. more on 4: So you have a large Map k Int containing frequencies, and you want the largest n frequency counts. There is an O(1) Map.splitRoot, which you can use to parallel divide and conquer - the largest n of the whole map are going to be among the (n * split count) combined largest n of each of the split maps. This didn't give me much speed up at all, though. I put my implementation at http://code.mathr.co.uk/word-histogram Thanks, Claude -- http://mathr.co.uk From tdammers at gmail.com Sat May 23 16:02:13 2015 From: tdammers at gmail.com (Tobias Dammers) Date: Sat, 23 May 2015 18:02:13 +0200 Subject: [Haskell-cafe] [Haskell] ANN: nonce package In-Reply-To: <555FB66A.9000904@gmail.com> References: <555FB66A.9000904@gmail.com> Message-ID: <20150523160211.GA10577@nibbler> Looks useful; feature request: something like nonce :: MonadIO => Int -> Generator (plus -url and -T flavors, obviously). I believe allowing the programmer to balance security vs. usability demands would be a good thing overall and worth a knob. -> m ByteString On Fri, May 22, 2015 at 08:06:18PM -0300, Felipe Lessa wrote: > (Please forgive me if you received multiple copies of this e-mail.) > > Hello, > > The nonce package [1] contains functions to easily generate > cryptographic nonces for many situations. Some places where these > generated nonces can be used include: > > - Password recovery e-mail tokens. > > - XSRF protection tokens. > > - Session IDs sent on cookies. > > - Initialization vectors. > > It uses an AES CPRNG periodically reseeded from /dev/urandom (or > equivalent). It has no frills, no knobs, so it's hard to misuse. It's > been available for an year but I just realized I've never properly > announced it. > > Regrettably, I've seen many uses of the random package (System.Random) > when generating nonces. It's a bad choice: it is not a > cryptographically secure PRNG, contains low entropy (64-bit state), and > its default usage is seeded predictably (using a constant seed). Please > avoid using the random package for generating nonces at all costs. In > its stead, use the nonce package or something similar. > > Cheers, > > [1] http://hackage.haskell.org/package/nonce > > -- > Felipe. > > _______________________________________________ > Haskell mailing list > Haskell at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell -- Tobias Dammers - tdammers at gmail.com From apauley at gmail.com Sun May 24 21:07:12 2015 From: apauley at gmail.com (Andreas Pauley) Date: Sun, 24 May 2015 23:07:12 +0200 Subject: [Haskell-cafe] Increasing parallelism in a frequency counter In-Reply-To: <556098D3.8050003@mathr.co.uk> References: <556098D3.8050003@mathr.co.uk> Message-ID: Hi Claude, On 23 May 2015 at 17:12, Claude Heiland-Allen wrote: > > > > Anyway, some general optimisation points, not all directly related to the > parallel part of the problem: Thank you so much for taking the time to implement your own version, and to explain everything you did. Your slowest sequential version is about 3 times faster than my fastest parallel version, I'm really impressed :-) Thank you also for the general coding tips, I'll definitely do some cleanup with a defaultMain or similar. I am busy looking at your implementation together with the optimisation points you mentioned. There is a lot for me to absorb, and I'll probably learn more from comparing your code (and the thinking behind it) with mine than I would have just reading a book or an article. Is there a field in computer science similar to comparative literature? Because I find comparing different implementations of the same program very useful as a learning tool. Kind regards, Andreas -- https://keybase.io/apauley http://za.linkedin.com/in/apauley http://www.meetup.com/lambda-luminaries http://www.meetup.com/Bitcoins-Baby-Bitcoins GPG Public Key: https://keybase.io/apauley/key.asc From bos at serpentine.com Mon May 25 04:22:51 2015 From: bos at serpentine.com (Bryan O'Sullivan) Date: Sun, 24 May 2015 21:22:51 -0700 Subject: [Haskell-cafe] Fwd: Abandoning String = [Char]? In-Reply-To: References: <555F3D4B.5030804@stilo.com> Message-ID: On Fri, May 22, 2015 at 9:30 PM, David Feuer wrote: > It would probably work > fine (great, even) when matching, but code that assumes String=[Char] > would be completely killed on the construction side, because building > Text by consing, or repeatedly prepending small chunks, is > ridiculously inefficient. > Actually, pattern-matching against Text using synonyms doesn't do so well performance-wise either. The unpack-on-the-left function is uncons, which has to do work and allocate memory. -------------- next part -------------- An HTML attachment was scrubbed... URL: From Andrew.Butterfield at scss.tcd.ie Mon May 25 08:28:16 2015 From: Andrew.Butterfield at scss.tcd.ie (Andrew Butterfield) Date: Mon, 25 May 2015 09:28:16 +0100 Subject: [Haskell-cafe] Increasing parallelism in a frequency counter In-Reply-To: References: <556098D3.8050003@mathr.co.uk> Message-ID: > On 24 May 2015, at 22:07, Andreas Pauley wrote: > > I am busy looking at your implementation together with the > optimisation points you mentioned. > There is a lot for me to absorb, and I'll probably learn more from > comparing your code (and the thinking behind it) with mine than I > would have just reading a book or an article. > > Is there a field in computer science similar to comparative > literature? Because I find comparing different implementations of the > same program very useful as a learning tool. Look at exercism.io - it supports Haskell Andrew Butterfield School of Computer Science & Statistics Trinity College Dublin 2, Ireland From sean at functionaljobs.com Mon May 25 16:00:01 2015 From: sean at functionaljobs.com (Functional Jobs) Date: Mon, 25 May 2015 12:00:01 -0400 Subject: [Haskell-cafe] New Functional Programming Job Opportunities Message-ID: <55634703cadb9@functionaljobs.com> Here are some functional programming job opportunities that were posted recently: Clojure/Erlang backend engineer/architect at Zoomo http://functionaljobs.com/jobs/8831-clojure-erlang-backend-engineer-architect-at-zoomo Cheers, Sean Murphy FunctionalJobs.com From adam at bergmark.nl Mon May 25 22:13:09 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Tue, 26 May 2015 00:13:09 +0200 Subject: [Haskell-cafe] aeson-utils: aeson-0.9 compatibility package Message-ID: Hi folks, aeson-0.9 was released today. It changes the behavior of `decode` and `eitherDecode`: They now both allow atomic values on the top level. Previously the behavior was inconsistent, `encode 1 = "1"` but `decode "1" :: Maybe Int = Nothing`. aeson-utils[1] has the functions `decodeV` and `eitherDecodeV` that work like aeson-0.9's `decode` and `eitherDecode` respectively, also with older aeson versions. If you want to stay backwards compatible without having varying semantics based on dependencies, check it out! [1] http://hackage.haskell.org/package/aeson-utils Regards, Adam -------------- next part -------------- An HTML attachment was scrubbed... URL: From briand at aracnet.com Tue May 26 05:19:31 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Mon, 25 May 2015 22:19:31 -0700 Subject: [Haskell-cafe] help with glfw seg-fault Message-ID: <20150525221931.40d810ff@cedar.deldotd.com> Hi, GLFW.swapBuffers w is the culprit. Not sure where to go from there. That's a pretty low level failure. Any suggestions. Brian From dani at dpwright.com Tue May 26 05:34:16 2015 From: dani at dpwright.com (Daniel P. Wright) Date: Tue, 26 May 2015 14:34:16 +0900 Subject: [Haskell-cafe] help with glfw seg-fault In-Reply-To: <20150525221931.40d810ff@cedar.deldotd.com> References: <20150525221931.40d810ff@cedar.deldotd.com> Message-ID: <2072714A-644D-4A35-A3D8-8065404A5F32@dpwright.com> Hi Brian, Have you checked for / output any GL errors that happen before you call swapBuffers? I have a function printErrors (as defined here http://dpwright.com/posts/2015/03/25/the-haskell-gl-package/#error-handling-utilities ) which I scatter around when things go wrong to try and find the root cause... -Dani 2015/05/26 14:19? ??????: > Hi, > > GLFW.swapBuffers w > > is the culprit. > > Not sure where to go from there. > > That's a pretty low level failure. > > Any suggestions. > > Brian > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From chneukirchen at gmail.com Sat May 23 14:07:36 2015 From: chneukirchen at gmail.com (Christian Neukirchen) Date: Sat, 23 May 2015 16:07:36 +0200 Subject: [Haskell-cafe] Munich Haskell Meeting, 2015-05-25 @ 19:30 Message-ID: <87zj4vo09j.fsf@gmail.com> Dear all, Next week, our monthly Munich Haskell Meeting will take place again on Monday, May 25 at Cafe Puck at 19h30. For details see here: http://www.haskell-munich.de/dates If you plan to join, please add yourself to this dudle so we can reserve enough seats! It is OK to add yourself to the dudle anonymously or pseudonymously. https://dudle.inf.tu-dresden.de/haskell-munich-may-2015/ Everybody is welcome! cu, -- Christian Neukirchen http://chneukirchen.org From anakreonmejdi at gmail.com Tue May 26 12:24:22 2015 From: anakreonmejdi at gmail.com (Anakreontas) Date: Tue, 26 May 2015 05:24:22 -0700 (PDT) Subject: [Haskell-cafe] Installing ghc-mod on Windows In-Reply-To: References: <1cd18995-9e54-4e76-9a72-e08a32b2f560@googlegroups.com> <555F54A7.7090103@ro-che.info> <87h9r4trep.fsf@imag.fr> Message-ID: <93475100-7311-4aa8-b2c6-c041363d65b2@googlegroups.com> I think cabal reported errors regarding the header files where in fact the problem was that it could not find a c compiler. I tried to install QuickCheck and the primitives package required by QuickCheck failed to install with errors related to header files. After installing gcc, primitives and QuickCheck installed without errors. On Tuesday, May 26, 2015 at 11:18:30 AM UTC+1, Anakreontas wrote: > > ... continued from previous message > .. even with command cabal install --extra-include-dirs=include cabal > still reports an error. > The header file is useful for older ghc versions that the one I have so > removing the dependency on the header resolved the problem. > > On Tue, May 26, 2015 at 11:16 AM, Anakreontas Mentis < > anakreonmejdi at gmail.com> wrote: > >> I installed the MinGHC distribution but it did not solve the problem. >> >> To install ghc-mod I had to: >> 1) cabal install ghc-mod >> to install what cabal can build without errors. >> 2) Modify the cabal file of ansiterminal according to Roman's advice. It >> installed successfully. >> 3) Modify the cabal file of lifted-base where I removed the Include-dirs >> and Includes directives and all references to inlinable.h from the source >> files. >> cabal reports that it can not find the header file or it is damaged. >> The file exists in the include directory but even with >> >> On Fri, May 22, 2015 at 7:58 PM, Michal Antkiewicz < >> mantkiew at gsd.uwaterloo.ca> wrote: >> >>> There used to be a big warning "don't download just the ghc. Use the >>> platform. " before. >>> >>> Nowadays, it's best to get MinGHC from >>> >>> https://www.haskell.org/downloads/windows >>> >>> this distribution is best, it'll allow you build the network package and >>> other things like the ansi-terminal, etc. >>> >>> Get the 32bit installer. >>> >>> Micha? >>> >>> On Fri, May 22, 2015 at 2:10 PM, wrote: >>> >>>> Hello. >>>> I don't know the MinGHC release. To install ghc I downloaded a windows >>>> install program from https://www.haskell.org/ghc/. >>>> >>>> >>>> Michal Antkiewicz writes: >>>> >>>> > Hi, >>>> > >>>> > are you using msys and MinGHC? >>>> > >>>> > For now, I clone ghc-mod @ master and just cabal install it (with >>>> MinGHC >>>> > 0.7.10 and cabal 1.22) within msys. It has not been released yet. >>>> > >>>> > Micha? >>>> > >>>> > On Fri, May 22, 2015 at 12:09 PM, Roman Cheplyaka >>>> wrote: >>>> > >>>> >> On 22/05/15 18:06, Anakreontas wrote: >>>> >> > I tried to instal ghc-mod on Windows with cabal. Two dependencies >>>> fail >>>> >> > to compile because of missing native libraries. >>>> >> > ansi-terminal requires kernel32 and >>>> >> > lifted-base requires inlinable.h. >>>> >> > >>>> >> > Have you solved a similar problem? In Linux it would be easy to >>>> install >>>> >> > the native libraries but in Windows I do not know which programs I >>>> >> > should install and where to find them. >>>> >> >>>> >> You should be able to install ansi-terminal by patching its cabal >>>> file, >>>> >> see https://github.com/feuerbach/ansi-terminal/issues/6 >>>> >> >>>> >> Once again, I'm asking Windows users and developers for their input >>>> on >>>> >> this issue. >>>> >> >>>> >> Roman >>>> >> >>>> >> >>>> >> _______________________________________________ >>>> >> Haskell-Cafe mailing list >>>> >> Haskell-Cafe at haskell.org >>>> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >> >>>> >> >>>> >>>> -- >>>> >>> >>> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Tue May 26 17:47:01 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 26 May 2015 12:47:01 -0500 Subject: [Haskell-cafe] ClassyPrelude vs. Haskell.Language.Interpreter Message-ID: No answer on -beginners, so I'm trying -cafe. I'm trying to run interpreted code via ClassyPrelude, and getting some results that make me suspect a bug in the Prelude's type system. Or maybe the interpreter. Anyway, here's a bit of code that works as expected: {-# LANGUAGE NoImplicitPrelude #-} import ClassyPrelude import Language.Haskell.Interpreter main :: IO () main = do fun <- runInterpreter $ makeFun "reverse" case fun of Left e -> print e Right f -> readFile "/etc/motd" >>= hPut stdout . f makeFun expr = do set [languageExtensions := [NoImplicitPrelude]] setImportsQ [("ClassyPrelude", Nothing)] interpret expr (as :: Text -> Text) I don't think I can simplify this any further. It works as expected, and also works as expected, and prints out the contents of /etc/motd reversed. However, if you change the type signature in the last line from Text -> Text to LText -> Ltext (to get lazy text), you get no output. But if you change the function in the first line after main from "reverse" to "id", it works. So far, it might be an issue with lazy IO. However, change the type signature in the last line to LText -> Text. In this case, there is no output for either value of the expression. I expect an error in this case, as neither id nor reverse should be able to have the type LText -> Text! So, is there something I missed in either ClassyPrelude or the Interpreter? Or is this a subtle interaction, in which case can someone suggest a workaround? Or have I found a bug in one of the two? -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Tue May 26 22:35:12 2015 From: mwm at mired.org (Mike Meyer) Date: Tue, 26 May 2015 17:35:12 -0500 Subject: [Haskell-cafe] ClassyPrelude vs. Haskell.Language.Interpreter In-Reply-To: References: Message-ID: Actually, I think there's at least one bug in ghc. My testing was all done on 7.8. When I tried running it on 7.10, reverse gives the out of memory error that Michael Sloan reported. Not really good, but acceptable, as you probably shouldn't be using lazy text in that situation. Trying to use LText -> Text (which generates a type error if I try it without the interpreter) on 7.8 gets no output, but on 7.10 eventually segfaults. On Tue, May 26, 2015 at 5:11 PM, Corentin Dupont wrote: > Lazy text is this one? > http://hackage.haskell.org/package/text-1.1.0.1/docs/Data-Text-Lazy.html > > At first sight I'd say it's the way lazy text works with reverse that the > interpreter doesn't like... > > On Tue, May 26, 2015 at 7:47 PM, Mike Meyer wrote: > >> No answer on -beginners, so I'm trying -cafe. >> >> I'm trying to run interpreted code via ClassyPrelude, and getting some >> results that make me suspect a bug in the Prelude's type system. Or maybe >> the interpreter. >> >> Anyway, here's a bit of code that works as expected: >> >> {-# LANGUAGE NoImplicitPrelude #-} >> >> import ClassyPrelude >> import Language.Haskell.Interpreter >> >> main :: IO () >> main = do >> fun <- runInterpreter $ makeFun "reverse" >> case fun of >> Left e -> print e >> Right f -> readFile "/etc/motd" >>= hPut stdout . f >> >> >> makeFun expr = do >> set [languageExtensions := [NoImplicitPrelude]] >> setImportsQ [("ClassyPrelude", Nothing)] >> interpret expr (as :: Text -> Text) >> >> >> I don't think I can simplify this any further. It works as expected, and >> also works as expected, and prints out the contents of /etc/motd reversed. >> >> However, if you change the type signature in the last line from Text -> >> Text to LText -> Ltext (to get lazy text), you get no output. But if you >> change the function in the first line after main from "reverse" to "id", it >> works. >> >> So far, it might be an issue with lazy IO. However, change the type >> signature in the last line to LText -> Text. In this case, there is no >> output for either value of the expression. I expect an error in this case, >> as neither id nor reverse should be able to have the type LText -> Text! >> >> So, is there something I missed in either ClassyPrelude or the >> Interpreter? Or is this a subtle interaction, in which case can someone >> suggest a workaround? Or have I found a bug in one of the two? >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mgsloan at gmail.com Tue May 26 21:15:28 2015 From: mgsloan at gmail.com (Michael Sloan) Date: Tue, 26 May 2015 14:15:28 -0700 Subject: [Haskell-cafe] ClassyPrelude vs. Haskell.Language.Interpreter In-Reply-To: References: Message-ID: Hi Mike! I'm not sure what's going on here. When I run that code with LText, with the string "hi" (instead of reading motd), I get an "out of memory" exception. So, I don't think this is an issue with lazy IO. However, storing values produced by an interpreter session reminds me of Chris's foreign-store package. Might be worth a shot: http://hackage.haskell.org/package/foreign-store -Michael On Tue, May 26, 2015 at 10:47 AM, Mike Meyer wrote: > No answer on -beginners, so I'm trying -cafe. > > I'm trying to run interpreted code via ClassyPrelude, and getting some > results that make me suspect a bug in the Prelude's type system. Or maybe > the interpreter. > > Anyway, here's a bit of code that works as expected: > > {-# LANGUAGE NoImplicitPrelude #-} > > import ClassyPrelude > import Language.Haskell.Interpreter > > main :: IO () > main = do > fun <- runInterpreter $ makeFun "reverse" > case fun of > Left e -> print e > Right f -> readFile "/etc/motd" >>= hPut stdout . f > > > makeFun expr = do > set [languageExtensions := [NoImplicitPrelude]] > setImportsQ [("ClassyPrelude", Nothing)] > interpret expr (as :: Text -> Text) > > > I don't think I can simplify this any further. It works as expected, and > also works as expected, and prints out the contents of /etc/motd reversed. > > However, if you change the type signature in the last line from Text -> > Text to LText -> Ltext (to get lazy text), you get no output. But if you > change the function in the first line after main from "reverse" to "id", it > works. > > So far, it might be an issue with lazy IO. However, change the type > signature in the last line to LText -> Text. In this case, there is no > output for either value of the expression. I expect an error in this case, > as neither id nor reverse should be able to have the type LText -> Text! > > So, is there something I missed in either ClassyPrelude or the > Interpreter? Or is this a subtle interaction, in which case can someone > suggest a workaround? Or have I found a bug in one of the two? > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Wed May 27 14:32:12 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Wed, 27 May 2015 17:32:12 +0300 Subject: [Haskell-cafe] Taking over protocol-buffers package Message-ID: Hi Chris and Cafe! I've sent Chris an email couple days ago, this is another one to have haskell-cafe CCed in order to request maintainership of protocol-buffers package. Stefan Wehr actually tried to contact Chris long time ago, and thus you can see current "riak" package depends upon protocol-buffers-fork package, created to add support for GHC 7.8. I'd like to incorporate work from protocol-buffers-fork, add support for GHC 7.10, and also move project to GitHub and add some README with at least basic tutorial. Thanks! Awaiting few weeks now :) -------------- next part -------------- An HTML attachment was scrubbed... URL: From alois.cochard at gmail.com Wed May 27 14:34:11 2015 From: alois.cochard at gmail.com (Alois Cochard) Date: Wed, 27 May 2015 16:34:11 +0200 Subject: [Haskell-cafe] Account for the Haskell Wiki Message-ID: Hi, I would like a user account to access the Haskell wiki. Desired username: 'aloiscochard' Cheers -- *?\ois* http://twitter.com/aloiscochard http://github.com/aloiscochard -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Wed May 27 18:30:42 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Wed, 27 May 2015 19:30:42 +0100 Subject: [Haskell-cafe] ZeroMQ Thread Safety Message-ID: Hi all, According to the ZeroMQ docs[1]: "Individual ?MQ sockets are not thread safe except in the case where full memory barriers are issued when migrating a socket from one thread to another." The Haskell ZeroMQ binding [2] is a fairly thin wrapper around the C API, and in particular doesn't seem to do much to enforce thread safety as described above. My question: do I need to use bound threads to call functions on sockets to ensure that all the foreign calls happen on the same OS thread, or is it the case that two consecutive foreign calls in a single Haskell thread have a "full memory barrier" between them if they end up being called from different OS threads? Thanks in advance, David [1] http://api.zeromq.org/4-0:zmq [2] http://hackage.haskell.org/package/zeromq4-haskell From lsp at informatik.uni-kiel.de Wed May 27 20:01:11 2015 From: lsp at informatik.uni-kiel.de (lennart spitzner) Date: Wed, 27 May 2015 22:01:11 +0200 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) Message-ID: <55662287.7000201@informatik.uni-kiel.de> Greetings, Regarding the pqueue package: 1) Does anyone have any (additional) contact details for the current maintainer/author, Louis Wasserman? 2) Is the package's repository available anywhere? The darcs link listed in the package 404s. 3) I would be willing to take over for basic maintenance if the current maintainer is unavailable. The pqueue package does not compile with ghc-7.10. Fixing requires just some quick changes (i have a working version locally). The last upload for the package is from 2012, but the author's github account lowasser shows some more recent activity. Yet I have not received a reply to my e-mail from six weeks ago. Lennart From adam at bergmark.nl Wed May 27 20:37:25 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Wed, 27 May 2015 22:37:25 +0200 Subject: [Haskell-cafe] Taking over protocol-buffers package In-Reply-To: References: Message-ID: Keping track of this here: https://github.com/haskell-infra/hackage-trustees/issues/37 On Wed, May 27, 2015 at 4:32 PM, Kostiantyn Rybnikov wrote: > Hi Chris and Cafe! > > I've sent Chris an email couple days ago, this is another one to have > haskell-cafe CCed in order to request maintainership of protocol-buffers > package. > > Stefan Wehr actually tried to contact Chris long time ago, and thus you > can see current "riak" package depends upon protocol-buffers-fork package, > created to add support for GHC 7.8. > > I'd like to incorporate work from protocol-buffers-fork, add support for > GHC 7.10, and also move project to GitHub and add some README with at least > basic tutorial. > > Thanks! Awaiting few weeks now :) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Wed May 27 20:39:19 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Wed, 27 May 2015 22:39:19 +0200 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: <55662287.7000201@informatik.uni-kiel.de> References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Keeping track of this here: https://github.com/haskell-infra/hackage-trustees/issues/38 On Wed, May 27, 2015 at 10:01 PM, lennart spitzner < lsp at informatik.uni-kiel.de> wrote: > Greetings, > > Regarding the pqueue package: > > 1) Does anyone have any (additional) contact details for the current > maintainer/author, Louis Wasserman? > 2) Is the package's repository available anywhere? The darcs link > listed in the package 404s. > 3) I would be willing to take over for basic maintenance if the > current maintainer is unavailable. > > The pqueue package does not compile with ghc-7.10. Fixing requires > just some quick changes (i have a working version locally). The last > upload for the package is from 2012, but the author's github account > lowasser shows some more recent activity. Yet I have not received a > reply to my e-mail from six weeks ago. > > Lennart > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From k-bx at k-bx.com Thu May 28 05:05:09 2015 From: k-bx at k-bx.com (Kostiantyn Rybnikov) Date: Thu, 28 May 2015 08:05:09 +0300 Subject: [Haskell-cafe] Taking over protocol-buffers package In-Reply-To: References: Message-ID: My hackage id is k_bx, if needed. On Wed, May 27, 2015 at 11:43 PM, Andrey Sverdlichenko wrote: > Go ahead, it took almost a year to push my patch to protocol-buffers, > active maintainer is definitely needed. > > On Wed, May 27, 2015 at 7:32 AM, Kostiantyn Rybnikov > wrote: > > Hi Chris and Cafe! > > > > I've sent Chris an email couple days ago, this is another one to have > > haskell-cafe CCed in order to request maintainership of protocol-buffers > > package. > > > > Stefan Wehr actually tried to contact Chris long time ago, and thus you > can > > see current "riak" package depends upon protocol-buffers-fork package, > > created to add support for GHC 7.8. > > > > I'd like to incorporate work from protocol-buffers-fork, add support for > GHC > > 7.10, and also move project to GitHub and add some README with at least > > basic tutorial. > > > > Thanks! Awaiting few weeks now :) > > > > > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From hsyl20 at gmail.com Thu May 28 01:07:51 2015 From: hsyl20 at gmail.com (Sylvain Henry) Date: Thu, 28 May 2015 03:07:51 +0200 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Hi, I have sent an email to the author two months ago about the same issue without receiving an answer either. My version of the package since then is here: https://github.com/hsyl20/pqueue In addition to making it compile with GHC 7.10, I have replaced all the tabs with spaces to remove the warnings. Sylvain 2015-05-27 22:39 GMT+02:00 Adam Bergmark : > Keeping track of this here: > https://github.com/haskell-infra/hackage-trustees/issues/38 > > > On Wed, May 27, 2015 at 10:01 PM, lennart spitzner < > lsp at informatik.uni-kiel.de> wrote: > >> Greetings, >> >> Regarding the pqueue package: >> >> 1) Does anyone have any (additional) contact details for the current >> maintainer/author, Louis Wasserman? >> 2) Is the package's repository available anywhere? The darcs link >> listed in the package 404s. >> 3) I would be willing to take over for basic maintenance if the >> current maintainer is unavailable. >> >> The pqueue package does not compile with ghc-7.10. Fixing requires >> just some quick changes (i have a working version locally). The last >> upload for the package is from 2012, but the author's github account >> lowasser shows some more recent activity. Yet I have not received a >> reply to my e-mail from six weeks ago. >> >> Lennart >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu May 28 08:26:58 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 28 May 2015 09:26:58 +0100 Subject: [Haskell-cafe] -fdefer-more-errors Message-ID: <20150528082658.GB30857@weber> Deferring type errors until runtime is a feature which probably helps a lot with the adoption of Haskell. Newcomers can get the encouragement of a mostly-working program even if there are type errors in a few places. I can write foo = 1 + 1 bar = head True main = print foo and still run the program or load it in GHCi. Does anyone think it would also be beneficial to have "-fdefer-name-errors"? If I write foo = 1 + 1 bar = baz main = print foo but baz doesn't exist it would still be nice to let the program run or be loaded in GHCi. This could be achieved by replacing all missing variables by "error 'baz was not defined'" or similar. If a suitable parser could be written it might even be possible to defer syntax errors! This kind of thing would make the experience with Haskell gentler for newcomers, but also more pleasant for veterans! Tom From mantkiew at gsd.uwaterloo.ca Thu May 28 13:21:57 2015 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Thu, 28 May 2015 06:21:57 -0700 (PDT) Subject: [Haskell-cafe] -fdefer-more-errors In-Reply-To: <20150528082658.GB30857@weber> References: <20150528082658.GB30857@weber> Message-ID: <9b65770c-f0e2-41d6-ba1c-ed734106c0ec@googlegroups.com> That is a great idea. I'd like to add that introducing a new option might not be necessary. How about automatically turning unresolved name errors into named type holes? That way, they would be deferred automatically with the existing option. Michal On Thursday, May 28, 2015 at 4:27:11 AM UTC-4, Tom Ellis wrote: > > Deferring type errors until runtime is a feature which probably helps a > lot > with the adoption of Haskell. Newcomers can get the encouragement of a > mostly-working program even if there are type errors in a few places. > I can write > > foo = 1 + 1 > bar = head True > main = print foo > > and still run the program or load it in GHCi. > > Does anyone think it would also be beneficial to have > "-fdefer-name-errors"? > If I write > > foo = 1 + 1 > bar = baz > main = print foo > > but baz doesn't exist it would still be nice to let the program run or be > loaded in GHCi. This could be achieved by replacing all missing variables > by "error 'baz was not defined'" or similar. > > If a suitable parser could be written it might even be possible to defer > syntax errors! > > This kind of thing would make the experience with Haskell gentler for > newcomers, but also more pleasant for veterans! > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mantkiew at gsd.uwaterloo.ca Thu May 28 13:21:57 2015 From: mantkiew at gsd.uwaterloo.ca (Michal Antkiewicz) Date: Thu, 28 May 2015 06:21:57 -0700 (PDT) Subject: [Haskell-cafe] -fdefer-more-errors In-Reply-To: <20150528082658.GB30857@weber> References: <20150528082658.GB30857@weber> Message-ID: <9b65770c-f0e2-41d6-ba1c-ed734106c0ec@googlegroups.com> That is a great idea. I'd like to add that introducing a new option might not be necessary. How about automatically turning unresolved name errors into named type holes? That way, they would be deferred automatically with the existing option. Michal On Thursday, May 28, 2015 at 4:27:11 AM UTC-4, Tom Ellis wrote: > > Deferring type errors until runtime is a feature which probably helps a > lot > with the adoption of Haskell. Newcomers can get the encouragement of a > mostly-working program even if there are type errors in a few places. > I can write > > foo = 1 + 1 > bar = head True > main = print foo > > and still run the program or load it in GHCi. > > Does anyone think it would also be beneficial to have > "-fdefer-name-errors"? > If I write > > foo = 1 + 1 > bar = baz > main = print foo > > but baz doesn't exist it would still be nice to let the program run or be > loaded in GHCi. This could be achieved by replacing all missing variables > by "error 'baz was not defined'" or similar. > > If a suitable parser could be written it might even be possible to defer > syntax errors! > > This kind of thing would make the experience with Haskell gentler for > newcomers, but also more pleasant for veterans! > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskel... at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk Thu May 28 13:26:52 2015 From: tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk (Tom Ellis) Date: Thu, 28 May 2015 14:26:52 +0100 Subject: [Haskell-cafe] -fdefer-more-errors In-Reply-To: <20150528082658.GB30857@weber> References: <20150528082658.GB30857@weber> Message-ID: <20150528132652.GF30857@weber> On Thu, May 28, 2015 at 09:26:58AM +0100, Tom Ellis wrote: > Does anyone think it would also be beneficial to have "-fdefer-name-errors"? [...] Via hamishmack on Haskell Reddit[1] there's already a Trac issue about this[2]. [1] http://www.reddit.com/r/haskell/comments/37km7e/fdeferscopeerrors_anyone/crnkdgq [2] https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19 From dominic at steinitz.org Mon May 25 19:58:45 2015 From: dominic at steinitz.org (Dominic Steinitz) Date: Mon, 25 May 2015 20:58:45 +0100 Subject: [Haskell-cafe] Libraries Mailing Problem? Message-ID: <672D16CA-FADC-4B98-A9D4-008200D58A94@steinitz.org> Is there something wrong with the libraries mailing list? There doesn?t seem to have been any traffic since 18 May: https://mail.haskell.org/pipermail/libraries/2015-May/date.html Dominic Steinitz dominic at steinitz.org http://idontgetoutmuch.wordpress.com -------------- next part -------------- An HTML attachment was scrubbed... URL: From dct25-561bs at mythic-beasts.com Thu May 28 16:24:50 2015 From: dct25-561bs at mythic-beasts.com (David Turner) Date: Thu, 28 May 2015 17:24:50 +0100 Subject: [Haskell-cafe] Consecutive FFI calls Message-ID: Hi, If I make a sequence of FFI calls (on a single Haskell thread) but which end up being called from different OS threads, is there any kind of ordering guarantee given? More specifically, is there a full memory barrier at the point where a Haskell thread migrates to a new OS thread? Many thanks, David From carter.schonwald at gmail.com Thu May 28 14:27:38 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 28 May 2015 10:27:38 -0400 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: I think Herbert helped me recover a copy of the Darcs repo a while ago. I'll check my email when I'm not traveling to see if I still have it. On Wednesday, May 27, 2015, Sylvain Henry wrote: > Hi, > > I have sent an email to the author two months ago about the same issue > without receiving an answer either. > > My version of the package since then is here: > https://github.com/hsyl20/pqueue > In addition to making it compile with GHC 7.10, I have replaced all the > tabs with spaces to remove the warnings. > > Sylvain > > > 2015-05-27 22:39 GMT+02:00 Adam Bergmark >: > >> Keeping track of this here: >> https://github.com/haskell-infra/hackage-trustees/issues/38 >> >> >> On Wed, May 27, 2015 at 10:01 PM, lennart spitzner < >> lsp at informatik.uni-kiel.de >> > wrote: >> >>> Greetings, >>> >>> Regarding the pqueue package: >>> >>> 1) Does anyone have any (additional) contact details for the current >>> maintainer/author, Louis Wasserman? >>> 2) Is the package's repository available anywhere? The darcs link >>> listed in the package 404s. >>> 3) I would be willing to take over for basic maintenance if the >>> current maintainer is unavailable. >>> >>> The pqueue package does not compile with ghc-7.10. Fixing requires >>> just some quick changes (i have a working version locally). The last >>> upload for the package is from 2012, but the author's github account >>> lowasser shows some more recent activity. Yet I have not received a >>> reply to my e-mail from six weeks ago. >>> >>> Lennart >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael.antosha at gmail.com Wed May 27 22:05:27 2015 From: michael.antosha at gmail.com (Michael V. Antosha) Date: Thu, 28 May 2015 01:05:27 +0300 Subject: [Haskell-cafe] foldt fix proposal (HaskellWiki) Message-ID: hi ALL, I think I've found a mistake in foldt implementation on the Fold page[1] of the HaskellWiki. foldt :: (a -> a -> a) -> a -> [a] -> a foldt f z [] = z foldt f z [x] = x -- mistake? -- foldt f z [x] = f x z -- fix proposal foldt f z xs = foldt f z (pairs f xs) pairs :: (a -> a -> a) -> [a] -> [a] pairs f (x:y:t) = f x y : pairs f t pairs f t = t Without the fix, foldt just ignores z value in all cases except for the case of empty input list. (Which is an inconsistent behaviour I suppose.) The Examples page[2] also needs corresponding fix. Is this mail list a right place to ask for the HaskellWiki page fix? Thanks! Michael. [1] Tree-like folds @ Fold @ HaskellWiki https://wiki.haskell.org/Fold#Tree-like_folds [2] Examples @ Fold @ HaskellWiki https://wiki.haskell.org/Fold#Examples -- Michael V. Antosha http://mivael.in.ua xmpp:m at mivael.in.ua (Jabber ID) From david.feuer at gmail.com Thu May 28 15:26:32 2015 From: david.feuer at gmail.com (David Feuer) Date: Thu, 28 May 2015 11:26:32 -0400 Subject: [Haskell-cafe] -fdefer-more-errors In-Reply-To: <9b65770c-f0e2-41d6-ba1c-ed734106c0ec@googlegroups.com> References: <20150528082658.GB30857@weber> <9b65770c-f0e2-41d6-ba1c-ed734106c0ec@googlegroups.com> Message-ID: Personally, I'd generally prefer if GHC got a little more interactive about name errors: "I couldn't find heod. Did you mean head?" And if the answer is yes, it could optionally edit the file for you, as well as continuing compilation. On May 28, 2015 9:22 AM, "Michal Antkiewicz" wrote: > That is a great idea. > > I'd like to add that introducing a new option might not be necessary. How > about automatically turning unresolved name errors into named type holes? > That way, they would be deferred automatically with the existing option. > > Michal > > On Thursday, May 28, 2015 at 4:27:11 AM UTC-4, Tom Ellis wrote: >> >> Deferring type errors until runtime is a feature which probably helps a >> lot >> with the adoption of Haskell. Newcomers can get the encouragement of a >> mostly-working program even if there are type errors in a few places. >> I can write >> >> foo = 1 + 1 >> bar = head True >> main = print foo >> >> and still run the program or load it in GHCi. >> >> Does anyone think it would also be beneficial to have >> "-fdefer-name-errors"? >> If I write >> >> foo = 1 + 1 >> bar = baz >> main = print foo >> >> but baz doesn't exist it would still be nice to let the program run or be >> loaded in GHCi. This could be achieved by replacing all missing >> variables >> by "error 'baz was not defined'" or similar. >> >> If a suitable parser could be written it might even be possible to defer >> syntax errors! >> >> This kind of thing would make the experience with Haskell gentler for >> newcomers, but also more pleasant for veterans! >> >> Tom >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskel... at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From wasserman.louis at gmail.com Thu May 28 01:09:41 2015 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Thu, 28 May 2015 01:09:41 +0000 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Hmmm. I may have a go at this over the weekend; I haven't done anything in a while but I will try to make some time. On Wed, May 27, 2015 at 6:07 PM Sylvain Henry wrote: > Hi, > > I have sent an email to the author two months ago about the same issue > without receiving an answer either. > > My version of the package since then is here: > https://github.com/hsyl20/pqueue > In addition to making it compile with GHC 7.10, I have replaced all the > tabs with spaces to remove the warnings. > > Sylvain > > > 2015-05-27 22:39 GMT+02:00 Adam Bergmark : > >> Keeping track of this here: >> https://github.com/haskell-infra/hackage-trustees/issues/38 >> >> >> On Wed, May 27, 2015 at 10:01 PM, lennart spitzner < >> lsp at informatik.uni-kiel.de> wrote: >> >>> Greetings, >>> >>> Regarding the pqueue package: >>> >>> 1) Does anyone have any (additional) contact details for the current >>> maintainer/author, Louis Wasserman? >>> 2) Is the package's repository available anywhere? The darcs link >>> listed in the package 404s. >>> 3) I would be willing to take over for basic maintenance if the >>> current maintainer is unavailable. >>> >>> The pqueue package does not compile with ghc-7.10. Fixing requires >>> just some quick changes (i have a working version locally). The last >>> upload for the package is from 2012, but the author's github account >>> lowasser shows some more recent activity. Yet I have not received a >>> reply to my e-mail from six weeks ago. >>> >>> Lennart >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From mrz.vtl at gmail.com Wed May 27 21:27:01 2015 From: mrz.vtl at gmail.com (Maurizio Vitale) Date: Wed, 27 May 2015 14:27:01 -0700 Subject: [Haskell-cafe] how to organize a parallel parser/compiler Message-ID: hello haskell-cafe, suppose you have a compiler pipeline roughly similar to (from write you a Haskell ): modl :: FilePath -> L.Text -> CompilerM () modl fname = parseP fname >=> dataP >=> groupP >=> renameP >=> desugarP >=> inferP >=> evalP and suppose you have a language where you can compile multiple files and compilation must be made _as if_ files were concatenated together in the order given on the command line (there might be side effects that affect parsing of subsequent files); still in the average case there're no dependencies and files could be compiled in parallel (or some of the dependencies can be handled at the AST level as one can prove they don't affect parsing but only aspects of the AST that can be patched). What are good strategies for dealing with this and rerun some of the parseP functions (and in the simplest solution the complete pipeline after it). The strategy I have in mind now doesn't mix well with the above pipeline, so I'd like to see if there're alternative solutions. Basically, what I have in mind is: - each parse function gets a file, something to watch on for the result of the previous parse (let's say an MVar, or some variation of speculation , not sure yet) and an input environment (same for everybody). It produces an AST + what he's sensitive to (e.g. what would have affected the parsing) and what he generates that the next guy must be sensitive to. - before producing the 'what it generates part', it must be sure to have completed a valid parse, so he'll wait on the input MVar to know that the previous files have been parsed properly and that whatever side effects it caised wouldn't affect parsing. This wait will be done on a thread that doesn't count towards the parallelism limit as it is presumably cheap and we don't really serialize the parsing. [a similar question related to the above pipeline would be how do I fit in any kind of global transformation pass] Is there any library or other ideas on how to combine multiple pipelines where we want to run them with maximum parallelism but the outcome of (even a partial step of) one pipeline can invalidate and require to rerun others? Thanks for any idea, Maurizio -------------- next part -------------- An HTML attachment was scrubbed... URL: From danburton.email at gmail.com Thu May 28 09:38:37 2015 From: danburton.email at gmail.com (Dan Burton) Date: Thu, 28 May 2015 02:38:37 -0700 Subject: [Haskell-cafe] -fdefer-more-errors In-Reply-To: <20150528082658.GB30857@weber> References: <20150528082658.GB30857@weber> Message-ID: Wow, I just posted to reddit asking about the same thing. Should have checked my email first. :) http://www.reddit.com/r/haskell/comments/37km7e/fdeferscopeerrors_anyone/ Obviously, I concur that this would make Haskell more pleasant for me. I just used -fdefer-type-errors today, which turned out to be a huge convenience, and I would have similarly benefited from -fdefer-name-errors. -- Dan Burton On Thu, May 28, 2015 at 1:26 AM, Tom Ellis < tom-lists-haskell-cafe-2013 at jaguarpaw.co.uk> wrote: > Deferring type errors until runtime is a feature which probably helps a lot > with the adoption of Haskell. Newcomers can get the encouragement of a > mostly-working program even if there are type errors in a few places. > I can write > > foo = 1 + 1 > bar = head True > main = print foo > > and still run the program or load it in GHCi. > > Does anyone think it would also be beneficial to have > "-fdefer-name-errors"? > If I write > > foo = 1 + 1 > bar = baz > main = print foo > > but baz doesn't exist it would still be nice to let the program run or be > loaded in GHCi. This could be achieved by replacing all missing variables > by "error 'baz was not defined'" or similar. > > If a suitable parser could be written it might even be possible to defer > syntax errors! > > This kind of thing would make the experience with Haskell gentler for > newcomers, but also more pleasant for veterans! > > Tom > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From david.feuer at gmail.com Wed May 27 22:06:29 2015 From: david.feuer at gmail.com (David Feuer) Date: Wed, 27 May 2015 18:06:29 -0400 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: <55662287.7000201@informatik.uni-kiel.de> References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Whoever takes over maintenance may want to consider producing unboxed versions. On Wed, May 27, 2015 at 4:01 PM, lennart spitzner wrote: > Greetings, > > Regarding the pqueue package: > > 1) Does anyone have any (additional) contact details for the current > maintainer/author, Louis Wasserman? > 2) Is the package's repository available anywhere? The darcs link > listed in the package 404s. > 3) I would be willing to take over for basic maintenance if the > current maintainer is unavailable. > > The pqueue package does not compile with ghc-7.10. Fixing requires > just some quick changes (i have a working version locally). The last > upload for the package is from 2012, but the author's github account > lowasser shows some more recent activity. Yet I have not received a > reply to my e-mail from six weeks ago. > > Lennart > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hamish.k.mackenzie at gmail.com Mon May 25 14:26:15 2015 From: hamish.k.mackenzie at gmail.com (Hamish Mackenzie) Date: Tue, 26 May 2015 02:26:15 +1200 Subject: [Haskell-cafe] ANN: Leksah 0.15 Message-ID: Hi Everyone, The new leksah package is in Hackage and the installers for Windows and OS X are available for download at: https://github.com/leksah/leksah/wiki/download (remember to choose the one that matches your GHC version) Nw in this release: * Support for GHC 7.10.1. * Uses Gtk+ 3.16 on Windows and OS X. * GtkInspector works on all platforms (Ctrl+Shift+I). * Updated build instructions https://github.com/leksah/leksah (OS X and Windows builds are fairly easy now). * Underlining of doctest failures. * Lots of bug fixes. Things that are new since 0.14.0: * Support for using GHCJS. https://www.youtube.com/watch?v=zQnExdDL63c * GtkInspector https://wiki.gnome.org/Projects/GTK%2B/Inspector. * Web Inspector pane (right click on output pane to bring it up. https://trac.webkit.org/wiki/WebInspector * Cabal commands executed by Leksah show up in the log pane. I remain optimistic about the future of Leksah. GTK+ has improved hugely in the last couple of years. Also WebKitGTK+ and GHCJS mean integrating tools into Leksah will be easier than ever. A great many people contribute (mostly indirectly) to Leksah, it is much appreciated and I hope that number will grow. As always, please help! Hop on #leksah or file and issue at https://github.com/leksah/leksah/issues, even if it is just to vent your displeasure with Leksah (every bug report helps). Here are some fun ideas you might like to try working on if you are looking for a way to contribute to Leksah: * Try using Leksah and fix the thing that annoys you most about it. * Figure out if/how ide-backend can be used in Leksah. * Create an XMonad like manager for
based panes. Ideally it would work for both GTK+ and GHCJS. * Migrate existing UI components from Gtk+ to GHCJS. * Anything GHCJS based and then add support in Leksah for it. * GHCJS based scripting (make it work for Leksah like elisp for Emacs). * Improve Yi integration. What we have is unusably incomplete. * Add GHCJS backend for Yi (replacing the Pango one). * Improve JavaScript based editor support (currently only CodeMirror is supported and not very well). * Add support for using SoH and/or FPView within Leksah. If you are interested in any of these please let me know and I will do what I can to help you get started. Hamish PS. I am kind of sad Eclipse FP has stalled for now and I hope it restarts soon. Integrating Haskell into existing IDEs (especially those with large user bases) will help sell Haskell to the world. I wish JP well and I am sure he will find something interesting and challenging to work on next. From amindfv at gmail.com Wed May 27 00:35:55 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Tue, 26 May 2015 20:35:55 -0400 Subject: [Haskell-cafe] Disambiguating a Num/RealFrac instance Message-ID: Given: data GPA = F Float | Excuse String class ToGPA a where giveGPA :: a -> GPA Is there any way (without IncoherentInstances or Rebindablesyntax) that I can let the user write e.g. "giveGPA 4.0" (and "giveGPA 4") and get back "F 4" without getting type errors that "4.0"'s type is ambiguous? I can guarantee there won't be any additional instances to "ToGPA" (For my uses, I really (actually!) don't want to make the user write e.g. "F 4.0") I've gotten this working, once with IncoherentInstances and once with RebindableSyntax, but both of those flags feel pretty dirty. Thanks, Tom From wasserman.louis at gmail.com Wed May 27 22:44:52 2015 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Wed, 27 May 2015 22:44:52 +0000 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Um. Hi. I don't think I have much bandwidth to devote to maintaining this. I'd prefer to retain author tags, but I'm happy if someone else wants to take over routine maintenance. On Wed, May 27, 2015 at 3:06 PM David Feuer wrote: > Whoever takes over maintenance may want to consider producing unboxed > versions. > > On Wed, May 27, 2015 at 4:01 PM, lennart spitzner > wrote: > > Greetings, > > > > Regarding the pqueue package: > > > > 1) Does anyone have any (additional) contact details for the current > > maintainer/author, Louis Wasserman? > > 2) Is the package's repository available anywhere? The darcs link > > listed in the package 404s. > > 3) I would be willing to take over for basic maintenance if the > > current maintainer is unavailable. > > > > The pqueue package does not compile with ghc-7.10. Fixing requires > > just some quick changes (i have a working version locally). The last > > upload for the package is from 2012, but the author's github account > > lowasser shows some more recent activity. Yet I have not received a > > reply to my e-mail from six weeks ago. > > > > Lennart > > _______________________________________________ > > Haskell-Cafe mailing list > > Haskell-Cafe at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu May 28 17:28:21 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 May 2015 13:28:21 -0400 Subject: [Haskell-cafe] Disambiguating a Num/RealFrac instance In-Reply-To: References: Message-ID: On Tue, May 26, 2015 at 8:35 PM, wrote: > Is there any way (without IncoherentInstances or Rebindablesyntax) that I > can let the user write e.g. "giveGPA 4.0" (and "giveGPA 4") and get back "F > 4" without getting type errors that "4.0"'s type is ambiguous? I can > guarantee there won't be any additional instances to "ToGPA" > A typeclass with only one instance is nonsensical, and often a symptom of trying to use typeclasses as OO classes. All it's doing here is hurting you. In this case, you don't really want to do anything special at all: giveGPA :: Float -> GPA giveGPA f = F f and let Haskell's numeric overloading resolve 4 as (fromInteger 4 :: Float). (Use of the typeclass blocks this.) -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Thu May 28 17:29:50 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Thu, 28 May 2015 19:29:50 +0200 Subject: [Haskell-cafe] Libraries Mailing Problem? In-Reply-To: <672D16CA-FADC-4B98-A9D4-008200D58A94@steinitz.org> References: <672D16CA-FADC-4B98-A9D4-008200D58A94@steinitz.org> Message-ID: The "ending date" is off, but there are messages from today, e.g. https://mail.haskell.org/pipermail/libraries/2015-May/025752.html On Mon, May 25, 2015 at 9:58 PM, Dominic Steinitz wrote: > Is there something wrong with the libraries mailing list? There doesn?t > seem to have been any traffic since 18 May: > https://mail.haskell.org/pipermail/libraries/2015-May/date.html > > Dominic Steinitz > dominic at steinitz.org > http://idontgetoutmuch.wordpress.com > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at bergmark.nl Thu May 28 17:34:08 2015 From: adam at bergmark.nl (Adam Bergmark) Date: Thu, 28 May 2015 19:34:08 +0200 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Thanks for letting us know Louis! Simplest way to proceed is for someone to give you their hackage user name so you can add them to the maintainer group: http://hackage.haskell.org/package/pqueue/maintainers/edit Cheers, Adam On Thu, May 28, 2015 at 12:44 AM, Louis Wasserman wrote: > Um. Hi. > > I don't think I have much bandwidth to devote to maintaining this. I'd > prefer to retain author tags, but I'm happy if someone else wants to take > over routine maintenance. > > On Wed, May 27, 2015 at 3:06 PM David Feuer wrote: > >> Whoever takes over maintenance may want to consider producing unboxed >> versions. >> >> On Wed, May 27, 2015 at 4:01 PM, lennart spitzner >> wrote: >> > Greetings, >> > >> > Regarding the pqueue package: >> > >> > 1) Does anyone have any (additional) contact details for the current >> > maintainer/author, Louis Wasserman? >> > 2) Is the package's repository available anywhere? The darcs link >> > listed in the package 404s. >> > 3) I would be willing to take over for basic maintenance if the >> > current maintainer is unavailable. >> > >> > The pqueue package does not compile with ghc-7.10. Fixing requires >> > just some quick changes (i have a working version locally). The last >> > upload for the package is from 2012, but the author's github account >> > lowasser shows some more recent activity. Yet I have not received a >> > reply to my e-mail from six weeks ago. >> > >> > Lennart >> > _______________________________________________ >> > Haskell-Cafe mailing list >> > Haskell-Cafe at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From alex at slab.org Thu May 28 10:36:40 2015 From: alex at slab.org (alex) Date: Thu, 28 May 2015 11:36:40 +0100 Subject: [Haskell-cafe] International Conference on Live Coding, 13-15 July, Registration open Message-ID: First International Conference on Live Coding ICSRiM, School of Music, University of Leeds 13th-15th July 2015 http://iclc.livecodenetwork.org/ We are happy to announce that registration for ICLC2015 is now open. Live coding turns programming languages into live interfaces, allowing us to directly manipulate computation via its notation. Live coding has great potential, being used for example to create improvised music and visuals, to allow developers to collaborate in new ways, to better understand computational models by making fundamental changes to them on-the-fly, and to find new ways to learn and teach programming. Since the beginning of the TOPLAP movement in 2003 (building on an extensive but hidden pre-history), live coding has grown fast, attracting interest from many people in artistic, creative, scientific, educational, business and mixed contexts. After a good number of international events, the time is right to bring these people together for an academic conference, exchanging ideas and techniques, and enjoying dozens of peer reviewed papers and performances. The conference will also open up the field for people new to live coding, so they may develop and contribute their own perspectives on this emerging field. Join us! Registration is ?80 (?50 concessions) for the three day conference including lunches, evening events, and more. See the website for details of the developing programme: http://iclc.livecodenetwork.org/ And register here, completing both the on-line payment and registration forms: http://iclc.livecodenetwork.org/registration.html ICLC is organised by the Live Coding Research Network, which is funded by the Arts and Humanities Research Council. -- http://yaxu.org/ From wasserman.louis at gmail.com Thu May 28 06:32:23 2015 From: wasserman.louis at gmail.com (Louis Wasserman) Date: Thu, 28 May 2015 06:32:23 +0000 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: No, it's not; I never did put it up on github. On Wed, May 27, 2015 at 11:18 PM Tobias Brandt wrote: > I have an open pull request for this issue since February: > https://github.com/bumptech/haskell-pqueue/pull/2 > > But I don't even know whether this is the official repository. > > On Wed, May 27, 2015 at 10:01 PM lennart spitzner < > lsp at informatik.uni-kiel.de> wrote: > >> Greetings, >> >> Regarding the pqueue package: >> >> 1) Does anyone have any (additional) contact details for the current >> maintainer/author, Louis Wasserman? >> 2) Is the package's repository available anywhere? The darcs link >> listed in the package 404s. >> 3) I would be willing to take over for basic maintenance if the >> current maintainer is unavailable. >> >> The pqueue package does not compile with ghc-7.10. Fixing requires >> just some quick changes (i have a working version locally). The last >> upload for the package is from 2012, but the author's github account >> lowasser shows some more recent activity. Yet I have not received a >> reply to my e-mail from six weeks ago. >> >> Lennart >> > _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From adam at well-typed.com Thu May 28 17:43:49 2015 From: adam at well-typed.com (Adam Gundry) Date: Thu, 28 May 2015 18:43:49 +0100 Subject: [Haskell-cafe] Disambiguating a Num/RealFrac instance In-Reply-To: References: Message-ID: <556753D5.60804@well-typed.com> [Sorry, CCing haskell-cafe rather than ghc-devs!] On 28/05/15 18:28, Brandon Allbery wrote: > On Tue, May 26, 2015 at 8:35 PM, > wrote: > > Is there any way (without IncoherentInstances or Rebindablesyntax) > that I can let the user write e.g. "giveGPA 4.0" (and "giveGPA 4") > and get back "F 4" without getting type errors that "4.0"'s type is > ambiguous? I can guarantee there won't be any additional instances > to "ToGPA" > > > A typeclass with only one instance is nonsensical, and often a symptom > of trying to use typeclasses as OO classes. All it's doing here is > hurting you. Like Brandon, I suspect this probably isn't what you should do. But if you *really* want to do it, this works: {-# LANGUAGE ExtendedDefaultRules, FlexibleInstances #-} default (Float) data GPA = F Float | Excuse String class ToGPA a where giveGPA :: a -> GPA instance ToGPA Float where giveGPA = F instance ToGPA String where giveGPA = Excuse x = giveGPA 4 y = giveGPA 4.0 z = giveGPA "Hello" For more information: https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive-evaluation.html#extended-default-rules Hope this helps, Adam -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From allbery.b at gmail.com Thu May 28 17:48:15 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 May 2015 13:48:15 -0400 Subject: [Haskell-cafe] Libraries Mailing Problem? In-Reply-To: <672D16CA-FADC-4B98-A9D4-008200D58A94@steinitz.org> References: <672D16CA-FADC-4B98-A9D4-008200D58A94@steinitz.org> Message-ID: On Mon, May 25, 2015 at 3:58 PM, Dominic Steinitz wrote: > Is there something wrong with the libraries mailing list? There doesn?t > seem to have been any traffic since 18 May: > https://mail.haskell.org/pipermail/libraries/2015-May/date.html > The mailing lists (all of them hosted on haskell.org) are throwing lots of "temporary error" deferrals for some reason. Chatter on #haskell-infrastructure indicates they're aware of the problem and are trying to figure out what's wrong. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From carter.schonwald at gmail.com Thu May 28 17:58:42 2015 From: carter.schonwald at gmail.com (Carter Schonwald) Date: Thu, 28 May 2015 13:58:42 -0400 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: Louis, do you have that repo Herbert emailed you, or was that a different code base? On Thursday, May 28, 2015, Louis Wasserman wrote: > No, it's not; I never did put it up on github. > > On Wed, May 27, 2015 at 11:18 PM Tobias Brandt > wrote: > >> I have an open pull request for this issue since February: >> https://github.com/bumptech/haskell-pqueue/pull/2 >> >> But I don't even know whether this is the official repository. >> >> On Wed, May 27, 2015 at 10:01 PM lennart spitzner < >> lsp at informatik.uni-kiel.de >> > wrote: >> >>> Greetings, >>> >>> Regarding the pqueue package: >>> >>> 1) Does anyone have any (additional) contact details for the current >>> maintainer/author, Louis Wasserman? >>> 2) Is the package's repository available anywhere? The darcs link >>> listed in the package 404s. >>> 3) I would be willing to take over for basic maintenance if the >>> current maintainer is unavailable. >>> >>> The pqueue package does not compile with ghc-7.10. Fixing requires >>> just some quick changes (i have a working version locally). The last >>> upload for the package is from 2012, but the author's github account >>> lowasser shows some more recent activity. Yet I have not received a >>> reply to my e-mail from six weeks ago. >>> >>> Lennart >>> >> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpmoresmau at gmail.com Thu May 28 18:05:49 2015 From: jpmoresmau at gmail.com (JP Moresmau) Date: Thu, 28 May 2015 20:05:49 +0200 Subject: [Haskell-cafe] Status of Acid-State and IxSet Message-ID: Hello, for a project I decided to use Acid-State and IxSet, and was pretty happy with them. I enjoyed working with Haskell structures for storing and querying data, and my data could fit in memory. However, now I've moved to GHC 7.10, and for example syb-with-class, a dependency of ixset, does not build with template-haskell 2.10. So I'm wondering, are these projects still alive and kicking? Are if I want some memory based storage and indexing, should I look at some other projects (maybe VCache http://hackage.haskell.org/package/vcache). Or is it just bad timing and GHC 7.10 compatible versions of these libraries are in the works? Thanks! -- JP Moresmau http://jpmoresmau.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From redneb8888 at gmail.com Wed May 27 17:40:53 2015 From: redneb8888 at gmail.com (Marios Titas) Date: Wed, 27 May 2015 18:40:53 +0100 Subject: [Haskell-cafe] GHC + musl = easier static linking Message-ID: TL;DR: I made some GHC binaries for linux that rely on musl instead of glibc for easier static linking. Scroll down for the link. Dear *, As most of you know, musl is a linux only C standard library that is optimized for static linking. Statically linked binaries can simplify distribution and deployment. If you have tried to statically link a program with glibc, you will probably know that this does not always work as expected: for example, in many cases the resulting binary will require to be executed in a system that has the exact same version of glibc as the one that was used to compiled it. In essence, static binaries linked with glibc are oftentimes *less* portable than dynamic ones. I decided to see if I could use GHC with musl. The problem was that while I could find some references online, I could not find a precompiled version of GHC that uses musl. So I decided to try and a build one myself. I was able to successfully bootstrap GHC under musl and I am posting it today in case someone else finds it usefull: https://drive.google.com/folderview?id=0B0zktggRQYRkbGJkbmU0UFFSYUE#list I posting this on google drive, I have no better place to host this, hopefully google will not disable my account :-) This is a fully bootstrapped (i.e. stage 2) GHC and *not* a cross compiler. So this will *not* work in a typical glibc based linux distribution. You need a complete musl based environment to use it (see bellow for that). Also, the binaries produced by this GHC will all depend on musl and not work on most glibc based distros. On the other hand, statically compiled binaries should be very portable and will not depend on any particular C standard library. I have done some minimal testing and it seems to work rather well; everything I tried to compile from hackage just worked. Additionally it can compile GHC itself which is always a good test. The size of the resulting static binaries is acceptable. In my 64 bit system, a simple hello world has the following sizes (stripped): 800K glibc dynanic, 1648K glibc static, and 1012K musl static. Why not use a cross-compiler? I have found that in practice it is easier to have a separete environment for producing static binaries. A cross-compiler requires that you also cross-compile all the C libraries that you use. Additionally, cabal has still problems (e.g. [1]) with cross-compiling and will not work out of the box. Note that musl is not 100% compatible with glibc, so some things might work slightly differently. If you do not like using a GHC precompiled by someone else, you can use my binaries to compile GHC under musl yourself; it would be easier than cross-compiling GHC from scratch. So how do you use this? You need a complete musl based environment. There a few musl based distros [2], albeit most of them are geared towards embedded applications. I personally use the experimental musl based gentoo image [3] which feels more like a regular distro. You can use it with chroot, lxc, or systemd-nspawn. For the sake of completeness, I have included at the end of this message some quick and dirty instructions on how to do this. [1] https://github.com/haskell/cabal/issues/1493 [2] http://wiki.musl-libc.org/wiki/Projects_using_musl [3] http://distfiles.gentoo.org/experimental/amd64/musl/ 8<------------------------------------- # gentoo stage3 image instructions CHROOT_PATH=/var/tmp/gentoo-musl cd /var/tmp wget http://distfiles.gentoo.org/experimental/amd64/musl/stage3-amd64-musl-vanilla-20150405.tar.bz2 mkdir "$CHROOT_PATH" tar xjf stage3-amd64-musl-vanilla-20150405.tar.bz2 -C "$CHROOT_PATH" for x in dev proc sys; do mount --bind /$x "$CHROOT_PATH/$x"; done cp -L /etc/resolv.conf "$CHROOT_PATH/etc" chroot "$CHROOT_PATH" /bin/bash -l PS1="(chroot) $PS1" # fetch the gentoo package db for the first time (slow): emerge-webrsync # enable static libraries (*.a), which are disabled by default: sed -ie 's/USE="/USE="static-libs /' /etc/portage/make.conf # reinstall/recompile gmp so that we have its static libs: emerge --oneshot dev-libs/gmp # install ghc: tar xJf /path/to/ghc-7.10.1-x86_64-unknown-linux-musl.tar.xz -C /tmp cd /tmp/ghc-7.10.1; ./configure --prefix=/opt/ghc-7.10.1; make install # compile a hello world: cd /tmp echo 'main = putStrLn "Hello world"' > test.hs /opt/ghc-7.10.1/bin/ghc --make -O -optl-static test.hs ./test file ./test # Of course, using chroot this way is insecure, don't use to install packages from hackage. From felipe.lessa at gmail.com Thu May 28 18:11:52 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 28 May 2015 15:11:52 -0300 Subject: [Haskell-cafe] Consecutive FFI calls In-Reply-To: References: Message-ID: <55675A68.1020003@gmail.com> On 28-05-2015 13:24, David Turner wrote: > If I make a sequence of FFI calls (on a single Haskell thread) but > which end up being called from different OS threads, is there any kind > of ordering guarantee given? More specifically, is there a full memory > barrier at the point where a Haskell thread migrates to a new OS > thread? David, you may want to try the GHC-Users list. Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From allbery.b at gmail.com Thu May 28 18:16:34 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 May 2015 14:16:34 -0400 Subject: [Haskell-cafe] GHC + musl = easier static linking In-Reply-To: References: Message-ID: On Wed, May 27, 2015 at 1:40 PM, Marios Titas wrote: > I posting this on google drive, I have no better place to host this, > hopefully google will not disable my account :-) > github? -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From felipe.lessa at gmail.com Thu May 28 18:17:36 2015 From: felipe.lessa at gmail.com (Felipe Lessa) Date: Thu, 28 May 2015 15:17:36 -0300 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: References: Message-ID: <55675BC0.4040809@gmail.com> Hey, JP! Coincidentally I've recently used acid-state as well. It seems well-maintained and works on GHC 7.10. I can't say much about ixset, though. It looks like the Happstack project is supporting GHC 7.10, perhaps someone forgot about ixset? You could file an issue [2]. [1] https://github.com/Happstack/happstack-server/issues/12 [2] https://github.com/Happstack/ixset Cheers, -- Felipe. -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 819 bytes Desc: OpenPGP digital signature URL: From escherdragon at gmail.com Thu May 28 07:13:50 2015 From: escherdragon at gmail.com (=?UTF-8?B?Sm9zw6kgQS4gUm9tZXJvIEwu?=) Date: Thu, 28 May 2015 09:13:50 +0200 Subject: [Haskell-cafe] no Web-Security component in Haskell? In-Reply-To: <3365849.1UF3EEsXps@x121e> References: <2608800.UApO9Nzphg@x121e> <3365849.1UF3EEsXps@x121e> Message-ID: There's yesod-auth: http://www.yesodweb.com/book/authentication-and-authorization https://hackage.haskell.org/package/yesod-auth Cheers, On Sat, May 23, 2015 at 3:49 PM, Thomas Koch wrote: > // moving the question with more info from haskell-cafe to web-devel > > Hallo, > > I already wrote a message with the same subject to haskell-cafe without > reply. > > I did not found anything comparable to Spring Security[1][2] (Java) or > Symfony > Security[3] (PHP) in Haskell. Both components are used in web applications > to > grant or deny access to resources based on roles, ACLs or custom voters. > > [1] http://projects.spring.io/spring-security > [2] > http://docs.spring.io/autorepo/docs/spring-security/3.1.7.RELEASE/apidocs > [3] > > http://api.symfony.com/master/Symfony/Component/Security/Core/SecurityContext.html > > A naive strategy would be to port the concepts of both components, which > are > very similar, to Haskell. They represent a lot of accumulated knowledge > from > many experts about web security. > > Or are there better ways to do web security in a powerful language like > Haskell? > > There was some unfinished role-based-access-control effort in snap[4] that > has > been removed from git now. > > [4] https://groups.google.com/forum/#!topic/snap_framework/yUgSEVpP2GE > > There seem to be a more modern (and more complex) thing than Role-Based- > Access-Control now, XACML[5] which is used inside Red Hats JBoss[6]. > > [5] http://en.wikipedia.org/wiki/XACML > [6] http://picketlink.org/about > > Regards, Thomas Koch > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Jos? A. Romero L. escherdragon at gmail.com "We who cut mere stones must always be envisioning cathedrals." (Quarry worker's creed) -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeyakovenko at gmail.com Mon May 25 21:14:52 2015 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Mon, 25 May 2015 21:14:52 +0000 Subject: [Haskell-cafe] Any recommendations on how to interact with the running state of a program? Message-ID: I am playing around with some deep learning algorithms and I need a way to periodically read the intermediate result and change some of the system variables. Any ideas on how to best approach this problem? I was thinking of something basic, like having the program periodically read and write from some files. Thanks, Anatoly -------------- next part -------------- An HTML attachment was scrubbed... URL: From blaze at ruddy.ru Wed May 27 20:43:26 2015 From: blaze at ruddy.ru (Andrey Sverdlichenko) Date: Wed, 27 May 2015 13:43:26 -0700 Subject: [Haskell-cafe] Taking over protocol-buffers package In-Reply-To: References: Message-ID: Go ahead, it took almost a year to push my patch to protocol-buffers, active maintainer is definitely needed. On Wed, May 27, 2015 at 7:32 AM, Kostiantyn Rybnikov wrote: > Hi Chris and Cafe! > > I've sent Chris an email couple days ago, this is another one to have > haskell-cafe CCed in order to request maintainership of protocol-buffers > package. > > Stefan Wehr actually tried to contact Chris long time ago, and thus you can > see current "riak" package depends upon protocol-buffers-fork package, > created to add support for GHC 7.8. > > I'd like to incorporate work from protocol-buffers-fork, add support for GHC > 7.10, and also move project to GitHub and add some README with at least > basic tutorial. > > Thanks! Awaiting few weeks now :) > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From corentin.dupont at gmail.com Tue May 26 22:11:04 2015 From: corentin.dupont at gmail.com (Corentin Dupont) Date: Wed, 27 May 2015 00:11:04 +0200 Subject: [Haskell-cafe] ClassyPrelude vs. Haskell.Language.Interpreter In-Reply-To: References: Message-ID: Lazy text is this one? http://hackage.haskell.org/package/text-1.1.0.1/docs/Data-Text-Lazy.html At first sight I'd say it's the way lazy text works with reverse that the interpreter doesn't like... On Tue, May 26, 2015 at 7:47 PM, Mike Meyer wrote: > No answer on -beginners, so I'm trying -cafe. > > I'm trying to run interpreted code via ClassyPrelude, and getting some > results that make me suspect a bug in the Prelude's type system. Or maybe > the interpreter. > > Anyway, here's a bit of code that works as expected: > > {-# LANGUAGE NoImplicitPrelude #-} > > import ClassyPrelude > import Language.Haskell.Interpreter > > main :: IO () > main = do > fun <- runInterpreter $ makeFun "reverse" > case fun of > Left e -> print e > Right f -> readFile "/etc/motd" >>= hPut stdout . f > > > makeFun expr = do > set [languageExtensions := [NoImplicitPrelude]] > setImportsQ [("ClassyPrelude", Nothing)] > interpret expr (as :: Text -> Text) > > > I don't think I can simplify this any further. It works as expected, and > also works as expected, and prints out the contents of /etc/motd reversed. > > However, if you change the type signature in the last line from Text -> > Text to LText -> Ltext (to get lazy text), you get no output. But if you > change the function in the first line after main from "reverse" to "id", it > works. > > So far, it might be an issue with lazy IO. However, change the type > signature in the last line to LText -> Text. In this case, there is no > output for either value of the expression. I expect an error in this case, > as neither id nor reverse should be able to have the type LText -> Text! > > So, is there something I missed in either ClassyPrelude or the > Interpreter? Or is this a subtle interaction, in which case can someone > suggest a workaround? Or have I found a bug in one of the two? > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From redneb8888 at gmail.com Thu May 28 19:23:23 2015 From: redneb8888 at gmail.com (Marios Titas) Date: Thu, 28 May 2015 20:23:23 +0100 Subject: [Haskell-cafe] GHC + musl = easier static linking In-Reply-To: References: Message-ID: On Thu, May 28, 2015 at 7:16 PM, Brandon Allbery wrote: > On Wed, May 27, 2015 at 1:40 PM, Marios Titas wrote: >> >> I posting this on google drive, I have no better place to host this, >> hopefully google will not disable my account :-) > > > github? Does github allow large (70 MiB) binaries? From clintonmead at gmail.com Tue May 26 04:31:15 2015 From: clintonmead at gmail.com (Clinton Mead) Date: Tue, 26 May 2015 14:31:15 +1000 Subject: [Haskell-cafe] (Why) must this function remain nameless? Message-ID: The following code (somewhat contrived) code compiles on GHC without issue, and towards the end repeatedly uses the lambda function "(\fn (D x) -> f fn x)". But when I simply try to give it a name, like so: h = (\fn (D x) -> f fn x) I then get a compile error. How can I name this function, or must it remain forever nameless? ( Ideone link: http://ideone.com/mtuYnK ) --- {-# LANGUAGE TypeFamilies #-} {-# LANGUAGE FlexibleInstances #-} {-# LANGUAGE FlexibleContexts #-} {-# LANGUAGE UndecidableInstances #-} {-# LANGUAGE OverlappingInstances #-} {-# LANGUAGE ScopedTypeVariables #-} {-# LANGUAGE ExistentialQuantification #-} {-# LANGUAGE MultiParamTypeClasses #-} {-# LANGUAGE ConstraintKinds #-} {-# LANGUAGE NoMonomorphismRestriction #-} import GHC.Exts (Constraint) type family Parent a class C a b where f :: b -> a -> String instance (C (Parent a) b) => C a b where f _ _ = f (undefined :: b) (undefined :: Parent a) data A1 = A1 data A2 = A2 data A3 = A3 data A4 = A4 type instance Parent A2 = A1 type instance Parent A3 = A2 type instance Parent A4 = A3 data F1 = F1 data F3 = F3 instance C A1 F1 where f _ _ = "F1" instance C A3 F3 where f _ _ = "F3" type family Constraints t a :: Constraint data D t = forall a. (Constraints t a) => D a type instance Constraints A1 a = (C a F1) type instance Constraints A2 a = (C a F1, C a F3) type instance Constraints A3 a = (C a F1, C a F3) type instance Constraints A4 a = (C a F1, C a F3) main = do putStrLn (f F1 A1) putStrLn (f F1 A2) putStrLn (f F1 A3) putStrLn (f F1 A4) putStrLn (f F3 A3) putStrLn (f F3 A4) putStrLn $ (\fn (D x) -> f fn x) F1 ((D A1) :: D A1) putStrLn $ (\fn (D x) -> f fn x) F1 ((D A2) :: D A1) putStrLn $ (\fn (D x) -> f fn x) F3 ((D A3) :: D A2) -- h = (\fn (D x) -> f fn x) -------------- next part -------------- An HTML attachment was scrubbed... URL: From cma at bitemyapp.com Thu May 28 19:27:36 2015 From: cma at bitemyapp.com (Christopher Allen) Date: Thu, 28 May 2015 14:27:36 -0500 Subject: [Haskell-cafe] GHC + musl = easier static linking In-Reply-To: References: Message-ID: I wouldn't recommend churning a 70mb binary over and over, but a one-off is no problem if they have to download it regardless. I've had many-gigabyte git repos that were perfectly usable. On Thu, May 28, 2015 at 2:23 PM, Marios Titas wrote: > On Thu, May 28, 2015 at 7:16 PM, Brandon Allbery > wrote: > > On Wed, May 27, 2015 at 1:40 PM, Marios Titas > wrote: > >> > >> I posting this on google drive, I have no better place to host this, > >> hopefully google will not disable my account :-) > > > > > > github? > > Does github allow large (70 MiB) binaries? > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From allbery.b at gmail.com Thu May 28 19:29:06 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 May 2015 15:29:06 -0400 Subject: [Haskell-cafe] (Why) must this function remain nameless? In-Reply-To: References: Message-ID: On Tue, May 26, 2015 at 12:31 AM, Clinton Mead wrote: > The following code (somewhat contrived) code compiles on GHC without > issue, and towards the end repeatedly uses the lambda function "(\fn (D x) > -> f fn x)". But when I simply try to give it a name, like so: > > h = (\fn (D x) -> f fn x) > > I then get a compile error. > That's inviting the monomorphism restriction to become involved, as a top level binding without a parameter (the parameter is explicitly part of its value). If that is the issue, writing it as h fn (D x) = f fn x would work better. -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From michael at snoyman.com Thu May 28 19:37:30 2015 From: michael at snoyman.com (Michael Snoyman) Date: Thu, 28 May 2015 19:37:30 +0000 Subject: [Haskell-cafe] GHC + musl = easier static linking In-Reply-To: References: Message-ID: I'd recommend using the release feature on Github. We just started using it for minghc On Thu, May 28, 2015, 10:27 PM Christopher Allen wrote: > I wouldn't recommend churning a 70mb binary over and over, but a one-off > is no problem if they have to download it regardless. > > I've had many-gigabyte git repos that were perfectly usable. > > On Thu, May 28, 2015 at 2:23 PM, Marios Titas > wrote: > >> On Thu, May 28, 2015 at 7:16 PM, Brandon Allbery >> wrote: >> > On Wed, May 27, 2015 at 1:40 PM, Marios Titas >> wrote: >> >> >> >> I posting this on google drive, I have no better place to host this, >> >> hopefully google will not disable my account :-) >> > >> > >> > github? >> >> Does github allow large (70 MiB) binaries? >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From lsp at informatik.uni-kiel.de Thu May 28 20:28:33 2015 From: lsp at informatik.uni-kiel.de (lennart spitzner) Date: Thu, 28 May 2015 22:28:33 +0200 Subject: [Haskell-cafe] pqueue - repository and maintainer (taking over) In-Reply-To: References: <55662287.7000201@informatik.uni-kiel.de> Message-ID: <55677A71.7070408@informatik.uni-kiel.de> On 28/05/15 03:07, Sylvain Henry wrote: > My version of the package since then is here: > https://github.com/hsyl20/pqueue > In addition to making it compile with GHC 7.10, I have replaced all the > tabs with spaces to remove the warnings. I just checked: my changes are almost identical. I use slightly different imports to ensure backwards-compatability (i tested down to ghc-7.2.2) and i removed the Typeable.h warning. @Louis: ah, good to hear you are alive :) From haskell at cdsoft.fr Thu May 28 20:54:38 2015 From: haskell at cdsoft.fr (Christophe Delord) Date: Thu, 28 May 2015 22:54:38 +0200 Subject: [Haskell-cafe] Type inference doesn't always calculate the most generic type? Message-ID: <20150528225438.365c03ae@debian.lan> Hello, I'm new here. Sorry if this question has already been asked. I have noticed something strange about type inference. Prelude> :t abs abs :: Num a => a -> a Prelude> let mapabs = map abs Prelude> :t mapabs mapabs :: [Integer] -> [Integer] Prelude> :t (map abs) (map abs) :: Num b => [b] -> [b] I think that "mapabs" and "map abs" should have the same generic type. In a program I can force the type like this: mapabs = map abs mapabs' :: (Num a) => [a] -> [a] mapabs' = map abs but mapabs still have the type [Integer] -> [Integer] Are there any reason for this? Regards, Christophe Delord. From allbery.b at gmail.com Thu May 28 20:56:08 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 May 2015 16:56:08 -0400 Subject: [Haskell-cafe] Type inference doesn't always calculate the most generic type? In-Reply-To: <20150528225438.365c03ae@debian.lan> References: <20150528225438.365c03ae@debian.lan> Message-ID: On Thu, May 28, 2015 at 4:54 PM, Christophe Delord wrote: > Prelude> let mapabs = map abs This is the monomorphism restriction. https://wiki.haskell.org/Monomorphism_restriction -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From fa-ml at ariis.it Thu May 28 20:54:31 2015 From: fa-ml at ariis.it (Francesco Ariis) Date: Thu, 28 May 2015 22:54:31 +0200 Subject: [Haskell-cafe] Type inference doesn't always calculate the most generic type? In-Reply-To: <20150528225438.365c03ae@debian.lan> References: <20150528225438.365c03ae@debian.lan> Message-ID: <20150528205431.GA7472@casa.casa> On Thu, May 28, 2015 at 10:54:38PM +0200, Christophe Delord wrote: > Hello, > > I'm new here. Sorry if this question has already been asked. > > I have noticed something strange about type inference. > > Prelude> :t abs > abs :: Num a => a -> a > Prelude> let mapabs = map abs > Prelude> :t mapabs > mapabs :: [Integer] -> [Integer] > Prelude> :t (map abs) > (map abs) :: Num b => [b] -> [b] I just fired up ghci: ?> let mapabs = map abs ?> :t mapabs mapabs :: Num b => [b] -> [b] ghc 7.10.1 From allbery.b at gmail.com Thu May 28 21:00:15 2015 From: allbery.b at gmail.com (Brandon Allbery) Date: Thu, 28 May 2015 17:00:15 -0400 Subject: [Haskell-cafe] Type inference doesn't always calculate the most generic type? In-Reply-To: <20150528205431.GA7472@casa.casa> References: <20150528225438.365c03ae@debian.lan> <20150528205431.GA7472@casa.casa> Message-ID: On Thu, May 28, 2015 at 4:54 PM, Francesco Ariis wrote: > I just fired up ghci: > > ?> let mapabs = map abs > ?> :t mapabs > mapabs :: Num b => [b] -> [b] > > ghc 7.10.1 > Sufficiently recent ghc disables the monomorphism restriction inside ghci (only --- compiled code, including code compiled by ghci, as opposed to code entered at the prompt, still uses it). Try ":seti". -- brandon s allbery kf8nh sine nomine associates allbery.b at gmail.com ballbery at sinenomine.net unix, openafs, kerberos, infrastructure, xmonad http://sinenomine.net -------------- next part -------------- An HTML attachment was scrubbed... URL: From tikhon at jelv.is Thu May 28 21:01:50 2015 From: tikhon at jelv.is (Tikhon Jelvis) Date: Thu, 28 May 2015 14:01:50 -0700 Subject: [Haskell-cafe] Type inference doesn't always calculate the most generic type? In-Reply-To: <20150528205431.GA7472@casa.casa> References: <20150528225438.365c03ae@debian.lan> <20150528205431.GA7472@casa.casa> Message-ID: The monomorphism restriction is turned off by default in ghci since version 7.8.1, so you'll see this behavior with newer versions of GHC and the original behavior with older ones. On Thu, May 28, 2015 at 1:54 PM, Francesco Ariis wrote: > On Thu, May 28, 2015 at 10:54:38PM +0200, Christophe Delord wrote: > > Hello, > > > > I'm new here. Sorry if this question has already been asked. > > > > I have noticed something strange about type inference. > > > > Prelude> :t abs > > abs :: Num a => a -> a > > Prelude> let mapabs = map abs > > Prelude> :t mapabs > > mapabs :: [Integer] -> [Integer] > > Prelude> :t (map abs) > > (map abs) :: Num b => [b] -> [b] > > I just fired up ghci: > > ?> let mapabs = map abs > ?> :t mapabs > mapabs :: Num b => [b] -> [b] > > ghc 7.10.1 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From haskell at cdsoft.fr Thu May 28 22:02:04 2015 From: haskell at cdsoft.fr (Christophe Delord) Date: Fri, 29 May 2015 00:02:04 +0200 Subject: [Haskell-cafe] Type inference doesn't always calculate the most generic type? In-Reply-To: References: <20150528225438.365c03ae@debian.lan> <20150528205431.GA7472@casa.casa> Message-ID: <20150529000204.07e6c9ea@debian.lan> Le Thu, 28 May 2015 14:01:50 -0700, Tikhon Jelvis a ?crit : > The monomorphism restriction is turned off by default in ghci since > version 7.8.1, so you'll see this behavior with newer versions of GHC > and the original behavior with older ones. I'm using an old version (7.6.3) on Debian. I'll try to install a newer version. Thank you for all these answers. From aeyakovenko at gmail.com Fri May 29 01:21:24 2015 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Fri, 29 May 2015 01:21:24 +0000 Subject: [Haskell-cafe] Any recommendations on how to interact with the running state of a program? In-Reply-To: References: Message-ID: How would the program get updated values? via an IORef? This thing is running until the user decides the output looks good Anatoly On Thu, May 28, 2015 at 12:16 PM Carlos L?pez-Camey wrote: > Cloud Haskell + Event streaming via some Protocol (like json on > websockets) ? > > > > 2015-05-25 15:14 GMT-06:00 Anatoly Yakovenko : > >> I am playing around with some deep learning algorithms and I need a way >> to periodically read the intermediate result and change some of the system >> variables. >> >> Any ideas on how to best approach this problem? I was thinking of >> something basic, like having the program periodically read and write from >> some files. >> >> Thanks, >> Anatoly >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpdurham at gmail.com Fri May 29 01:32:11 2015 From: cpdurham at gmail.com (Charlie Durham) Date: Thu, 28 May 2015 21:32:11 -0400 Subject: [Haskell-cafe] Any recommendations on how to interact with the running state of a program? In-Reply-To: References: Message-ID: Check out the configurator package: https://hackage.haskell.org/package/configurator It has auto reloading of config files through the aptly named autoReload function. Pretty cool stuff. Charlie On Thu, May 28, 2015 at 9:21 PM, Anatoly Yakovenko wrote: > How would the program get updated values? via an IORef? This thing is > running until the user decides the output looks good > > Anatoly > > On Thu, May 28, 2015 at 12:16 PM Carlos L?pez-Camey > wrote: > >> Cloud Haskell + Event streaming via some Protocol (like json on >> websockets) ? >> >> >> >> 2015-05-25 15:14 GMT-06:00 Anatoly Yakovenko : >> >>> I am playing around with some deep learning algorithms and I need a way >>> to periodically read the intermediate result and change some of the system >>> variables. >>> >>> Any ideas on how to best approach this problem? I was thinking of >>> something basic, like having the program periodically read and write from >>> some files. >>> >>> Thanks, >>> Anatoly >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From aeyakovenko at gmail.com Fri May 29 01:48:16 2015 From: aeyakovenko at gmail.com (Anatoly Yakovenko) Date: Fri, 29 May 2015 01:48:16 +0000 Subject: [Haskell-cafe] Any recommendations on how to interact with the running state of a program? In-Reply-To: References: Message-ID: Cool, thanks. But the ChangeHandler would still be modifying some mutable state that some other thread is referencing while it's running. That would still be via an IORef? I guess this is a similar problem as having a play/pause/skip controls to a video player. Is the interface between the "running" thread and the user triggered events an IORef? Or is there some other way to wrap that. Thanks, Anatoly On Thu, May 28, 2015 at 6:32 PM Charlie Durham wrote: > Check out the configurator package: > https://hackage.haskell.org/package/configurator > > It has auto reloading of config files through the aptly named autoReload > function. Pretty cool stuff. > > Charlie > > On Thu, May 28, 2015 at 9:21 PM, Anatoly Yakovenko > wrote: > >> How would the program get updated values? via an IORef? This thing is >> running until the user decides the output looks good >> >> Anatoly >> >> On Thu, May 28, 2015 at 12:16 PM Carlos L?pez-Camey >> wrote: >> >>> Cloud Haskell + Event streaming via some Protocol (like json on >>> websockets) ? >>> >>> >>> >>> 2015-05-25 15:14 GMT-06:00 Anatoly Yakovenko : >>> >>>> I am playing around with some deep learning algorithms and I need a way >>>> to periodically read the intermediate result and change some of the system >>>> variables. >>>> >>>> Any ideas on how to best approach this problem? I was thinking of >>>> something basic, like having the program periodically read and write from >>>> some files. >>>> >>>> Thanks, >>>> Anatoly >>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cpdurham at gmail.com Fri May 29 02:22:37 2015 From: cpdurham at gmail.com (Charlie Durham) Date: Thu, 28 May 2015 22:22:37 -0400 Subject: [Haskell-cafe] Any recommendations on how to interact with the running state of a program? In-Reply-To: References: Message-ID: I think it entirely depends on how you plan to inject the new values into a running program. If you are doing iterations, then it might make sense to do an IOref that contains the entire space of values that may change and then atomically update the whole space when a config update happens. Or maybe you can put each update in a queue inside of an IORef and then do an atomic modify, or I see there is a package providing lockfree queues in hackage. Again, I think it more depends on how you are going about running your program, and where it makes sense to inject new values. Charlie On Thu, May 28, 2015 at 9:48 PM, Anatoly Yakovenko wrote: > Cool, thanks. > But the ChangeHandler would still be modifying some mutable state that > some other thread is referencing while it's running. That would still be > via an IORef? > I guess this is a similar problem as having a play/pause/skip controls to > a video player. Is the interface between the "running" thread and the user > triggered events an IORef? Or is there some other way to wrap that. > Thanks, > Anatoly > > > On Thu, May 28, 2015 at 6:32 PM Charlie Durham wrote: > >> Check out the configurator package: >> https://hackage.haskell.org/package/configurator >> >> It has auto reloading of config files through the aptly named autoReload >> function. Pretty cool stuff. >> >> Charlie >> >> On Thu, May 28, 2015 at 9:21 PM, Anatoly Yakovenko > > wrote: >> >>> How would the program get updated values? via an IORef? This thing is >>> running until the user decides the output looks good >>> >>> Anatoly >>> >>> On Thu, May 28, 2015 at 12:16 PM Carlos L?pez-Camey >>> wrote: >>> >>>> Cloud Haskell + Event streaming via some Protocol (like json on >>>> websockets) ? >>>> >>>> >>>> >>>> 2015-05-25 15:14 GMT-06:00 Anatoly Yakovenko : >>>> >>>>> I am playing around with some deep learning algorithms and I need a >>>>> way to periodically read the intermediate result and change some of the >>>>> system variables. >>>>> >>>>> Any ideas on how to best approach this problem? I was thinking of >>>>> something basic, like having the program periodically read and write from >>>>> some files. >>>>> >>>>> Thanks, >>>>> Anatoly >>>>> >>>>> _______________________________________________ >>>>> Haskell-Cafe mailing list >>>>> Haskell-Cafe at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>> >>>>> >>>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From briand at aracnet.com Fri May 29 04:18:52 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Thu, 28 May 2015 21:18:52 -0700 Subject: [Haskell-cafe] help with glfw seg-fault In-Reply-To: <2072714A-644D-4A35-A3D8-8065404A5F32@dpwright.com> References: <20150525221931.40d810ff@cedar.deldotd.com> <2072714A-644D-4A35-A3D8-8065404A5F32@dpwright.com> Message-ID: <20150528211852.1b664e10@cedar.deldotd.com> On Tue, 26 May 2015 14:34:16 +0900 "Daniel P. Wright" wrote: > Hi Brian, > > Have you checked for / output any GL errors that happen before you call swapBuffers? I have a function printErrors (as defined here http://dpwright.com/posts/2015/03/25/the-haskell-gl-package/#error-handling-utilities ) which I scatter around when things go wrong to try and find the root cause... > +list glGetErrors is in the openglraw package but not opengl, which is kind of weird. on your web page: GL_NO_ERROR should be gl_NO_ERROR and sadly, i put in the getErrors function and i'm getting the empty list right before it segfaults. Brian From briand at aracnet.com Fri May 29 04:32:30 2015 From: briand at aracnet.com (briand at aracnet.com) Date: Thu, 28 May 2015 21:32:30 -0700 Subject: [Haskell-cafe] help with glfw seg-fault In-Reply-To: <2072714A-644D-4A35-A3D8-8065404A5F32@dpwright.com> References: <20150525221931.40d810ff@cedar.deldotd.com> <2072714A-644D-4A35-A3D8-8065404A5F32@dpwright.com> Message-ID: <20150528213230.2106aea1@cedar.deldotd.com> On Tue, 26 May 2015 14:34:16 +0900 "Daniel P. Wright" wrote: > Hi Brian, > > Have you checked for / output any GL errors that happen before you call swapBuffers? I have a function printErrors (as defined here http://dpwright.com/posts/2015/03/25/the-haskell-gl-package/#error-handling-utilities ) which I scatter around when things go wrong to try and find the root cause... > bug report! m@(~(Just w)) <- createWindow 400 400 "Title" Nothing Nothing when (isNothing m) (error "Couldn't create window!") GLFW.makeContextCurrent m ^^^^^^^^^^^^^^^^^^^^^^^^^ then no seg-faults. Brian From dani at dpwright.com Fri May 29 05:58:16 2015 From: dani at dpwright.com (Daniel P. Wright) Date: Fri, 29 May 2015 14:58:16 +0900 Subject: [Haskell-cafe] help with glfw seg-fault In-Reply-To: <20150528213230.2106aea1@cedar.deldotd.com> References: <20150525221931.40d810ff@cedar.deldotd.com> <2072714A-644D-4A35-A3D8-8065404A5F32@dpwright.com> <20150528213230.2106aea1@cedar.deldotd.com> Message-ID: Ah, yeah, that blog post I linked is using the "gl" package rather than the "OpenGL"/"OpenGLRaw" packages, so some of the names of things are a bit different. Glad you got it sorted in the end! 2015-05-29 13:32 GMT+09:00 : > On Tue, 26 May 2015 14:34:16 +0900 > "Daniel P. Wright" wrote: > > > Hi Brian, > > > > Have you checked for / output any GL errors that happen before you call > swapBuffers? I have a function printErrors (as defined here > http://dpwright.com/posts/2015/03/25/the-haskell-gl-package/#error-handling-utilities > ) which I scatter around when things go wrong to try and find the root > cause... > > > > bug report! > > > m@(~(Just w)) <- createWindow 400 400 "Title" Nothing Nothing > when (isNothing m) (error "Couldn't create window!") > > GLFW.makeContextCurrent m > ^^^^^^^^^^^^^^^^^^^^^^^^^ > > then no seg-faults. > > Brian > -------------- next part -------------- An HTML attachment was scrubbed... URL: From codygman.consulting at gmail.com Fri May 29 07:49:25 2015 From: codygman.consulting at gmail.com (Cody Goodman) Date: Fri, 29 May 2015 02:49:25 -0500 Subject: [Haskell-cafe] Anyone using Tidal/emacs like emacs-live/overtone? Message-ID: Does anyone have a working setup where you enter Haskell code from the tidal library and use a keybinding to execute that statement (or multiple)? Basically wanting to try livecoding Tidal code like all the overtone videos: https://vimeo.com/22798433 From ben at smart-cactus.org Fri May 29 08:37:10 2015 From: ben at smart-cactus.org (Ben Gamari) Date: Fri, 29 May 2015 10:37:10 +0200 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: References: Message-ID: <87h9qv6aq1.fsf@smart-cactus.org> JP Moresmau writes: > Hello, for a project I decided to use Acid-State and IxSet, and was pretty > happy with them. I enjoyed working with Haskell structures for storing and > querying data, and my data could fit in memory. However, now I've moved to > GHC 7.10, and for example syb-with-class, a dependency of ixset, does not > build with template-haskell 2.10. So I'm wondering, are these projects > still alive and kicking? Are if I want some memory based storage and > indexing, should I look at some other projects (maybe VCache > http://hackage.haskell.org/package/vcache). Or is it just bad timing and > GHC 7.10 compatible versions of these libraries are in the works? > Indeed it seems like syb-with-class is a bit stagnant. For what it's worth I've moved the source to a Git repository [1] along with fixes allowing it to compile on GHC 7.10 (although with a slight loss of sharing which may or may not be recovered by the optimizer). sanzhiyan or Simon, do you think you could have a look at these changes and push them to Hackage if you find them acceptable? I would also be happy to take over maintenance if that is preferred. Cheers, - Ben [1] https://github.com/bgamari/syb-with-class -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 472 bytes Desc: not available URL: From j.cretel at umail.ucc.ie Fri May 29 08:46:19 2015 From: j.cretel at umail.ucc.ie (Julien Cretel) Date: Fri, 29 May 2015 10:46:19 +0200 Subject: [Haskell-cafe] Haskell wiki: user account Message-ID: Hi there, I'd like to get a user account for the Haskell wiki. Desired username: Jubobs Cheers -- Julien Cretel PhD student University College Cork, Ireland Email: j.cretel at umail.ucc.ie From adam at well-typed.com Fri May 29 08:53:23 2015 From: adam at well-typed.com (Adam Gundry) Date: Fri, 29 May 2015 09:53:23 +0100 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: References: Message-ID: <55682903.10103@well-typed.com> Hi, On 28/05/15 19:05, JP Moresmau wrote: > Hello, for a project I decided to use Acid-State and IxSet, and was > pretty happy with them. I enjoyed working with Haskell structures for > storing and querying data, and my data could fit in memory. However, now > I've moved to GHC 7.10, and for example syb-with-class, a dependency of > ixset, does not build with template-haskell 2.10. So I'm wondering, are > these projects still alive and kicking? Are if I want some memory based > storage and indexing, should I look at some other projects (maybe > VCache http://hackage.haskell.org/package/vcache). Or is it just bad > timing and GHC 7.10 compatible versions of these libraries are in the works? Another alternative to ixset is ixset-typed [1], by my colleague Andres. It has an API rather like ixset, but with much stronger type-level guarantees, and it is fairly easy to port code from one to the other. Moreover, it doesn't depend on syb-with-class. Hope this helps, Adam [1] https://hackage.haskell.org/package/ixset-typed https://github.com/well-typed/ixset-typed -- Adam Gundry, Haskell Consultant Well-Typed LLP, http://www.well-typed.com/ From hsyl20 at gmail.com Fri May 29 09:03:53 2015 From: hsyl20 at gmail.com (Sylvain Henry) Date: Fri, 29 May 2015 11:03:53 +0200 Subject: [Haskell-cafe] Any recommendations on how to interact with the running state of a program? In-Reply-To: References: Message-ID: I would use STM to do that (i.e. put the system variables and the intermediate result in some TVars). Sylvain 2015-05-29 4:22 GMT+02:00 Charlie Durham : > I think it entirely depends on how you plan to inject the new values into > a running program. If you are doing iterations, then it might make sense to > do an IOref that contains the entire space of values that may change and > then atomically update the whole space when a config update happens. Or > maybe you can put each update in a queue inside of an IORef and then do an > atomic modify, or I see there is a package providing lockfree queues in > hackage. Again, I think it more depends on how you are going about running > your program, and where it makes sense to inject new values. > > Charlie > > On Thu, May 28, 2015 at 9:48 PM, Anatoly Yakovenko > wrote: > >> Cool, thanks. >> But the ChangeHandler would still be modifying some mutable state that >> some other thread is referencing while it's running. That would still be >> via an IORef? >> I guess this is a similar problem as having a play/pause/skip controls to >> a video player. Is the interface between the "running" thread and the user >> triggered events an IORef? Or is there some other way to wrap that. >> Thanks, >> Anatoly >> >> >> On Thu, May 28, 2015 at 6:32 PM Charlie Durham >> wrote: >> >>> Check out the configurator package: >>> https://hackage.haskell.org/package/configurator >>> >>> It has auto reloading of config files through the aptly named autoReload >>> function. Pretty cool stuff. >>> >>> Charlie >>> >>> On Thu, May 28, 2015 at 9:21 PM, Anatoly Yakovenko < >>> aeyakovenko at gmail.com> wrote: >>> >>>> How would the program get updated values? via an IORef? This thing is >>>> running until the user decides the output looks good >>>> >>>> Anatoly >>>> >>>> On Thu, May 28, 2015 at 12:16 PM Carlos L?pez-Camey >>>> wrote: >>>> >>>>> Cloud Haskell + Event streaming via some Protocol (like json on >>>>> websockets) ? >>>>> >>>>> >>>>> >>>>> 2015-05-25 15:14 GMT-06:00 Anatoly Yakovenko : >>>>> >>>>>> I am playing around with some deep learning algorithms and I need a >>>>>> way to periodically read the intermediate result and change some of the >>>>>> system variables. >>>>>> >>>>>> Any ideas on how to best approach this problem? I was thinking of >>>>>> something basic, like having the program periodically read and write from >>>>>> some files. >>>>>> >>>>>> Thanks, >>>>>> Anatoly >>>>>> >>>>>> _______________________________________________ >>>>>> Haskell-Cafe mailing list >>>>>> Haskell-Cafe at haskell.org >>>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>>>> >>>>>> >>>>> >>>> _______________________________________________ >>>> Haskell-Cafe mailing list >>>> Haskell-Cafe at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>>> >>>> >>> > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From jpmoresmau at gmail.com Fri May 29 10:50:59 2015 From: jpmoresmau at gmail.com (JP Moresmau) Date: Fri, 29 May 2015 12:50:59 +0200 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: <55682903.10103@well-typed.com> References: <55682903.10103@well-typed.com> Message-ID: Thank you all!! It looks I need to look into ixset-typed but that there is hope to get ixset and its dependencies in good order! JP On Fri, May 29, 2015 at 10:53 AM, Adam Gundry wrote: > Hi, > > On 28/05/15 19:05, JP Moresmau wrote: > > Hello, for a project I decided to use Acid-State and IxSet, and was > > pretty happy with them. I enjoyed working with Haskell structures for > > storing and querying data, and my data could fit in memory. However, now > > I've moved to GHC 7.10, and for example syb-with-class, a dependency of > > ixset, does not build with template-haskell 2.10. So I'm wondering, are > > these projects still alive and kicking? Are if I want some memory based > > storage and indexing, should I look at some other projects (maybe > > VCache http://hackage.haskell.org/package/vcache). Or is it just bad > > timing and GHC 7.10 compatible versions of these libraries are in the > works? > > Another alternative to ixset is ixset-typed [1], by my colleague Andres. > It has an API rather like ixset, but with much stronger type-level > guarantees, and it is fairly easy to port code from one to the other. > Moreover, it doesn't depend on syb-with-class. > > Hope this helps, > > Adam > > [1] https://hackage.haskell.org/package/ixset-typed > https://github.com/well-typed/ixset-typed > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ > -- JP Moresmau http://jpmoresmau.blogspot.com/ -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri May 29 14:50:27 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 29 May 2015 10:50:27 -0400 Subject: [Haskell-cafe] -fdefer-more-errors In-Reply-To: <20150528132652.GF30857@weber> References: <20150528082658.GB30857@weber> <20150528132652.GF30857@weber> Message-ID: <6FC6575A-86F2-41C1-A470-EE4034644D28@cis.upenn.edu> The request for -fdefer-name-errors is indeed in #5910, but very much buried under other stuff. If you want this, make a new feature request, referencing #5910. Of course, even better would be a full specification (on a wiki page) and a patch! I expect the challenge here is coming up with a nice design more so than a nice implementation. Thanks! Richard On May 28, 2015, at 9:26 AM, Tom Ellis wrote: > On Thu, May 28, 2015 at 09:26:58AM +0100, Tom Ellis wrote: >> Does anyone think it would also be beneficial to have "-fdefer-name-errors"? > [...] > > Via hamishmack on Haskell Reddit[1] there's already a Trac issue about > this[2]. > > [1] http://www.reddit.com/r/haskell/comments/37km7e/fdeferscopeerrors_anyone/crnkdgq > [2] https://ghc.haskell.org/trac/ghc/ticket/5910#comment:19 > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From nicholls.mark at vimn.com Fri May 29 15:47:45 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Fri, 29 May 2015 15:47:45 +0000 Subject: [Haskell-cafe] recursive datakinds Message-ID: Hello, If I were trying to do something like creating types like.... > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > data MyList a where > MyEnd :: MyList '[] > MyCons :: a -> MyList b -> MyList (a ': b) > mysimplelist :: MyList '[Integer] > mysimplelist = MyCons 1 (MyEnd) what about > myrecursivelist = MyCons 1 myrecursivelist Cafe2.lhs:23:30: Occurs check: cannot construct the infinite type: b ~ a : b Expected type: MyList b Actual type: MyList (a : b) Relevant bindings include myrecursivelist :: MyList (a : b) (bound at Cafe2.lhs:23:3) In the second argument of 'MyCons', namely 'myrecursivelist' In the expression: MyCons 1 myrecursivelist can I "fix" this somehow? I obviously want the type of myrecursivelist to be MyList '[Integer, Integer, Integer, Integer, Integer, Integer, Integer, Integer,.....] Something like a completely nonsensical... MyList (Fix (Integer ': )) P.S. Yes, I barely understand "fix" as a function, let alone a data type. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri May 29 16:01:04 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 29 May 2015 12:01:04 -0400 Subject: [Haskell-cafe] recursive datakinds In-Reply-To: References: Message-ID: <477EB664-593E-4157-AE09-ABD1647D06E2@cis.upenn.edu> GHC stubbornly refuses to allow infinite types, although I don't know of a good theoretical reason why. (From a practical standpoint, with infinite types, GHC would be very likely to hang, though that could be avoided with enough engineering, I think.) Your best bet here is, in my view, not to use promoted [] to index your list type, but instead something like > data List a = Cons a (List a) | Tail [a] where the Tail constructor marks a (possibly-empty) infinitely-repeating tail of a list. Instead of the infinite (repeat Integer) list, you would just have Tail [Integer], which is much better behaved. I haven't tried to build an indexed list from such a beast, though... Richard On May 29, 2015, at 11:47 AM, "Nicholls, Mark" wrote: > Hello, > > If I were trying to do something like creating types like?. > > > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE ExplicitForAll #-} > > {-# LANGUAGE FlexibleContexts #-} > > {-# LANGUAGE FlexibleInstances #-} > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE PolyKinds #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE UndecidableInstances #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > data MyList a where > > MyEnd :: MyList '[] > > MyCons :: a -> MyList b -> MyList (a ': b) > > > mysimplelist :: MyList '[Integer] > > mysimplelist = MyCons 1 (MyEnd) > > what about > > > myrecursivelist = MyCons 1 myrecursivelist > > Cafe2.lhs:23:30: > Occurs check: cannot construct the infinite type: b ~ a : b > Expected type: MyList b > Actual type: MyList (a : b) > Relevant bindings include > myrecursivelist :: MyList (a : b) (bound at Cafe2.lhs:23:3) > In the second argument of ?MyCons?, namely ?myrecursivelist? > In the expression: MyCons 1 myrecursivelist > > can I ?fix? this somehow? > > I obviously want the type of myrecursivelist to be > MyList ?[Integer, Integer, Integer, Integer, Integer, Integer, Integer, Integer,?..] > > Something like a completely nonsensical? > > MyList (Fix (Integer ?: )) > > P.S. > > Yes, I barely understand ?fix? as a function, let alone a data type. > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -------------- next part -------------- An HTML attachment was scrubbed... URL: From nicholls.mark at vimn.com Fri May 29 16:19:15 2015 From: nicholls.mark at vimn.com (Nicholls, Mark) Date: Fri, 29 May 2015 16:19:15 +0000 Subject: [Haskell-cafe] recursive datakinds In-Reply-To: <477EB664-593E-4157-AE09-ABD1647D06E2@cis.upenn.edu> References: <477EB664-593E-4157-AE09-ABD1647D06E2@cis.upenn.edu> Message-ID: My actual use case is a bit more complex than just a repeating [Integer, Integer, Integer, Integer, Integer,...] And in fact the recursion is not even repeated segments of a list...hmmm....or is it?.....not sure....lets say it isnt...for the moment. At the moment it feels more like a recursive Tree type... a nice unrecursive one would be mytree :: MyTree 'Branch '[ 'Leaf Integer, 'Branch '[ 'Leaf String, 'Leaf Bool ] ] mytree = .... Obviously we can construct recursive trees with recursive functions...that leads to recursive types...and BOOOM I'm not sure I understand your example though....or if it helps in the above example....its all "a"s...I need a's and b's. I know OF "fix"....and how we can use it to stratify (?) recursive structures....so...the question is whether we can "Fix" the above somehow. There is I believe a "Fix" type....which makes my head hurt even more. From: Richard Eisenberg [mailto:eir at cis.upenn.edu] Sent: 29 May 2015 5:01 PM To: Nicholls, Mark Cc: haskell-cafe at haskell.org Subject: Re: [Haskell-cafe] recursive datakinds GHC stubbornly refuses to allow infinite types, although I don't know of a good theoretical reason why. (From a practical standpoint, with infinite types, GHC would be very likely to hang, though that could be avoided with enough engineering, I think.) Your best bet here is, in my view, not to use promoted [] to index your list type, but instead something like > data List a = Cons a (List a) | Tail [a] where the Tail constructor marks a (possibly-empty) infinitely-repeating tail of a list. Instead of the infinite (repeat Integer) list, you would just have Tail [Integer], which is much better behaved. I haven't tried to build an indexed list from such a beast, though... Richard On May 29, 2015, at 11:47 AM, "Nicholls, Mark" > wrote: Hello, If I were trying to do something like creating types like.... > {-# LANGUAGE DataKinds #-} > {-# LANGUAGE ExplicitForAll #-} > {-# LANGUAGE FlexibleContexts #-} > {-# LANGUAGE FlexibleInstances #-} > {-# LANGUAGE GADTs #-} > {-# LANGUAGE MultiParamTypeClasses #-} > {-# LANGUAGE PolyKinds #-} > {-# LANGUAGE StandaloneDeriving #-} > {-# LANGUAGE TypeFamilies #-} > {-# LANGUAGE TypeOperators #-} > {-# LANGUAGE UndecidableInstances #-} > {-# LANGUAGE ScopedTypeVariables #-} > data MyList a where > MyEnd :: MyList '[] > MyCons :: a -> MyList b -> MyList (a ': b) > mysimplelist :: MyList '[Integer] > mysimplelist = MyCons 1 (MyEnd) what about > myrecursivelist = MyCons 1 myrecursivelist Cafe2.lhs:23:30: Occurs check: cannot construct the infinite type: b ~ a : b Expected type: MyList b Actual type: MyList (a : b) Relevant bindings include myrecursivelist :: MyList (a : b) (bound at Cafe2.lhs:23:3) In the second argument of 'MyCons', namely 'myrecursivelist' In the expression: MyCons 1 myrecursivelist can I "fix" this somehow? I obviously want the type of myrecursivelist to be MyList '[Integer, Integer, Integer, Integer, Integer, Integer, Integer, Integer,.....] Something like a completely nonsensical... MyList (Fix (Integer ': )) P.S. Yes, I barely understand "fix" as a function, let alone a data type. CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe CONFIDENTIALITY NOTICE This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. -------------- next part -------------- An HTML attachment was scrubbed... URL: From ky3 at atamo.com Fri May 29 16:40:58 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Fri, 29 May 2015 23:40:58 +0700 Subject: [Haskell-cafe] Haskell Weekly News Message-ID: *Top Picks:* - Tony Day, Brisbane-based investment strategist and high-frequency-trading hacker, rides 100% idiomatic Haskell into the Single Page (web)-App space. How? He spins the GHCJS transpiler on Gabriel Gonzalez's Model-View-Controller library to obtain his own TodoMVC benchmark demo . Per GHCJS, the production spans multi-megabytes of javascript. Not to be missed: auto-run, i.e. click the QuickCheck-powered checkbox labeled "Let haskell do the work." Github repo . Along the way, he discovers how crippled Javascript is without sum types. As noted on HN , "Typos and missing cases represent a very large set of trivial bugs." He believes superior FP features such as sum types makes it "much harder for haskell to avoid success." Woe is us. /r/haskell - Michael Walker, a Ph.D. student at York, reveals his personal book-collection management web-app that runs on top of persistent , WAI , and web-routes . Public domain. - David Christiansen announces on /r/haskell Idris 0.9.18 with fancier records. Top comment says Idris is more type-friendly than Haskell despite the "esoteric academics behind dependent type theory." Why? Because Idris, helpfully offers suggestions that turn ill- into well-typed code. Haskell doesn't. - Remember JP Moresmau dropping EclipseFP ? Can Leksah take its place? Hamish Mackenzie announces a 7.10-ready Leksah 0.15.0 on /r/haskell . Top new feature? Support for GHCJS, which excites Phil Freeman of PureScript fame. Here's a 2min video clip on How to make a ghcjs-dom application in Leksah . - Roman Cheplyaka writes a short 'n sweet tutorial on how a list may be variously forced. He summarizes the similarities and differences in a table that goes from the shallowestly evaluated seq () to forceSpine to forceElements to the deepest rnf. /r/haskell - Justin Leitgeb, Rails developer and Co-Founder / CTO of Stack Builders, a Haskell-enabled software consultancy, deprioritizes learning Clojure, Go, Erlang, and Scala in favor of Agda, Coq, Idris, Elm, and Liquid Haskell . He will invest a couple of weeks at the Oregon PL Summer School starting June 15 . - Tony Morris announces a three-day Haskell-based Intro to FP course in Melbourne, July 21-23 this year. Pitched at beginners, it features learning by coding. Free; application deadline: July 10 . - By popular request , Franti?ek Farka and his team recorded all of a workshop on type inference in Dundee, Scotland held a couple of weeks ago. Highly-viewed talks include Edwin Brady on implementing dependent types in Idris and Conor McBride on "Type Inference Needs Revolution." /r/haskell - Michael Hicks at UMD, PC chair of POPL 2012, writes a PL research apologia cum pitch for new grad students. An informal poll he did shows PL Ph.D.s get good jobs. He explains that "The ethos of PL research is to not just find solutions to important problems, but to find the *best expression of those solutions.*" As ethos specimens, he gives three: probabilistic programming, incremental computation a.k.a. self-adaptive computation, and authenticated data structures (see LambdaAuth ). HN-worthy . - Jan Stolarek gives a glimpse of GHC's new injective type families feature, which is joint research with SPJ and Richard Eisenberg. It brings Haskell one step closer to having a notion of type functions as opposed to mere 'constructors.' The feature is useful in type-level hacking. It allows the arguments of a type family to be inferred solely by result type. But Lennart Augustsson on /r/haskell gives a trivial example where even when a type family isn't injective, its argument can still be inferred knowing a particular result type. He regrets that GHC doesn't do this. - Joe Nelson uploads the video and a summary of Kristen Kozak introducing the Safe Haskell extension to the SF Bay Area Haskell Users Group on May 12. Slides here . Redditor beerdude26 adds the link to and tidies up the Safe Haskell wiki entry. - Out of frustration with existing Windows GUI FFIs, Luka Horvat creates bindings for WinForms , Microsoft's .NET menus-and-widgets library. He binds to F# instead of lower-level C++/C# because it's easier. /r/haskell - Gabriel Gonzalez demoes another piece of Morte, what he describes as his "pandoc for programming languages." He prototypes "distributing typed code over the internet where the unit of compilation is individual expressions." /r/haskell - Taylor Fausak forsakes TagSoup and scrapes websites the hard way using xml-conduit. He concludes that it's "tougher than doing the same thing in scripting languages, but hopefully easier than [his blog readers] expected." - Stuart Popejoy writes a monad tutorial . A redditor finds it an "entertaining explanation of monads." Another asks the OOP-ish question: are monads "basically wrappers that contain 'impure' data and actions with some common functions?" See /r/haskell *Announcement:* Semen Trygubenko has stepped down from publishing his edition of HWN. Losing him means there will be no issue next week. *Quotes of the Week:* - UnoOuzo : "The type of my love is parametrically polymorphic. It is unbounded." Looking into ways to cite this in my thesis. - Conor McBride : Algebra is a posh way of saying "construction kit". - Michael Hicks : The ethos of PL research is to not just find solutions to important problems, but to find the *best expression of those solutions. * - There is a fountain of youth: it is your mind, your talents, the creativity you bring to your life and the lives of people you love. When you learn to tap this source, you will truly have defeated age. -- Sophia Loren -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From jeremy at n-heptane.com Fri May 29 16:52:43 2015 From: jeremy at n-heptane.com (Jeremy Shaw) Date: Fri, 29 May 2015 11:52:43 -0500 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: References: Message-ID: Hello, acid-state is still alive and kicking (and better be since hackage uses it). In fact, there is a GSoC project to add replication support this summer I believe. ixset is still supported. We submitted a patch upstream to syb-with-class but have not heard back. Our patched version is here: https://github.com/seereason/syb-with-class Nix patches syb-with-class by default -- which is nice ;) If you do not have legacy code to support, I highly recommend checking out ixset-typed. It is very much like ixset -- but does a better job catching errors though the type system. IxSet is a little too loose with the types for no real reason resulting in avoidable runtime errors. - jeremy On Thu, May 28, 2015 at 1:05 PM, JP Moresmau wrote: > Hello, for a project I decided to use Acid-State and IxSet, and was pretty > happy with them. I enjoyed working with Haskell structures for storing and > querying data, and my data could fit in memory. However, now I've moved to > GHC 7.10, and for example syb-with-class, a dependency of ixset, does not > build with template-haskell 2.10. So I'm wondering, are these projects > still alive and kicking? Are if I want some memory based storage and > indexing, should I look at some other projects (maybe VCache > http://hackage.haskell.org/package/vcache). Or is it just bad timing and > GHC 7.10 compatible versions of these libraries are in the works? > > Thanks! > > -- > JP Moresmau > http://jpmoresmau.blogspot.com/ > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > -------------- next part -------------- An HTML attachment was scrubbed... URL: From eir at cis.upenn.edu Fri May 29 18:23:58 2015 From: eir at cis.upenn.edu (Richard Eisenberg) Date: Fri, 29 May 2015 14:23:58 -0400 Subject: [Haskell-cafe] recursive datakinds In-Reply-To: References: <477EB664-593E-4157-AE09-ABD1647D06E2@cis.upenn.edu> Message-ID: <6735CD59-CF80-4C6D-B4B9-9DB123E6F57E@cis.upenn.edu> There is a Fix datatype: > data Fix f = Fix (f (Fix f)) The problem is that it isn't promotable, because only datatypes whose parameters are all of kind * are promotable. Wait until 7.12, though, and that should promote. :) Richard On May 29, 2015, at 12:19 PM, "Nicholls, Mark" wrote: > My actual use case is a bit more complex than just a repeating [Integer, Integer, Integer, Integer, Integer,?] > > And in fact the recursion is not even repeated segments of a list?hmmm?.or is it?.....not sure?.lets say it isnt?for the moment. > > At the moment it feels more like a recursive Tree type... a nice unrecursive one would be > > mytree :: MyTree ?Branch ?[ ?Leaf Integer, ?Branch ?[ ?Leaf String, ?Leaf Bool ] ] > mytree = ?. > > Obviously we can construct recursive trees with recursive functions?that leads to recursive types?and BOOOM > > I?m not sure I understand your example though?.or if it helps in the above example?.its all ?a?s?I need a?s and b?s. > > I know OF ?fix??.and how we can use it to stratify (?) recursive structures?.so?the question is whether we can ?Fix? the above somehow. > > There is I believe a ?Fix? type?.which makes my head hurt even more. > > > From: Richard Eisenberg [mailto:eir at cis.upenn.edu] > Sent: 29 May 2015 5:01 PM > To: Nicholls, Mark > Cc: haskell-cafe at haskell.org > Subject: Re: [Haskell-cafe] recursive datakinds > > GHC stubbornly refuses to allow infinite types, although I don't know of a good theoretical reason why. (From a practical standpoint, with infinite types, GHC would be very likely to hang, though that could be avoided with enough engineering, I think.) Your best bet here is, in my view, not to use promoted [] to index your list type, but instead something like > > > data List a = Cons a (List a) | Tail [a] > > where the Tail constructor marks a (possibly-empty) infinitely-repeating tail of a list. Instead of the infinite (repeat Integer) list, you would just have Tail [Integer], which is much better behaved. I haven't tried to build an indexed list from such a beast, though... > > Richard > > On May 29, 2015, at 11:47 AM, "Nicholls, Mark" wrote: > > > Hello, > > If I were trying to do something like creating types like?. > > > > {-# LANGUAGE DataKinds #-} > > {-# LANGUAGE ExplicitForAll #-} > > {-# LANGUAGE FlexibleContexts #-} > > {-# LANGUAGE FlexibleInstances #-} > > {-# LANGUAGE GADTs #-} > > {-# LANGUAGE MultiParamTypeClasses #-} > > {-# LANGUAGE PolyKinds #-} > > {-# LANGUAGE StandaloneDeriving #-} > > {-# LANGUAGE TypeFamilies #-} > > {-# LANGUAGE TypeOperators #-} > > {-# LANGUAGE UndecidableInstances #-} > > {-# LANGUAGE ScopedTypeVariables #-} > > > data MyList a where > > MyEnd :: MyList '[] > > MyCons :: a -> MyList b -> MyList (a ': b) > > > mysimplelist :: MyList '[Integer] > > mysimplelist = MyCons 1 (MyEnd) > > what about > > > myrecursivelist = MyCons 1 myrecursivelist > > Cafe2.lhs:23:30: > Occurs check: cannot construct the infinite type: b ~ a : b > Expected type: MyList b > Actual type: MyList (a : b) > Relevant bindings include > myrecursivelist :: MyList (a : b) (bound at Cafe2.lhs:23:3) > In the second argument of ?MyCons?, namely ?myrecursivelist? > In the expression: MyCons 1 myrecursivelist > > can I ?fix? this somehow? > > I obviously want the type of myrecursivelist to be > MyList ?[Integer, Integer, Integer, Integer, Integer, Integer, Integer, Integer,?..] > > Something like a completely nonsensical? > > MyList (Fix (Integer ?: )) > > P.S. > > Yes, I barely understand ?fix? as a function, let alone a data type. > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > > > > CONFIDENTIALITY NOTICE > > This e-mail (and any attached files) is confidential and protected by copyright (and other intellectual property rights). If you are not the intended recipient please e-mail the sender and then delete the email and any attached files immediately. Any further use or dissemination is prohibited. > > While MTV Networks Europe has taken steps to ensure that this email and any attachments are virus free, it is your responsibility to ensure that this message and any attachments are virus free and do not affect your systems / data. > > Communicating by email is not 100% secure and carries risks such as delay, data corruption, non-delivery, wrongful interception and unauthorised amendment. If you communicate with us by e-mail, you acknowledge and assume these risks, and you agree to take appropriate measures to minimise these risks when e-mailing us. > > MTV Networks International, MTV Networks UK & Ireland, Greenhouse, Nickelodeon Viacom Consumer Products, VBSi, Viacom Brand Solutions International, Be Viacom, Viacom International Media Networks and VIMN and Comedy Central are all trading names of MTV Networks Europe. MTV Networks Europe is a partnership between MTV Networks Europe Inc. and Viacom Networks Europe Inc. Address for service in Great Britain is 17-29 Hawley Crescent, London, NW1 8TT. > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sanzhiyan at gmail.com Fri May 29 20:08:37 2015 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Fri, 29 May 2015 22:08:37 +0200 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: References: Message-ID: On Fri, May 29, 2015 at 6:52 PM, Jeremy Shaw wrote: > Hello, > > acid-state is still alive and kicking (and better be since hackage uses it). > In fact, there is a GSoC project to add replication support this summer I > believe. > > ixset is still supported. We submitted a patch upstream to syb-with-class > but have not heard back. Our patched version is here: Where is this upstream? Since I haven't seen any patches my way until today I guess there's some other place where I'm not checking. Anyhow there's a new version on hackage now which builds on ghc-7.10. I would gladly transfer maintainership of syb-with-class though. Cheers, Andrea > > https://github.com/seereason/syb-with-class > > Nix patches syb-with-class by default -- which is nice ;) > > If you do not have legacy code to support, I highly recommend checking out > ixset-typed. It is very much like ixset -- but does a better job catching > errors though the type system. IxSet is a little too loose with the types > for no real reason resulting in avoidable runtime errors. > > - jeremy > > On Thu, May 28, 2015 at 1:05 PM, JP Moresmau wrote: >> >> Hello, for a project I decided to use Acid-State and IxSet, and was pretty >> happy with them. I enjoyed working with Haskell structures for storing and >> querying data, and my data could fit in memory. However, now I've moved to >> GHC 7.10, and for example syb-with-class, a dependency of ixset, does not >> build with template-haskell 2.10. So I'm wondering, are these projects still >> alive and kicking? Are if I want some memory based storage and indexing, >> should I look at some other projects (maybe VCache >> http://hackage.haskell.org/package/vcache). Or is it just bad timing and GHC >> 7.10 compatible versions of these libraries are in the works? >> >> Thanks! >> >> -- >> JP Moresmau >> http://jpmoresmau.blogspot.com/ >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > From sanzhiyan at gmail.com Fri May 29 20:17:18 2015 From: sanzhiyan at gmail.com (Andrea Vezzosi) Date: Fri, 29 May 2015 22:17:18 +0200 Subject: [Haskell-cafe] Status of Acid-State and IxSet In-Reply-To: References: Message-ID: Oh, sorry, your mail was from today as well, so github was the upstream, it's been a while since I've been on -cafe and thought this was an older thread. All the best, Andrea On Fri, May 29, 2015 at 10:08 PM, Andrea Vezzosi wrote: > On Fri, May 29, 2015 at 6:52 PM, Jeremy Shaw wrote: >> Hello, >> >> acid-state is still alive and kicking (and better be since hackage uses it). >> In fact, there is a GSoC project to add replication support this summer I >> believe. >> >> ixset is still supported. We submitted a patch upstream to syb-with-class >> but have not heard back. Our patched version is here: > > Where is this upstream? Since I haven't seen any patches my way until > today I guess there's some other place where I'm not checking. > > Anyhow there's a new version on hackage now which builds on ghc-7.10. > > I would gladly transfer maintainership of syb-with-class though. > > Cheers, > Andrea > >> >> https://github.com/seereason/syb-with-class >> >> Nix patches syb-with-class by default -- which is nice ;) >> >> If you do not have legacy code to support, I highly recommend checking out >> ixset-typed. It is very much like ixset -- but does a better job catching >> errors though the type system. IxSet is a little too loose with the types >> for no real reason resulting in avoidable runtime errors. >> >> - jeremy >> >> On Thu, May 28, 2015 at 1:05 PM, JP Moresmau wrote: >>> >>> Hello, for a project I decided to use Acid-State and IxSet, and was pretty >>> happy with them. I enjoyed working with Haskell structures for storing and >>> querying data, and my data could fit in memory. However, now I've moved to >>> GHC 7.10, and for example syb-with-class, a dependency of ixset, does not >>> build with template-haskell 2.10. So I'm wondering, are these projects still >>> alive and kicking? Are if I want some memory based storage and indexing, >>> should I look at some other projects (maybe VCache >>> http://hackage.haskell.org/package/vcache). Or is it just bad timing and GHC >>> 7.10 compatible versions of these libraries are in the works? >>> >>> Thanks! >>> >>> -- >>> JP Moresmau >>> http://jpmoresmau.blogspot.com/ >>> >>> _______________________________________________ >>> Haskell-Cafe mailing list >>> Haskell-Cafe at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >>> >> >> >> _______________________________________________ >> Haskell-Cafe mailing list >> Haskell-Cafe at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe >> From mihai.maruseac at gmail.com Fri May 29 20:41:56 2015 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Fri, 29 May 2015 16:41:56 -0400 Subject: [Haskell-cafe] ANNOUNCE: Haskell Communities and Activities Report (28th ed., May 2015) Message-ID: On behalf of all the contributors, we are pleased to announce that the Haskell Communities and Activities Report (28th edition, May 2014) is now available, in PDF and HTML formats: http://haskell.org/communities/05-2015/report.pdf http://haskell.org/communities/05-2015/html/report.html Many thanks go to all the people that contributed to this report, both directly, by sending in descriptions, and indirectly, by doing all the interesting things that are reported. We hope you will find it as interesting a read as we did. If you have not encountered the Haskell Communities and Activities Reports before, you may like to know that the first of these reports was published in November 2001. Their goal is to improve the communication between the increasingly diverse groups, projects, and individuals working on, with, or inspired by Haskell. The idea behind these reports is simple: Every six months, a call goes out to all of you enjoying Haskell to contribute brief summaries of your own area of work. Many of you respond (eagerly, unprompted, and sometimes in time for the actual deadline) to the call. The editors collect all the contributions into a single report and feed that back to the community. When we try for the next update, six months from now, you might want to report on your own work, project, research area or group as well. So, please put the following into your diaries now: ======================================== End of September 2015: target deadline for contributions to the November 2015 edition of the HC&A Report ======================================== Unfortunately, many Haskellers working on interesting projects are so busy with their work that they seem to have lost the time to follow the Haskell related mailing lists and newsgroups, and have trouble even finding time to report on their work. If you are a member, user or friend of a project so burdened, please find someone willing to make time to report and ask them to "register" with the editors for a simple e-mail reminder in October (you could point us to them as well, and we can then politely ask if they want to contribute, but it might work better if you do the initial asking). Of course, they will still have to find the ten to fifteen minutes to draw up their report, but maybe we can increase our coverage of all that is going on in the community. Feel free to circulate this announcement further in order to reach people who might otherwise not see it. Enjoy! Mihai Maruseac and Alejandro Serrano Mena -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya -------------- next part -------------- An HTML attachment was scrubbed... URL: From mwm at mired.org Fri May 29 21:25:07 2015 From: mwm at mired.org (Mike Meyer) Date: Fri, 29 May 2015 16:25:07 -0500 Subject: [Haskell-cafe] Annoucing Eddie 1.0.0 Message-ID: Eddie is a tool to let you use Haskell code in shell scripts, in a manner similar to the way awk and other scripting languages can be used. The jump to 1.0.0 isn't because it's finished, but because this is a rewrite from the ground up to incorporate more modern Haskell features (the old version was my first non-trivial Haskell program), resulting in changes to various behaviors as well as some option tweaks. Most notably, it no longer uses [Char] for everything. In text mode, it uses Text, with options to specify both input and output encodings. In binary mode, it uses ByteString, with an option to set the output back to Text so you can generate summaries as opposed to simply filter. To make using Text and ByteString sane, it also uses ClassyPrelude instead of Prelude + Data.Char & Data.List so your Haskell list habits work - at least mostly. See CHANGES.md in the source or ChangeLog in the wiki for detailed changes. Otherwise, the manual page is available on the web site. -------------- next part -------------- An HTML attachment was scrubbed... URL: From redneb8888 at gmail.com Fri May 29 22:46:15 2015 From: redneb8888 at gmail.com (Marios Titas) Date: Fri, 29 May 2015 23:46:15 +0100 Subject: [Haskell-cafe] GHC + musl = easier static linking In-Reply-To: References: Message-ID: I posted some notes about GHC on musl here: https://github.com/redneb/ghc-alt-libc. I also posted there some notes and a download link of a (mostly working) port of GHC to uClibc. On Wed, May 27, 2015 at 6:40 PM, Marios Titas wrote: > TL;DR: I made some GHC binaries for linux that rely on musl instead of > glibc for easier static linking. Scroll down for the link. > > Dear *, > > As most of you know, musl is a linux only C standard library that is > optimized for static linking. Statically linked binaries can simplify > distribution and deployment. If you have tried to statically link a > program with glibc, you will probably know that this does not always > work as expected: for example, in many cases the resulting binary will > require to be executed in a system that has the exact same version of > glibc as the one that was used to compiled it. In essence, static > binaries linked with glibc are oftentimes *less* portable than dynamic > ones. > > I decided to see if I could use GHC with musl. The problem was that > while I could find some references online, I could not find a > precompiled version of GHC that uses musl. So I decided to try and a > build one myself. I was able to successfully bootstrap GHC under musl > and I am posting it today in case someone else finds it usefull: > > https://drive.google.com/folderview?id=0B0zktggRQYRkbGJkbmU0UFFSYUE#list > > I posting this on google drive, I have no better place to host this, > hopefully google will not disable my account :-) > This is a fully bootstrapped (i.e. stage 2) GHC and *not* a cross > compiler. So this will *not* work in a typical glibc based linux > distribution. You need a complete musl based environment to use it > (see bellow for that). Also, the binaries produced by this GHC will > all depend on musl and not work on most glibc based distros. On the > other hand, statically compiled binaries should be very portable and > will not depend on any particular C standard library. I have done some > minimal testing and it seems to work rather well; everything I tried > to compile from hackage just worked. Additionally it can compile GHC > itself which is always a good test. The size of the resulting static > binaries is acceptable. In my 64 bit system, a simple hello world has > the following sizes (stripped): 800K glibc dynanic, 1648K glibc > static, and 1012K musl static. > > Why not use a cross-compiler? I have found that in practice it is > easier to have a separete environment for producing static binaries. A > cross-compiler requires that you also cross-compile all the C > libraries that you use. Additionally, cabal has still problems (e.g. > [1]) with cross-compiling and will not work out of the box. > > Note that musl is not 100% compatible with glibc, so some things might > work slightly differently. > > If you do not like using a GHC precompiled by someone else, you can > use my binaries to compile GHC under musl yourself; it would be easier > than cross-compiling GHC from scratch. > > So how do you use this? You need a complete musl based environment. > There a few musl based distros [2], albeit most of them are geared > towards embedded applications. I personally use the experimental musl > based gentoo image [3] which feels more like a regular distro. You can > use it with chroot, lxc, or systemd-nspawn. For the sake of > completeness, I have included at the end of this message some quick > and dirty instructions on how to do this. > > [1] https://github.com/haskell/cabal/issues/1493 > [2] http://wiki.musl-libc.org/wiki/Projects_using_musl > [3] http://distfiles.gentoo.org/experimental/amd64/musl/ > > 8<------------------------------------- > > # gentoo stage3 image instructions > > CHROOT_PATH=/var/tmp/gentoo-musl > cd /var/tmp > wget http://distfiles.gentoo.org/experimental/amd64/musl/stage3-amd64-musl-vanilla-20150405.tar.bz2 > mkdir "$CHROOT_PATH" > tar xjf stage3-amd64-musl-vanilla-20150405.tar.bz2 -C "$CHROOT_PATH" > for x in dev proc sys; do mount --bind /$x "$CHROOT_PATH/$x"; done > cp -L /etc/resolv.conf "$CHROOT_PATH/etc" > chroot "$CHROOT_PATH" /bin/bash -l > PS1="(chroot) $PS1" > # fetch the gentoo package db for the first time (slow): > emerge-webrsync > # enable static libraries (*.a), which are disabled by default: > sed -ie 's/USE="/USE="static-libs /' /etc/portage/make.conf > # reinstall/recompile gmp so that we have its static libs: > emerge --oneshot dev-libs/gmp > # install ghc: > tar xJf /path/to/ghc-7.10.1-x86_64-unknown-linux-musl.tar.xz -C /tmp > cd /tmp/ghc-7.10.1; ./configure --prefix=/opt/ghc-7.10.1; make install > # compile a hello world: > cd /tmp > echo 'main = putStrLn "Hello world"' > test.hs > /opt/ghc-7.10.1/bin/ghc --make -O -optl-static test.hs > ./test > file ./test > > # Of course, using chroot this way is insecure, don't use to install > packages from hackage. From amindfv at gmail.com Sat May 30 01:39:34 2015 From: amindfv at gmail.com (amindfv at gmail.com) Date: Fri, 29 May 2015 21:39:34 -0400 Subject: [Haskell-cafe] Disambiguating a Num/RealFrac instance In-Reply-To: <556753D5.60804@well-typed.com> References: <556753D5.60804@well-typed.com> Message-ID: <12E43DD1-CCAC-42E8-B452-D5176CFF9761@gmail.com> Oh apologies -- it looks like my contrived example was a little too contrived. I'm actually using a MPTC, so the type would be more like: class ToGPA a b where toGPA :: a -> GPA ExtendedDefaultRules doesn't work with MPTCs it seems. Tom El May 28, 2015, a las 13:43, Adam Gundry escribi?: > [Sorry, CCing haskell-cafe rather than ghc-devs!] > > On 28/05/15 18:28, Brandon Allbery wrote: >> On Tue, May 26, 2015 at 8:35 PM, > > wrote: >> >> Is there any way (without IncoherentInstances or Rebindablesyntax) >> that I can let the user write e.g. "giveGPA 4.0" (and "giveGPA 4") >> and get back "F 4" without getting type errors that "4.0"'s type is >> ambiguous? I can guarantee there won't be any additional instances >> to "ToGPA" >> >> >> A typeclass with only one instance is nonsensical, and often a symptom >> of trying to use typeclasses as OO classes. All it's doing here is >> hurting you. > > Like Brandon, I suspect this probably isn't what you should do. But if > you *really* want to do it, this works: > > {-# LANGUAGE ExtendedDefaultRules, FlexibleInstances #-} > > default (Float) > > data GPA = F Float | Excuse String > > class ToGPA a where > giveGPA :: a -> GPA > > instance ToGPA Float where > giveGPA = F > > instance ToGPA String where > giveGPA = Excuse > > x = giveGPA 4 > y = giveGPA 4.0 > z = giveGPA "Hello" > > For more information: > https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/interactive-evaluation.html#extended-default-rules > > Hope this helps, > > Adam > > > -- > Adam Gundry, Haskell Consultant > Well-Typed LLP, http://www.well-typed.com/ From takenobu.hs at gmail.com Sat May 30 03:10:57 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 30 May 2015 12:10:57 +0900 Subject: [Haskell-cafe] Consecutive FFI calls In-Reply-To: References: Message-ID: Hi David, I'm not 100% sure, especially semantics, and I'm studying too. I don't have an answer, but I describe the related matters in order to organize my head. At first: "memory barrier" ... is order control mechanism between memory accesses. "bound thread" ... is association mechanism between ffi calls and a specified thread. And: "memory barrier" ... is depend on cpu hardware architecture(x86, ARM, ...). "OS level thread" ... is depend on OS(Linux, Windows, ...). Last: There are four cases about ffi call [1]: (1) safe ffi call on unbound thread(forkIO) (2) unsafe ffi call on unbound thread(forkIO) (3) safe ffi call on bound thread(main, forkOS) (4) unsafe ffi call on bound thread(main, forkOS) I think, maybe (2) and (4) have not guarantee with memory ordering. Because they might be inlined and optimized. If (1) and (3) always use pthread api (or memory barrier api) for thread/HEC context switch, they are guarantee. But I think that it would not guarantee the full case. I feel that order issues are very difficult. I think order issues can be safely solved by explicit notation, like explicit memory barrier notation, STM,... If I have misunderstood, please teach me :-) [1]: http://takenobu-hs.github.io/downloads/haskell_ghc_illustrated.pdf#page=98 Cheers, Takenobu 2015-05-29 1:24 GMT+09:00 David Turner : > Hi, > > If I make a sequence of FFI calls (on a single Haskell thread) but > which end up being called from different OS threads, is there any kind > of ordering guarantee given? More specifically, is there a full memory > barrier at the point where a Haskell thread migrates to a new OS > thread? > > Many thanks, > > David > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From takenobu.hs at gmail.com Sat May 30 03:13:28 2015 From: takenobu.hs at gmail.com (Takenobu Tani) Date: Sat, 30 May 2015 12:13:28 +0900 Subject: [Haskell-cafe] Threads and critical sections (threadWaitRead) In-Reply-To: <555F193D.1010809@lars-petersen.net> References: <555F193D.1010809@lars-petersen.net> Message-ID: Hi Lars, uh, order issues are difficult for me. Although this is not the answer, I write a little. At first: "critical section" ... is block that should protect the invariants. "atomic block" ... is undivided code block. Your point (1) and (2) are "critical section" for mfd and fd, but not "atomic block". readMVar can't create "atomic block". It's only read the content of MVar. Of cource, as you have said. If point (1) have no memory allocations, async exception and timer-based thread context switch don't occur there. But you might think many other case, such as implement dependent. If you want to protect the critical section exactly, it is better to use an explicit mechanism rather than implicit mechanism. Libraries on hackage[1] might be helpful. For performance pursuit, there may be a gimmick way;-) [1]: https://hackage.haskell.org/ Cheers, Takenobu 2015-05-22 20:55 GMT+09:00 Lars Petersen : > Hello cafe, > > I'm currently trying to understand Haskell's threading model and GHC's > implementation of it. Specifically I wondered about the safety of file > IO. Consider this piece of code: > > > newtype Socket = Socket (MVar Fd) > > > > read :: Socket -> IO ByteString > > read (Socket mfd) = do > > fd <- readMVar mfd > > -- (1) > > threadWaitRead fd > > -- (2) > > withMVar mfd $ \fd'-> do > > -- (3) the actual read... > > Context: > - The socket is configured non-blocking. > - No other operation will hold the MVar over a blocking call (because > this would make it impossible to close it while it's blocking). > - My close operation will fill the MVar with -1 after it's closed and > will hold the MVar during the close operation. > > Questions: > - Is it theoretically possible that my thread gets paused at (1) or > within threadWaitRead, another thread closes the socket (or even worse > opens another file with the same fd) _and_ my thread is resumed > afterwards (I'm not asking about async exceptions)? > - What constructs contain safepoints and which are guaranteed to be > executed without interruption? > > Considerations (so far): > - It is unlikely that (1) is a safepoint as no memory allocations > occur, but is it guaranteed? > - If the socket were closed during (1), threadWaitRead throws an > exception complaining about a bad file descriptor which is unexpected > but not harmful. > - I found this thread > ( > https://mail.haskell.org/pipermail/haskell-cafe/2014-September/115841.html > ) > which is somewhat related, but I couldn't extract a clear answer from it. > > Best, > Lars > > > > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -------------- next part -------------- An HTML attachment was scrubbed... URL: From holdenlee at alum.mit.edu Sat May 30 05:24:23 2015 From: holdenlee at alum.mit.edu (Holden Lee) Date: Sat, 30 May 2015 01:24:23 -0400 Subject: [Haskell-cafe] Why is vector sort slower than list sort? Message-ID: >From places like http://programmers.stackexchange.com/questions/180417/fastest-haskell-library-sort-implementation and http://stackoverflow.com/questions/3655329/how-does-one-sort-with-data-vector-generic-mutable I'm led to believe that sorting mutable vectors is faster than sorting lists. However, when running on my own computer, I'm seeing the opposite effect. What's wrong with what I'm doing, or am I misunderstanding something? What's the fastest way to sort? Here's the code: Sort0.hs (List version) import Control.Monad import System.Random import qualified Data.Vector as IV import qualified Data.Vector.Mutable as MV import qualified Data.Vector.Generic as V import qualified Data.Vector.Algorithms.Intro as VA import qualified Data.List as L randList :: IO [Int] randList = sequence $ replicate 1000000 (randomIO :: IO Int) main = do v <- randList print $ L.sort v Here's Sort1.hs import Control.Monad import System.Random import qualified Data.Vector as IV import qualified Data.Vector.Mutable as MV import qualified Data.Vector.Generic as V import qualified Data.Vector.Algorithms.Intro as VA randVector :: IO (MV.IOVector Int) randVector = do v <- MV.new 1000000 forM [0..999999] $ \x -> do r <- randomIO :: IO Int MV.write v x r return v main = do v <- randVector VA.sort v iv <- V.unsafeFreeze v :: IO (IV.Vector Int) print . V.toList $ iv I'm compiling and running as follows: ghc -prof -fprof-auto -rtsopts -o Sort0 Sort0.hs ./Sort0 +RTS -p -sstderr -K99999999 -RTS Here are the traces; the first one is Sort0.hs (list version) and takes ~11s while the other takes ~17s: Sat May 30 05:06 2015 Time and Allocation Profiling Report (Final) Sort0.exe +RTS -p -sstderr -K99999999 -RTS total time = *11.43 secs* (11434 ticks @ 1000 us, 1 processor) total alloc = 1,966,669,596 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc main Main 61.4 49.4 randList Main 38.6 50.6 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 41 0 0.0 0.0 100.0 100.0 CAF GHC.IO.Encoding.CodePage 69 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Encoding 67 0 0.0 0.0 0.0 0.0 CAF System.CPUTime 59 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Handle.FD 58 0 0.0 0.0 0.0 0.0 CAF Data.Fixed 54 0 0.0 0.0 0.0 0.0 CAF Data.Time.Clock.POSIX 50 0 0.0 0.0 0.0 0.0 CAF System.Random 49 0 0.0 0.0 0.0 0.0 CAF Main 48 0 0.0 0.0 100.0 100.0 randList Main 83 1 1.7 3.1 1.7 3.1 main Main 82 1 61.4 49.4 98.3 96.9 randList Main 84 0 36.9 47.6 36.9 47.6 Sat May 30 04:59 2015 Time and Allocation Profiling Report (Final) Sort1.exe +RTS -p -sstderr -K99999999 -RTS total time = * 17.07 secs* (17066 ticks @ 1000 us, 1 processor) total alloc = 5,783,472,528 bytes (excludes profiling overheads) COST CENTRE MODULE %time %alloc main Main 71.9 81.5 randVector.\ Main 25.0 16.5 randVector Main 3.1 2.0 individual inherited COST CENTRE MODULE no. entries %time %alloc %time %alloc MAIN MAIN 60 0 0.0 0.0 100.0 100.0 CAF GHC.IO.Encoding.CodePage 108 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Encoding 106 0 0.0 0.0 0.0 0.0 CAF System.CPUTime 98 0 0.0 0.0 0.0 0.0 CAF GHC.IO.Handle.FD 95 0 0.0 0.0 0.0 0.0 CAF Data.Fixed 87 0 0.0 0.0 0.0 0.0 CAF Data.Time.Clock.POSIX 82 0 0.0 0.0 0.0 0.0 CAF System.Random 81 0 0.0 0.0 0.0 0.0 CAF Main 67 0 0.0 0.0 100.0 100.0 randVector Main 121 1 0.0 0.0 0.0 0.0 main Main 120 1 71.9 81.5 100.0 100.0 randVector Main 122 0 3.1 2.0 28.1 18.5 randVector.\ Main 123 1000000 25.0 16.5 25.0 16.5 Thanks, Holden -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat May 30 09:39:17 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 30 May 2015 11:39:17 +0200 Subject: [Haskell-cafe] .a files not found Message-ID: L.S., I get messages about .a files not being found, when I try to install package data-default-instances-base, data-default-instances-containers, data-default-instances-dlist or data-default-instances-old-locale. How can I solve this? I am using GHC 7.10.1 on Windows. Sample output: C:\X\data-default-instances-old-locale-0.0.1> cabal install Resolving dependencies... Configuring data-default-instances-old-locale-0.0.1... Building data-default-instances-old-locale-0.0.1... Failed to install data-default-instances-old-locale-0.0.1 Build log ( C:\Users\X\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log ): Building data-default-instances-old-locale-0.0.1... Preprocessing library data-default-instances-old-locale-0.0.1... [1 of 1] Compiling Data.Default.Instances.OldLocale ( Data\Default\Instances\OldLocale.hs, dist\build\Data\Default\Instances\OldLocale.o ) C:\Programs\Haskell\MinGHC-7.10.1\ghc-7.10.1\mingw\bin\ar.exe: dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-2192\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: No such file or directory cabal: Error: some packages failed to install: data-default-instances-old-locale-0.0.1 failed during the building phase. The exception was: ExitFailure 1 Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From vagarenko at gmail.com Sat May 30 11:44:57 2015 From: vagarenko at gmail.com (Alexey Vagarenko) Date: Sat, 30 May 2015 04:44:57 -0700 (PDT) Subject: [Haskell-cafe] .a files not found In-Reply-To: References: Message-ID: Hello, See https://github.com/haskell/cabal/issues/2502 -------------- next part -------------- An HTML attachment was scrubbed... URL: From toby at paccrat.org Sat May 30 11:46:00 2015 From: toby at paccrat.org (Toby Goodwin) Date: 30 May 2015 11:46:00 -0000 Subject: [Haskell-cafe] Why is vector sort slower than list sort? In-Reply-To: References: Message-ID: <1432986360.763.lithium.flare.email@hydrogen.mpv6.com> >I'm led to believe that sorting mutable vectors is faster than sorting >lists. For one thing, you should use "-O2" when looking at performance. For another, you're not actually looking at the sort in isolation. If you pull it out to the top-level (e.g. "doSort = L.sort") so you can see it in the profiling, then even without -O2 I see the vector sort is faster. (Arguably you should include the cost of freezing the vector too.) Regards, Toby. From ky3 at atamo.com Sat May 30 14:10:59 2015 From: ky3 at atamo.com (Kim-Ee Yeoh) Date: Sat, 30 May 2015 21:10:59 +0700 Subject: [Haskell-cafe] .a files not found In-Reply-To: References: Message-ID: On Sat, May 30, 2015 at 4:39 PM, Henk-Jan van Tuyl wrote: > How can I solve this? I am using GHC 7.10.1 on Windows. > Hi Henk-Jan, Could you confirm the workaround, i.e. setting TEMP and TMP to something short like c:\temp, makes the problem go away for you too? Ganesh contributed that workaround in the link that Alexey gave. -- Kim-Ee -------------- next part -------------- An HTML attachment was scrubbed... URL: From hjgtuyl at chello.nl Sat May 30 14:15:50 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 30 May 2015 16:15:50 +0200 Subject: [Haskell-cafe] .a files not found In-Reply-To: References: Message-ID: On Sat, 30 May 2015 16:10:59 +0200, Kim-Ee Yeoh wrote: > Hi Henk-Jan, > > Could you confirm the workaround, i.e. setting TEMP and TMP to something > short like c:\temp, makes the problem go away for you too? > > Ganesh contributed that workaround in the link that Alexey gave. I tried it; the problem is still there. Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From matej.borovec at yahoo.com Sat May 30 16:45:00 2015 From: matej.borovec at yahoo.com (Matej Borovec) Date: Sat, 30 May 2015 18:45:00 +0200 Subject: [Haskell-cafe] .a files not found In-Reply-To: References: Message-ID: Try this for every package: mkdir c:\temp cd c:\temp cabal unpack data-default-instances-base cabal install ./data-default-instances-base -----Original Message----- From: Henk-Jan van Tuyl Sent: Saturday, May 30, 2015 11:39 AM To: haskell-cafe at haskell.org Subject: [Haskell-cafe] .a files not found L.S., I get messages about .a files not being found, when I try to install package data-default-instances-base, data-default-instances-containers, data-default-instances-dlist or data-default-instances-old-locale. How can I solve this? I am using GHC 7.10.1 on Windows. Sample output: C:\X\data-default-instances-old-locale-0.0.1> cabal install Resolving dependencies... Configuring data-default-instances-old-locale-0.0.1... Building data-default-instances-old-locale-0.0.1... Failed to install data-default-instances-old-locale-0.0.1 Build log ( C:\Users\X\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log ): Building data-default-instances-old-locale-0.0.1... Preprocessing library data-default-instances-old-locale-0.0.1... [1 of 1] Compiling Data.Default.Instances.OldLocale ( Data\Default\Instances\OldLocale.hs, dist\build\Data\Default\Instances\OldLocale.o ) C:\Programs\Haskell\MinGHC-7.10.1\ghc-7.10.1\mingw\bin\ar.exe: dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-2192\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: No such file or directory cabal: Error: some packages failed to install: data-default-instances-old-locale-0.0.1 failed during the building phase. The exception was: ExitFailure 1 Regards, Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From hjgtuyl at chello.nl Sat May 30 17:04:18 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 30 May 2015 19:04:18 +0200 Subject: [Haskell-cafe] .a files not found In-Reply-To: References: Message-ID: That works! Thanks, Henk-Jan van Tuyl On Sat, 30 May 2015 18:45:00 +0200, Matej Borovec wrote: > Try this for every package: > > mkdir c:\temp > cd c:\temp > cabal unpack data-default-instances-base > cabal install ./data-default-instances-base > > > -----Original Message----- From: Henk-Jan van Tuyl > Sent: Saturday, May 30, 2015 11:39 AM > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] .a files not found > > > L.S., > > I get messages about .a files not being found, when I try to install > package data-default-instances-base, data-default-instances-containers, > data-default-instances-dlist or data-default-instances-old-locale. How > can > I solve this? I am using GHC 7.10.1 on Windows. > > Sample output: > > C:\X\data-default-instances-old-locale-0.0.1> cabal install > Resolving dependencies... > Configuring data-default-instances-old-locale-0.0.1... > Building data-default-instances-old-locale-0.0.1... > Failed to install data-default-instances-old-locale-0.0.1 > Build log ( > C:\Users\X\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log > ): > Building data-default-instances-old-locale-0.0.1... > Preprocessing library data-default-instances-old-locale-0.0.1... > [1 of 1] Compiling Data.Default.Instances.OldLocale ( > Data\Default\Instances\OldLocale.hs, > dist\build\Data\Default\Instances\OldLocale.o ) > C:\Programs\Haskell\MinGHC-7.10.1\ghc-7.10.1\mingw\bin\ar.exe: > dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-2192\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: > No such file or directory > cabal: Error: some packages failed to install: > data-default-instances-old-locale-0.0.1 failed during the building phase. > The > exception was: > ExitFailure 1 > > > Regards, > Henk-Jan van Tuyl > > -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From mantkiew at gsd.uwaterloo.ca Sat May 30 17:18:22 2015 From: mantkiew at gsd.uwaterloo.ca (mantkiew at gsd.uwaterloo.ca) Date: Sat, 30 May 2015 13:18:22 -0400 Subject: [Haskell-cafe] .a files not found In-Reply-To: References: Message-ID: <20150530171822.5296206.51377.8528@gsd.uwaterloo.ca> The location is not that ?important. In any folder where cabal install fails, I can do cabal get + cabal install and it works. So it's probably related to cabal's own temp folder names which get too long. Michal ? Original Message ? From: Henk-Jan van Tuyl Sent: Saturday, May 30, 2015 1:04 PM To: haskell-cafe at haskell.org; Matej Borovec Subject: Re: [Haskell-cafe] .a files not found That works! Thanks, Henk-Jan van Tuyl On Sat, 30 May 2015 18:45:00 +0200, Matej Borovec wrote: > Try this for every package: > > mkdir c:\temp > cd c:\temp > cabal unpack data-default-instances-base > cabal install ./data-default-instances-base > > > -----Original Message----- From: Henk-Jan van Tuyl > Sent: Saturday, May 30, 2015 11:39 AM > To: haskell-cafe at haskell.org > Subject: [Haskell-cafe] .a files not found > > > L.S., > > I get messages about .a files not being found, when I try to install > package data-default-instances-base, data-default-instances-containers, > data-default-instances-dlist or data-default-instances-old-locale. How > can > I solve this? I am using GHC 7.10.1 on Windows. > > Sample output: > > C:\X\data-default-instances-old-locale-0.0.1> cabal install > Resolving dependencies... > Configuring data-default-instances-old-locale-0.0.1... > Building data-default-instances-old-locale-0.0.1... > Failed to install data-default-instances-old-locale-0.0.1 > Build log ( > C:\Users\X\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log > ): > Building data-default-instances-old-locale-0.0.1... > Preprocessing library data-default-instances-old-locale-0.0.1... > [1 of 1] Compiling Data.Default.Instances.OldLocale ( > Data\Default\Instances\OldLocale.hs, > dist\build\Data\Default\Instances\OldLocale.o ) > C:\Programs\Haskell\MinGHC-7.10.1\ghc-7.10.1\mingw\bin\ar.exe: > dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-2192\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: > No such file or directory > cabal: Error: some packages failed to install: > data-default-instances-old-locale-0.0.1 failed during the building phase. > The > exception was: > ExitFailure 1 > > > Regards, > Henk-Jan van Tuyl > > -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- _______________________________________________ Haskell-Cafe mailing list Haskell-Cafe at haskell.org http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe From bertram.felgenhauer at googlemail.com Sat May 30 21:18:13 2015 From: bertram.felgenhauer at googlemail.com (Bertram Felgenhauer) Date: Sat, 30 May 2015 23:18:13 +0200 Subject: [Haskell-cafe] foldt fix proposal (HaskellWiki) In-Reply-To: References: Message-ID: <20150530211813.GF12752@24f89f8c-e6a1-4e75-85ee-bb8a3743bb9f> Dear Michael, > I think I've found a mistake in foldt > implementation on the Fold page[1] of the > HaskellWiki. > > foldt :: (a -> a -> a) -> a -> [a] -> a > foldt f z [] = z > foldt f z [x] = x -- mistake? > -- foldt f z [x] = f x z -- fix proposal > foldt f z xs = foldt f z (pairs f xs) > > pairs :: (a -> a -> a) -> [a] -> [a] > pairs f (x:y:t) = f x y : pairs f t > pairs f t = t In the context of the text on the fold page, I believe you're right, since it describes z as an "initial value". Nevertheless I like the definition on the wiki. Let me explain by starting with what is, to my mind, the fundamental tree folding function, which works with an associative function left and non-empty lists: foldt f [x] = x foldt f xs = foldt f (pair f xs) It has the nice property P that f (foldt f xs) (foldt f ys) = foldt f (xs ++ ys) if f is associative and xs, ys are non-empty. Now there are two fairly natural ways of making this function total. One way is to work with a monoidal structure (so f comes with a unit z). This results in the definition currently given on the wiki, and it preserves property P, and even extends it to empty lists. But the wiki page makes no mention of the fact that z should be a unit. The second way is to add an extra element that corresponds to the final (alternatively it could be the first...) element of the list being processed. This corresponds to the idea of having an "initial value", but property P is lost. This is what happens with your fix proposal. To summarize, I believe your fix proposal is ok, but there may be a bigger story to be told about tree-like folds. Cheers, Bertram From hjgtuyl at chello.nl Sat May 30 21:52:58 2015 From: hjgtuyl at chello.nl (Henk-Jan van Tuyl) Date: Sat, 30 May 2015 23:52:58 +0200 Subject: [Haskell-cafe] .a files not found In-Reply-To: <20150530171822.5296206.51377.8528@gsd.uwaterloo.ca> References: <20150530171822.5296206.51377.8528@gsd.uwaterloo.ca> Message-ID: If I use a sandbox inside C:\temp, I get the same error message again. Henk-Jan On Sat, 30 May 2015 19:18:22 +0200, wrote: > The location is not that ?important. In any folder where cabal install > fails, I can do cabal get + cabal install and it works. So it's probably > related to cabal's own temp folder names which get too long. > > Michal > > Original Message From: Henk-Jan van Tuyl > Sent: Saturday, May 30, 2015 1:04 PM > To: haskell-cafe at haskell.org; Matej Borovec > Subject: Re: [Haskell-cafe] .a files not found > > > That works! > > Thanks, > Henk-Jan van Tuyl > > > On Sat, 30 May 2015 18:45:00 +0200, Matej Borovec > wrote: > >> Try this for every package: >> >> mkdir c:\temp >> cd c:\temp >> cabal unpack data-default-instances-base >> cabal install ./data-default-instances-base >> >> >> -----Original Message----- From: Henk-Jan van Tuyl >> Sent: Saturday, May 30, 2015 11:39 AM >> To: haskell-cafe at haskell.org >> Subject: [Haskell-cafe] .a files not found >> >> >> L.S., >> >> I get messages about .a files not being found, when I try to install >> package data-default-instances-base, data-default-instances-containers, >> data-default-instances-dlist or data-default-instances-old-locale. How >> can >> I solve this? I am using GHC 7.10.1 on Windows. >> >> Sample output: >> >> C:\X\data-default-instances-old-locale-0.0.1> cabal install >> Resolving dependencies... >> Configuring data-default-instances-old-locale-0.0.1... >> Building data-default-instances-old-locale-0.0.1... >> Failed to install data-default-instances-old-locale-0.0.1 >> Build log ( >> C:\Users\X\AppData\Roaming\cabal\logs\data-default-instances-old-locale-0.0.1.log >> ): >> Building data-default-instances-old-locale-0.0.1... >> Preprocessing library data-default-instances-old-locale-0.0.1... >> [1 of 1] Compiling Data.Default.Instances.OldLocale ( >> Data\Default\Instances\OldLocale.hs, >> dist\build\Data\Default\Instances\OldLocale.o ) >> C:\Programs\Haskell\MinGHC-7.10.1\ghc-7.10.1\mingw\bin\ar.exe: >> dist\build\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a-2192\libHSdata-default-instances-old-locale-0.0.1-6jcjjaR25tK4x3nJhHHjFM.a: >> No such file or directory >> cabal: Error: some packages failed to install: >> data-default-instances-old-locale-0.0.1 failed during the building >> phase. >> The >> exception was: >> ExitFailure 1 >> >> >> Regards, >> Henk-Jan van Tuyl -- Folding at home What if you could share your unused computer power to help find a cure? In just 5 minutes you can join the world's biggest networked computer and get us closer sooner. Watch the video. http://folding.stanford.edu/ http://Van.Tuyl.eu/ http://members.chello.nl/hjgtuyl/tourdemonad.html Haskell programming -- From nicola.gigante at gmail.com Sun May 31 14:56:29 2015 From: nicola.gigante at gmail.com (Nicola Gigante) Date: Sun, 31 May 2015 16:56:29 +0200 Subject: [Haskell-cafe] Blog platform written in Haskell Message-ID: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> Hi all, Is there a blog platform written in Haskell? I mean something dynamic (as opposed to a static site generator like hakyll) like WordPress but written in Haskell. Does something like that exist? Greetings, Nicola From mihai.maruseac at gmail.com Sun May 31 15:59:10 2015 From: mihai.maruseac at gmail.com (Mihai Maruseac) Date: Sun, 31 May 2015 11:59:10 -0400 Subject: [Haskell-cafe] Blog platform written in Haskell In-Reply-To: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> References: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> Message-ID: Hi, That's what I know about: http://www.clckwrks.com/page/view-page-slug/1/clckwrks-com Never used it so far. On Sun, May 31, 2015 at 10:56 AM, Nicola Gigante wrote: > Hi all, > > Is there a blog platform written in Haskell? I mean something > dynamic (as opposed to a static site generator like hakyll) like > WordPress but written in Haskell. > > Does something like that exist? > > Greetings, > Nicola > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > -- Mihai Maruseac (MM) "If you can't solve a problem, then there's an easier problem you can solve: find it." -- George Polya -------------- next part -------------- An HTML attachment was scrubbed... URL: From thomas at koch.ro Sun May 31 16:38:54 2015 From: thomas at koch.ro (Thomas Koch) Date: Sun, 31 May 2015 18:38:54 +0200 Subject: [Haskell-cafe] Blog platform written in Haskell In-Reply-To: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> References: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> Message-ID: <14778267.vlDyoCH63g@x121e> On Sunday 31 May 2015 16:56:29 Nicola Gigante wrote: > Hi all, > > Is there a blog platform written in Haskell? I mean something > dynamic (as opposed to a static site generator like hakyll) like > WordPress but written in Haskell. > > Does something like that exist? i want to add a blog feature to gitit2 modeled after ikiwiki. some yesod bloging code snippets: - https://github.com/konn/Yablog - https://github.com/yesodweb/yesodweb.com/blob/master/Handler/Blog.hs - https://github.com/coreyoconnor/corebot-bliki/blob/master/src/Yesod/CoreBot/Bliki/Resources/Blog.hs From tdammers at gmail.com Sun May 31 17:32:39 2015 From: tdammers at gmail.com (Tobias Dammers) Date: Sun, 31 May 2015 19:32:39 +0200 Subject: [Haskell-cafe] Blog platform written in Haskell In-Reply-To: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> References: <5B4731BB-48A6-4EB7-90AC-09B4D13985E5@gmail.com> Message-ID: <20150531173238.GA8136@nibbler> FWIW, I'm working on a fairly generic CMS platform that could easily be bashed into a blog type website (assuming that you'd use something like disqus for comments), but it's not quite ready for prime time yet... On Sun, May 31, 2015 at 04:56:29PM +0200, Nicola Gigante wrote: > Hi all, > > Is there a blog platform written in Haskell? I mean something > dynamic (as opposed to a static site generator like hakyll) like > WordPress but written in Haskell. > > Does something like that exist? > > Greetings, > Nicola > _______________________________________________ > Haskell-Cafe mailing list > Haskell-Cafe at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe -- Tobias Dammers - tdammers at gmail.com