- Haskell-Cafe - Haskell.org

About pointer taken by C lib in FFI.
by Magicloud Magiclouds 14 Jan '19

14 Jan '19

Hi, Say I have some data, and `poke` into a Ptr. Then I pass the Ptr to some function in C lib. The C lib stores the Ptr somewhere to use later. My question is, how does GHC handle the finalizing of the Ptr? Does it track the "used by foreign lib"? -- 竹密岂妨流水过山高哪阻野云飞 And for G+, please use magiclouds#gmail.com.

3 4

Binary Data Access via PIC…??
by Nick Rudnick 13 Jan '19

13 Jan '19

On NL FP day, it struck me again when I saw an almost 1 MB *.hs file with apparent sole purpose of getting a quantity of raw data incorporated to the binary – applying some funny text encoding constructs. I remembered that, to my best knowledge, with major downside that it's compile time, this appears to be the best solution to me… Another approach I did notice several times was, say, the use of super fast parsing, to read in binary data at run time. Did I miss something? Or, more specifically – I am speaking about that kind of binary data which is (1) huge! – the 1 MB mentioned above rather being at the lower limit, (2) completely independent from the version of the Haskell compiler, (3) guaranteed (externally!) to match the structural requirements of the application referred to, (4) well managed in some way, concerning ABI issues, too (e.g. versioning, metadata headers etc.), and the question is in how far – as I believe other languages do, too – we can exploit PIC (position independent code), to read in really large quantities of binary data at run time or immediately before run time, without the need for parsing at all. E.g., a textual data representation Haskell file will generate an an object file already, for which linking only should have a limited amount of assumptions regarding its inner structure. Imagining I have a huge but simple DB table, and a kind of converter which by some simplification of a Haskell compiler generates an object file that equally matches these (limited, as I believe) assumptions, and at the end can build a 'fake' the linker accepts instead of one dummy file skeleton – couldn't that be a way leading into the direction of directly getting in vast amounts of binary data in one part? In case there are stronger integrity needs, extra metadata like should be usable for verification of the origin from a valid code generator. Of course, while not completely necessary, true run time loading would be even greater… while direct interfacing to foreign (albeit simple) memory spaces deems much more intricate to me. I regularly stumbled about such cases – so I do believe this to useful. I would be happy to learn more about this – any thoughts…?? Cheers, and all the best, Nick

2 1

Fwd: Void is not Monoid?
by Javran Cheng 13 Jan '19

13 Jan '19

(forgot to reply all, sorry) Hi Will, Thanks for the reply! > A monoid has an identity element, and void does not. now I feel dull never thought about that. > How would you write return with void as the writer? > You can accomplish what you want with the free monoid over Void - i.e. [Void], which is isomorphic to unit. So unit seems like the right choice. Unit does work fine, but I figure using Void is an interesting idea, as I can make sure that no one can use the "W" part of my RWST. Javran On Sun, Jan 13, 2019 at 12:23 AM William Yager <will.yager(a)gmail.com> wrote: > On Sun, Jan 13, 2019 at 4:00 PM Javran Cheng <javran.c(a)gmail.com> wrote: > >> Hi Cafe, >> >> I'm wondering why Data.Void does not have a Monoid instance, or, what >> would be the problem if we do "mempty = absurd mempty"? >> > > This diverges, does it not? > > A monoid has an identity element, and void does not. > > >> Long story: I was using a monad with some transformers, then I realize I >> can collapse State and Reader into RWST with Void being Writer output. >> (well, I could have just used Unit but I wanna give Void a try...) I know >> beforehand that Void is Semigroup but is a bit surprise it doesn't have >> Monoid instance. >> > > How would you write return with void as the writer? > > You can accomplish what you want with the free monoid over Void - i.e. > [Void], which is isomorphic to unit. So unit seems like the right choice. > > --Will > -- Javran (Fang) Cheng -- Javran (Fang) Cheng

3 3

Void is not Monoid?
by Javran Cheng 13 Jan '19

13 Jan '19

Hi Cafe, I'm wondering why Data.Void does not have a Monoid instance, or, what would be the problem if we do "mempty = absurd mempty"? Long story: I was using a monad with some transformers, then I realize I can collapse State and Reader into RWST with Void being Writer output. (well, I could have just used Unit but I wanna give Void a try...) I know beforehand that Void is Semigroup but is a bit surprise it doesn't have Monoid instance. Javran Cheng

2 1

Honest constant-space mergesort
by Ryan Reich 13 Jan '19

13 Jan '19

I am, for entertainment, trying to figure out how to implement a constant-space bottom-up mergesort in Haskell. This is quite easy to at least describe imperatively: break the list into ordered blocks, merge adjacent ones, and repeat with double the length until there's only one block and you're done. For a linked list like [a] in Haskell, this should be constant-space. Unfortunately, it is not. You can definitely express the above algorithm nicely if you organize those blocks into an [[a]], but then you are creating O(n) new lists. Even if you go to extremes to keep the blocks concatenated, though, you still have the issue that every time you merge two lists, you are creating a new list and that involves the allocator. (Note that the implementation of Data.List.sort does this.) The C equivalent would proceed by just overwriting the linking pointers in each node, without allocating new nodes to do so, but of course, that's not going to work in Haskell. I considered using something like STRef to represent the links (so, departing from the plain [a] type) but even then, if you overwrite the contents of one of those, the garbage collector still needs to know. This is better than allocating more space, but it is not necessary because the algorithm never actually makes any of the nodes unreachable. Also, I understand that using a lot of STRefs is bad for efficiency. Is there any way to do this in (GHC) Haskell and get the algorithm down to the bare minimum? If there is, is it any different than just "writing C in Haskell"? That is, can one coerce GHC into emitting the mutable-link operations and not doing collections, from high-level code? Although I've definitely seen examples of algorithms that compile down to such unboxed depths, this one has been really resistant to improvement. Thanks, Ryan Reich

3 3

Re: [Haskell-cafe] About 'Overloaded functions are not your friend' line in GHC manual
by Johannes Waldmann 11 Jan '19

11 Jan '19

At run-time, only the branch (Left/Right) is "picked" at run-time. For each branch, the "show" instance is determined at compile-time. The problem is that such instances are represented by dictionaries, and this adds extra cost (extra arguments) to function calls - but only in those cases where these dictionaries are not inlined (that is, removed) statically. But I am thinking that GHC has become very good at inlining. - J.W.

3 3

LambdaConf 2019 Call for Proposals
by John A. De Goes 11 Jan '19

11 Jan '19

Dear Haskell Enthusiasts: The LambdaConf 2019 Call for Proposals is open, and we warmly welcome Haskell proposals on topics of interest to aspiring and practicing functional programmers. Historically, Haskell content accounts for more than 50% of content across all 5-8 tracks of the event. Last year’s speakers included Michael Snoyberg, Dana Scott, Jeremy Siek, and many others from both industry and academia. To submit a proposal for LambdaConf 2019, please visit the following website: https://www.papercall.io/lambdaconf-2019 Travel assistance is available, including lodging. ## INTRODUCTION LambdaConf is the largest interdisciplinary functional programming conference in the Mountain West, and one of the largest and most respected functional programming conferences in the world. The conference takes place June 5rd - 7th, in Boulder, Colorado, at the University of Colorado Boulder, and is surrounded by commercial training opportunities. If you are an educator, a researcher, a speaker, a speaker coach, or someone aspiring to one of the preceding, then we warmly welcome you to submit a proposal for LambdaConf 2019. No prior experience is necessary for most proposals, and we welcome beginner-level content. The Call for Proposals closes at the end of January 2019. We recommend submitting as early as you can to ensure sufficient time for editing. LambdaConf attracts everyone from the FP-curious to researchers advancing state-of-the-art; hobbyists, professionals, academics and students. Material at all levels, including beginner content and very advanced content, will find an audience at LambdaConf. Historically, LambdaConf has enjoyed a large selection of sessions on statically-typed functional programming, and a smaller selection of sessions on dynamically-typed functional programming. Some sessions are not tied to specific programming languages, but rather cover topics in abstract algebra, category theory, type theory, programming language theory, functional architecture, and so on, either generically or in a way that applies across many programming languages. ## TOPICS LambdaConf looks for sessions in the following areas: - LANGUAGES. Proposals that overview or dive into specific features of functional, math, or logic programming languages (both new and existing), with the goal of exposing developers to new ideas or helping them master features of languages they already know. LIBRARIES. Proposals that discuss libraries that leverage functional or logic programming to help programmers solve real-world problems. - CONCEPTS. Proposals that discuss functional programming idioms, patterns, or abstractions; or concepts from mathematics, logic, and computer science, all directed at helping developers write software that’s easier to test, easier to reason about, and easier to change safely. - APPLICATIONS. Proposals that discuss how functional programming can help with specific aspects of modern software development, including scalability, distributed systems, concurrency, data processing, security, performance, correctness, user-interfaces, machine learning, and big data. - USE CASES. Proposals that discuss how functional programming enabled a project or team to thrive, or deliver more business value than possible with other approaches. - CHERRY PICKING. Proposals that show how techniques and approaches from functional programming can be adapted and incorporated into mainstream development languages and practices, to the benefit of developers using them. - CAUTIONARY TALES. Proposals that call attention to difficulties of functional programming (both as a cautionary tale but also to raise awareness), especially such proposals that suggest alternatives or a path forward. - EFFICACY. Proposals that present data, measurements, or analysis that suggests different techniques, paradigms, languages, libraries, concepts, or approaches have different efficacies for given specified metrics, which provide actionable takeaways to practicing functional and logic programmers. - OFF-TOPIC. Proposals that have appeal to a mainstream developer audience (the number of off-topic proposals we accept is small, but we do accept some, especially for keynotes). ## SESSION TYPES LambdaConf accepts proposals for the following types of sessions: - LEAP WORKSHOPS (6h). Leap Workshops are approximately 6 hours in length. They are in-depth, hands-on workshops designed to teach mainstream functional programming topics in enough detail, attendees can immediately apply what they learn in their jobs. We require that speakers follow our recommended format for Leap Workshops, although we allow exceptions for experienced teachers. - HOP WORKSHOPS (2h). Hop Workshops are 2 hours in length. Like Leap Workshops, these workshops are in-depth and hands-on, but they cover reduced content and may be specialized to topics that may not have mainstream appeal. We require that speakers follow our recommended format for Hop Workshops, although we allow exceptions for experienced teachers. - DE NOVO SESSIONS (50m). De Novo Sessions are 50 minutes in length. These sessions are designed to present original work from industry and academia. While the requirements for proposals are more rigorous, there is less competition for De Novo slots. - EDUCATIONAL SESSIONS (50m). Educational Sessions are 50 minutes in length. These sessions are designed to clearly and concisely teach one useful concept, skill, aspect, library, or language to attendees. - KEYNOTES (40m). Keynotes are 40 minutes in length, and are presented before all attendees (there are no other sessions concurrent with keynotes). Keynotes are designed to offer thought-provoking, opinionated, and insightful commentary on topics of interest to the community. If you are accepted for a specific type of proposal (e.g. Educational), we cannot guarantee that you will get a slot of this type. Based on scheduling requirements, feedback from the committee, or feedback from your speaker coach, we may require you to change the format of your session. Regards, -- John A. De Goes john(a)degoes.net Follow me on Twitter @jdegoes

8 10

Second Call for Papers: PACMPL issue ICFP 2019
by William Fearon 11 Jan '19

11 Jan '19

1 0

About 'Overloaded functions are not your friend' line in GHC manual
by Michail Pevnev 10 Jan '19

10 Jan '19

Hello everyone. I've been browsing through GHC manual some time ago, mostly to see what extensions there are, and stumbled upon the following paragraph in the 'Advice on: sooner, faster, smaller, thriftier' section, 'faster' subsection: Overloaded functions are not your friend: Haskell’s overloading (using type classes) is elegant, neat, etc., etc., but it is death to performance if left to linger in an inner loop. I don't quite understand the reason behind this. I was under impression that function overloading - existential shenanigans aside - is resolved mostly at compile time. Mostly, because obviously, say, 'show' for an Either still has to examine its argument at runtime and pick appropriate 'show' for one of the inner types. But the same happens for any examination of an Either, really. Does overloading make it worse, and if so, how and why? Or am I completely off track here, and the actual reason is something entirely different? -- Michail.

1 0

overloading functions
by Damien Mattei 10 Jan '19

10 Jan '19

Hi, i have this definition: {-# LANGUAGE FlexibleInstances #-} class ConcatenateMaybeString a where cms :: Maybe String -> a -> Maybe String instance ConcatenateMaybeString (Maybe String) where cms mf ms = mf >>= (\f -> ms >>= (\s -> return (f ++ s))) instance ConcatenateMaybeString String where cms mf s = mf >>= (\f -> return (f ++ s)) when i use it on : f `cms` ("." ::String) `cms` s it works but not on this: f `cms` "." `cms` s "." is too ambigious to compile: *Main> :load UpdateSidonie [1 of 1] Compiling Main ( UpdateSidonie.hs, interpreted ) UpdateSidonie.hs:373:43: error: • Ambiguous type variable ‘a0’ arising from a use of ‘cms’ prevents the constraint ‘(ConcatenateMaybeString a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance ConcatenateMaybeString (Maybe String) -- Defined at UpdateSidonie.hs:169:11 instance ConcatenateMaybeString String -- Defined at UpdateSidonie.hs:177:11 • In the first argument of ‘cms’, namely ‘f `cms` "."’ In the expression: f `cms` "." `cms` s In the expression: let f = fmap head resBDwords s = fmap (head . tail) resBDwords mp = Just "." :: Maybe String .... in f `cms` "." `cms` s | 373 | in f `cms` "." `cms` s) :: Maybe String | ^^^^^^^^^^^ UpdateSidonie.hs:373:51: error: • Ambiguous type variable ‘a0’ arising from the literal ‘"."’ prevents the constraint ‘(Data.String.IsString a0)’ from being solved. Probable fix: use a type annotation to specify what ‘a0’ should be. These potential instances exist: instance Data.String.IsString Query -- Defined in ‘Database.MySQL.Simple.Types’ instance Data.String.IsString Tx.Text -- Defined in ‘Data.Text’ instance (a ~ Char) => Data.String.IsString [a] -- Defined in ‘Data.String’ ...plus six instances involving out-of-scope types (use -fprint-potential-instances to see them all) • In the second argument of ‘cms’, namely ‘"."’ In the first argument of ‘cms’, namely ‘f `cms` "."’ In the expression: f `cms` "." `cms` s | 373 | in f `cms` "." `cms` s) :: Maybe String | ^^^ Failed, no modules loaded. Prelude> any idea? Damien

5 7