- Haskell-Cafe - Haskell.org

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

03 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 03 Nov '16

03 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

Cfa TTT 2017 (Type Theory Based Tools)
by Andreas Abel 02 Nov '16

02 Nov '16

CALL FOR ABSTRACTS TTT : Type Theory Based Tools ============================= Satellite workshop of POPL 2017, Paris France, January 15th [We have funding possibilities for students and young researchers, see below. Note the early deadline!] Overview ======== The aim of this workshop is to showcase modern tools based on type theory, whether designed for programming or for verification, whether academic projects or used in an industrial setting. It will provide a forum to highlight and discuss their common and their distinctive features, and the future directions of development of the tools. The program will consist of invited and contributed talks, and will encourage informal discussion. Abstracts will be displayed on the website of the workshop but there will be no proceedings. We solicit abstract submissions proposing demos, case studies, describing the impact of a theoretical result on practice, or any other aspect of the development and use of tools based on type theory. In particular, we welcome submissions about prototype implementations and promising work in progress, as soon as they have the potential of raising interesting discussions. This workshop is funded by the EUTypes COST project (https://eutypes.cs.ru.nl/) The program will include a plenary discussion on the role of the EUTypes project in the community and planning of activities for 2017. Invited Speakers ================ Robbert Krebbers, Delft University of Technology, Netherlands Aaron Tomb, Galois, US More speakers to be confirmed Registration ============ Registration information will be soon available at the main POPL 2017 website: http://conf.researchr.org/home/POPL-2017 Participant funding =================== The EUTypes COST project (https://eutypes.cs.ru.nl/) can fund students and young researchers from countries participating in the project to attend the workshop – check http://www.cost.eu/COST_Actions/ca/CA15123?parties to see if your country is listed. The application should include the following information: * Your name * Your institution * The name of your supervisor(s) * The url of your webpage if you have one * Your research topics or interests in 1 paragraph and should be sent to ttt2017(a)easychair.org as soon as possible and no later than November 20th. Contact ======= For any query about this workshop, please contact us at ttt2017(a)easychair.org Call for abstracts ================== Submissions for talks and demonstrations should be described in an extended abstract, between 1 and 2 pages in length. We suggest formatting the text using the two-column SIGPLAN LaTeX style (9pt font). Submission page: https://easychair.org/conferences/?conf=ttt2017 Important dates =============== Submission deadline: 30 November 2016 Notification: 15 December 2016 Workshop: 15 January 2017 Program Committee ================= Andreas Abel, Gothenburg University, Sweden Andrej Bauer, University of Ljubljana, Slovenia Assia Mahboubi, Inria Université Paris-Saclay, France Keiko Nakata, Germany -- Andreas Abel <>< Du bist der geliebte Mensch. Department of Computer Science and Engineering Chalmers and Gothenburg University, Sweden andreas.abel(a)gu.se http://www2.tcs.ifi.lmu.de/~abel/

1 0

Suggestion for Data Structure regarding Timetabling and Time Intervals
by Michael Roth 02 Nov '16

02 Nov '16

I would like to experiment with timetabling algorithms and resource scheduling in a special use case: I have time intervals like A, B and C and they are put sequentially on a time line. However, between the major time intervals like A, B etc. their are always "minor" time intervals which separates the major ones. For example: a, A, ab, B, bc, C, c Upper case letters denotes "major" time intervals and lower case letters denotes the minor intervals which always separates the major ones. The minor time intervals only have a duration, their exact occurrence in time doesn't matter, only the fact that they occur between the major time intervals are important. The major time intervals start and stop a specific time; they don't overlap and maybe there is free time between major and/or minor time intervals. The minor time intervals "a" and "b" at the beginning and ending of the complete time line I'm not interested in and can be omitted completely. Say, to insert a time interval X after B, assuming there is enough free time between B and C, the resulting structure is: a, A, ab, B, bx, X, xc, C, c The minor time interval "bc" is discarded and two new minor time intervals "bx" and "xc" are inserted. I'm a little bit stuck what a good data structure would be for this problem. Additionally I would like to use an infinite data structure, because a priori I don't know how many time intervals have to be created and inserted into the time line. The time intervals are not generated in an ascending order. An algorithm will search for possible places to insert the new created major time intervals and creates the corresponding minor time intervals. There is the concept of a "present time" in this process. The algorithm can only manipulate the future. I thought to push all time intervals in the past respective to this "present time" to a MonadWriter to get my infinite list of time intervals. The "present time" is moved forward at specific events. What do you experts think about the approach with the MonadWriter? What would be a good data structure to ensure that all major time intervals are separated by minor time intervals? Thank you in advance for your ideas and comments, Michael Roth

1 0

Suggestion: A catalog of Language extensions
by Zachary Kessin 01 Nov '16

01 Nov '16

I have noticed that almost every haskell source file I have looked at has 4-8 language extensions. It would be very nice if there was a page somewhere that listed them all and gave a short (1 paragraph) description of what that extension does and what it is normally used for. That is not a detailed description of the API but a short description of *WHY* you might want to use it. Followed by a link to the API -- Zach Kessin SquareTarget <http://squaretarget.rocks?utm_source=email-sig> Twitter: @zkessin <https://twitter.com/zkessin> Skype: zachkessin ᐧ

4 3

Call for Workshop Proposals: ICFP 2017
by Lindsey Kuper 01 Nov '16

01 Nov '16

CALL FOR WORKSHOP AND CO-LOCATED EVENT PROPOSALS ICFP 2017 22nd ACM SIGPLAN International Conference on Functional Programming September 3-9, 2017 Oxford, United Kingdom http://conf.researchr.org/home/icfp-2017 The 22nd ACM SIGPLAN International Conference on Functional Programming will be held in Oxford, United Kingdom on September 3-9, 2017. ICFP provides a forum for researchers and developers to hear about the latest work on the design, implementations, principles, and uses of functional programming. Proposals are invited for workshops (and other co-located events, such as tutorials) to be affiliated with ICFP 2017 and sponsored by SIGPLAN. These events should be less formal and more focused than ICFP itself, include sessions that enable interaction among the attendees, and foster the exchange of new ideas. The preference is for one-day events, but other schedules can also be considered. The workshops are scheduled to occur on September 3 (the day before ICFP) and September 7-9 (the three days after ICFP). ---------------------------------------------------------------------- Submission details Deadline for submission: November 19, 2016 Notification of acceptance: December 18, 2016 Prospective organizers of workshops or other co-located events are invited to submit a completed workshop proposal form in plain text format to the ICFP 2017 workshop co-chairs (David Christiansen and Andres Loeh), via email to icfp2017-workshops(a)googlegroups.com by November 19, 2016. (For proposals of co-located events other than workshops, please fill in the workshop proposal form and just leave blank any sections that do not apply.) Please note that this is a firm deadline. Organizers will be notified if their event proposal is accepted by December 18, 2016, and if successful, depending on the event, they will be asked to produce a final report after the event has taken place that is suitable for publication in SIGPLAN Notices. The proposal form is available at: http://www.icfpconference.org/icfp2017-files/icfp17-workshops-form.txt Further information about SIGPLAN sponsorship is available at: http://www.sigplan.org/Resources/Proposals/Sponsored/ ---------------------------------------------------------------------- Selection committee The proposals will be evaluated by a committee comprising the following members of the ICFP 2017 organizing committee, together with the members of the SIGPLAN executive committee. Workshop Co-Chair: David Christiansen (Indiana University) Workshop Co-Chair: Andres Loeh (Well-Typed LLP) General Chair: Jeremy Gibbons (University of Oxford) Program Chair: Mark Jones (Portland State University) ---------------------------------------------------------------------- Further information Any queries should be addressed to the workshop co-chairs (David Christiansen and Andres Loeh), via email to icfp2017-workshops(a)googlegroups.com

1 0