November 2016 - Haskell-Cafe

Re: [Haskell-cafe] Suggestion for Data Structure regarding Timetabling and Time Intervals
by dominic＠steinitz.org 03 Nov '16

03 Nov '16

I don’t know if this is relevant but for manipulating time intervals, I have found the intervals package very useful. > Message: 5 > Date: Wed, 2 Nov 2016 21:26:32 +0100 > From: Olaf Klinke <olf(a)aatal-apotheke.de> > To: list(a)mroth.net > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] Suggestion for Data Structure regarding > Timetabling and Time Intervals > Message-ID: <63753058-716B-4D2B-8D8F-4B0F77732C2A(a)aatal-apotheke.de> > Content-Type: text/plain; charset=us-ascii > > Dear Michael, > > if you can be sure your intervals will never overlap, why not use a binary search tree, such as Data.Set from containers? You could make a data structure distinguishing major and minor intervals such as: > > type Time = -- your favourite totally ordered time type > data Major = Major { > fromTime :: Time, > untilTime :: Time} deriving (Eq) > data Minor = Minor { > after :: Time > before :: Time} deriving (Eq) > type TimeInterval = Either Minor Major > > instance Ord (Either Minor Major) where > Left a <= Left b = before a <= after b > Right a <= Right b = untilTime a <= fromTime b > Left a <= Right b = before a <= fromTime b > Right a <= Left b = untilTime a <= after b > > If I understood your intentions correctly, inserting a minor interval between a :: Major and b :: Major where a < b would mean to insert > > Minor {after = untilTime a, before = fromTime b} > > It might also be handy to define a new type (isomorphic to the product (a,b)) > > Anno a b = Anno a b > > whose Ord instance uses the Ord instance of b only, so that > > Anno "Some annotation" (Major t0 t1) > > is an interval bearing some annotation that can be ordered just like the Major type. > > If your intervals _do_ overlap, then two intervals can be in six different configurations (instead of LT, GT and EQ), and several tree structures exist that support some operations more or less efficiently. Bioinformatics and geometry has developed good data structures and algorithms to deal with efficient overlap searches. > > Olaf > > Dominic Steinitz dominic(a)steinitz.org http://idontgetoutmuch.wordpress.com

1 0

Using unboxed integers
by Richard A. O'Keefe 03 Nov '16

03 Nov '16

I have x, y :: Int# I expect that x <=# y :: Bool but ghc 7.8 says Couldn't match expected type âBoolâ with actual type âInt#â In the expression: x <=# y In an equation for âbâ: b = x <=# y I have MagicHash and I've imported the right modules so that <=# is recognised as *something*, but at this point I'm baffled. I'm also not clear on how I can show an Int#.

3 3

Any students for master project in The Netherlands? (near Eindhoven)
by Damian Nadales 03 Nov '16

03 Nov '16

Hi, In my current team, we're looking for Master students to work in a project about checking RAML specifications automatically. We would like to develop this in the functional paradigm, but all the students we got so far have no FP exposure whatsoever. So if you know of somebody that might be looking for a master project and want to know more details please do let me know (maybe Alejandro and Jurriën have some ideas ;)). Best, Damian.

1 0

Call for participation: BayHac 2017 survey
by danburton.email＠gmail.com 02 Nov '16

02 Nov '16

I've invited you to fill out the following form: BayHac 2017 participation survey To fill it out, visit: https://docs.google.com/forms/d/e/1FAIpQLSdaHON7_RFSwR-2aAHpR8bJ6IUvpQ7Usul… BayHac is a Haskell hackathon weekend event for the San Francisco Bay Area and Silicon Valley. It will be a weekend of learning, hacking, and connecting with fellow Haskell enthusiasts. The proposed outline for 2017 is: Friday: Haskell in Production & getting started with Haskell Saturday: Get involved! Highlights of various open source Haskell projects. Sunday: Follow along: Abstract concepts taught via Haskell code snippets. As we solidify the location and date (tentatively March or April 2017), Haskellers of all varieties and skill levels are invited to participate to the degree that they are willing and able. If you are interested in attending BayHac 2017, kindly fill out this survey to help us calibrate and organize our preparations. Google Forms: Create and analyze surveys.

1 0

Re: [Haskell-cafe] Suggestion: A catalog of Language (broken links)
by Olaf Klinke 02 Nov '16

02 Nov '16

The documentation https://downloads.haskell.org/~ghc/8.0.1/docs/html/libraries/Cabal-1.24.0.0… was mentioned in a post on haskell-cafe, and I found that every link to a specific KnownExtension there is broken. Olaf

2 1

Re: [Haskell-cafe] Suggestion for Data Structure regarding Timetabling and Time Intervals
by Olaf Klinke 02 Nov '16

02 Nov '16

Dear Michael, if you can be sure your intervals will never overlap, why not use a binary search tree, such as Data.Set from containers? You could make a data structure distinguishing major and minor intervals such as: type Time = -- your favourite totally ordered time type data Major = Major { fromTime :: Time, untilTime :: Time} deriving (Eq) data Minor = Minor { after :: Time before :: Time} deriving (Eq) type TimeInterval = Either Minor Major instance Ord (Either Minor Major) where Left a <= Left b = before a <= after b Right a <= Right b = untilTime a <= fromTime b Left a <= Right b = before a <= fromTime b Right a <= Left b = untilTime a <= after b If I understood your intentions correctly, inserting a minor interval between a :: Major and b :: Major where a < b would mean to insert Minor {after = untilTime a, before = fromTime b} It might also be handy to define a new type (isomorphic to the product (a,b)) Anno a b = Anno a b whose Ord instance uses the Ord instance of b only, so that Anno "Some annotation" (Major t0 t1) is an interval bearing some annotation that can be ordered just like the Major type. If your intervals _do_ overlap, then two intervals can be in six different configurations (instead of LT, GT and EQ), and several tree structures exist that support some operations more or less efficiently. Bioinformatics and geometry has developed good data structures and algorithms to deal with efficient overlap searches. Olaf

1 0

DefaultSignature versus overlapping instance
by Ole Krüger 02 Nov '16

02 Nov '16

Ahoy, I have the following type class. -- | An entity whose underlying information spans zero or more columns class ResultEntity a where -- | Build an instance of @a@. parseEntity :: RowParser a default parseEntity :: (EligibleDataType meta cons a) => RowParser a parseEntity = parseGeneric The EligibleDataType constraint allows me to construct a RowParser with the help of generics. It is so minimal that I am considering to transform the hole thing into this. -- | An entity whose underlying information spans zero or more columns class ResultEntity a where -- | Build an instance of @a@. parseEntity :: RowParser a instance {-# OVERLAPPABLE #-} (EligibleDataType meta cons a) => ResultEntity a where parseEntity = parseGeneric This makes defining new instances of ResultEntity obsolete for types that already satisfy the EligibleDataType constraint (basically everything that has a Generic instance). It is still possible to provide a hand-rolled instance. Undecidable and overlapping instances seem like a big no-no. Even after reading up on them, I can't get rid of the feeling that this might be dangerous. *Is it dangerous? *I am targeting GHC 8.0.1 with this. - Ole

1 1

file name to module name
by Corentin Dupont 02 Nov '16

02 Nov '16

Hi there, is there somewhere in the libraries a function to transform a file name into a module name? for exemple: "src/Data/List.hs" --> "Data.List" Thanks! Corentin

1 0

GHCJS Bad first impression
by Zachary Kessin 02 Nov '16

02 Nov '16

I am starting a project that might use ghcjs and it seems to me that if someone's first impression of it is tying stack install and having it take several hours to build everything that is not a very welcoming way to get people to use ghcjs. Why not precompiled binaries? Also while It has been compiling i have seen a lot of warnings? Zach -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin ᐧ

5 7

Re: [Haskell-cafe] Haskell-Cafe Digest, Vol 158, Issue 29
by Rik Howard 02 Nov '16

02 Nov '16

Richard thanks for your response and the references which I'll look into, the Dijkstra sounds particularly relevant. "Procedural-functional" is not novel; and as you also mentioned, Haskell, Clean and Mercury would qualify, if you chose to look at it that way, as would other languages. Any novelty in the note would only ever be in the way that the mix is provided. You raise salient points about the sort of challenges that languages will need to confront although a search has left me still unsure about PGPUs. Can I ask you to say a bit more about programming styles: what Java can't do, what others can do, how that scales? Regards Rik On 27 October 2016 at 13:00, <haskell-cafe-request(a)haskell.org> wrote: > Send Haskell-Cafe mailing list submissions to > haskell-cafe(a)haskell.org > > To subscribe or unsubscribe via the World Wide Web, visit > http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe > or, via email, send a message with subject or body 'help' to > haskell-cafe-request(a)haskell.org > > You can reach the person managing the list at > haskell-cafe-owner(a)haskell.org > > When replying, please edit your Subject line so it is more specific > than "Re: Contents of Haskell-Cafe digest..." > > > Today's Topics: > > 1. Re: A Procedural-Functional Language (WIP) (Rik Howard) > 2. Re: A Procedural-Functional Language (WIP) (Rik Howard) > 3. Re: A Procedural-Functional Language (WIP) (Richard A. O'Keefe) > 4. Proof of concept of explanations for instance resolution > (Michael Sloan) > 5. Re: A Procedural-Functional Language (WIP) (Joachim Durchholz) > 6. Re: Proof of concept of explanations for instance resolution > (Tom Ellis) > 7. Fwd: How to best display type variables with the same name > (Christopher Done) > 8. CoALP-Ty'16: Call for Participation (František Farka) > > > ---------------------------------------------------------------------- > > Message: 1 > Date: Wed, 26 Oct 2016 16:48:47 +0100 > From: Rik Howard <rik(a)dcs.bbk.ac.uk> > To: Joachim Durchholz <jo(a)durchholz.org> > Cc: haskell-cafe(a)haskell.org > Subject: Re: [Haskell-cafe] A Procedural-Functional Language (WIP) > Message-ID: > <CAAGBjQW+xzaU5kGQsm5S_et6v4YXOZ1QvkNN_cRfigRUOdbNMQ@ > mail.gmail.com> > Content-Type: text/plain; charset="utf-8" > > Jo > > > > Question is not whether these things are precluded, question is how you > > want to tackle them. It's not even stating design goals here. > > > The section on Types has been amended to note that these questions form a > part of the ongoing work. > > > > > > > The salient point of this and some other features is that they make it > > easier to reason about a given program's properties, at the expense of > > making programming harder. > > > > You put that point well. > > > > > > The basic concept of subtypes is simple, but establishing a definition of > > "subtype" that is both useful and sound is far from trivial. > > > > I hope that there is nothing that I've said that could be interpreted as me > thinking otherwise. As you mentioned elsewhere, though, they look too > appealing to ignore. > > > > > > For example. mutable circles and mutable ellipses are not in a subtype > > relationship to each other if there is an updating "scale" operation with > > an x and y scaling factor (you cannot guarantee that a scaled circle > stays > > circular). > > The design space for dealing with this is far from fully explored. > > > > I'm not sure that the language could support mutable structures but I take > your point that there are complications. > > > > > > Also, subtypes and binary operators do not really mix; google for > > "parallel type hierarchy". (The core of the problem is that if you make > > Byte a subtype of Word, declaring the (+) operator in Word as Word -> > Word > > will preclude Byte from being a subtype because you want a covariant > > signature in Byte but that violates subtyping rules for functions. So you > > need parametric polymorphism, but now you cannot use the simple methods > for > > subtyping anymore.) > > > Clearly there is more to be done in this area. > > > > > > The key point to mention is that you want to maintain referential > > integrity. > > > > The document now mentions this. > > > > > > Sounds pretty much like the conseqences of having the IO monad in > Haskell. > > > > That seems fair to me although the broader impact on an entire program > would be different I think. > > > > > > I think you should elaborate similarities and differences with how > Haskell > > does IO, that's a well-known standard it is going to make the paper > easier > > to read. Same goes for Clean&Mercury. > > > Something like that is addressed in Related Work. Clean is already on the > list but it sounds, from your comments and those of others, as if Mercury > may be worth including as well. > > > > > > It's hard to tell whether it is actually new, too many details are > missing. > > > Certainly you have spotted the vagueness in the types however I think that > that issue can be momentarily set aside from the point of view of novelty. > The language is purely functional with respect to functions and provides > out-vars as the only mechanism for dealing with IO. Let's assume for the > moment that that all hangs together: if there is another language that does > that, no novelty; otherwise, there is novelty. > > Once again, your feedback has been useful and stimulating. Many thanks! > > Regards > Rik >

3 10