- Haskell-prime - Haskell.org

definition of List.transpose
by Doug McIlroy 03 Mar '15

03 Mar '15

Not having participated in haskell' before, I'm not sure how to put these perfecting amendments--mot langauge changes--into the pot. Doug McIlroy The specification of List.transpose does not tell what a "column" of a ragged-right list of rows is, either directly or by example. Here is a fuller spec, plus some properties. ----------------------------------------------------- A generalization of the customary matrix operation, transpose returns a list of columns extracted from a list of rows. The jth column of x::[[a]] comprises all extant elements x!!i!!j ordered by i. In the subdomain of list structures that have positive nonincreasing row lengths, e.g. matrices and Young tableaux, transpose . transpose === id (transpose x) !! i !! j === x !! j !! i In general transpose . transpose . transpose === transpose sum . map length . transpose === sum . map length Example: transpose [[10,11],[20],[],[30,31,32]] === [[10,20,30],[11,31],[32]] ----------------------------------------------------- The reference definition can be simplified: transpose xss = case [h | (h:_) <- xss] of [] -> [] hs -> hs : transpose [tss | (_:tss) <- xss]

2 1

Re:definition of List.transpose
by Doug McIlroy 01 Mar '15

01 Mar '15

Sorry for a stylistic lapse in a post I just sent from the wrong file. A tail should be called ts, not tss, in the proposed reference definition for List.transpose Doug transpose xss = case [h | (h:_) <- xss] of [] -> [] hs -> hs : transpose [ts | (_:ts) <- xss]

1 0

Several default implementations for instance methods
by Andreas Abel 04 Oct '14

04 Oct '14

Consider the following class for an overloaded pretty printer. For atomic data (numeric types, String etc.) one would implement prettyShow, for complex data either pretty or prettyPrec. > import Text.PrettyPrint > > class Pretty a where > pretty :: a -> Doc > prettyShow :: a -> String > prettyPrec :: Int -> a -> Doc Implementing one of these methods should be enough, giving default implementations for the other two. It is easy to get prettyShow and prettyPrec from pretty. > prettyShow = render . pretty > prettyPrec = const . pretty However, to define pretty from one of the others, I need two default implementations. > pretty = text . prettyShow > pretty = prettyPrec 0 Is there a way to get this to work? Workarounds (not entirely satisfactory): Technically, one could define a cycle of default implementations. Alternative 1: > pretty = prettyPrec 0 > prettyShow = render . pretty > prettyPrec _ = text . prettyShow Problem: Here, if pretty is defined, > prettyPrec _ = text . render . pretty instead of just > prettyPrec _ = pretty and (text . render) is not the identity (destroys inner document structure). Alternative 2: > pretty = text . prettyShow > prettyShow = render . prettyPrec 0 > prettyPrec _ = pretty Problem: Here, if prettyPrec is defined, > pretty = text . render . prettyPrec 0 instead of just > pretty = prettyPrec 0 I guess alternative 2 is worse than alternative 1, as one would usually define prettyPrec to get pretty, and not the otherway round. But none of these two alternatives really does the job. -- 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/

3 2

Re: Revival: PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 23 Aug '14

23 Aug '14

Right, given the lack of disagreement and past support for this I will implement whichever variant is simplest to implement/strikes my fancy and put a patch up on Trac. Cheers, Merijn On 16 Aug 2014, at 14:23 , Carter Schonwald <carter.schonwald(a)gmail.com> wrote: > i personally think the .format+lhs pattern/convention is a good one, and prevents any misinterpretations that current plague literate tools + willl be treated as an unknown format rather than eagerly as .format or .lhs > > > On Sat, Aug 16, 2014 at 5:05 PM, Merijn Verstraaten <merijn(a)inconsistent.nl> wrote: > Hey Philip, > > This proposal is not because *GHC* needs to know anything about markdown/rST, in fact, GHC is already perfectly happy to take a literate haskell files that’s written in markdown, since it just strips the non-haskell bits and only compiles the haskell code. > > The problem is OTHER tools. For example, I have literate haskell files for my blog posts, how does my blog software know whether my lhs file is markdown, rST, TeX, or what not? I can just name my files using anyway I want (like “Foo.md.lhs”) to have these tools detect the format, but then GHC will no longer compile my files. > > This is the problem I’m trying to solve with this proposal, once we settle on some extension format like this, it’s trivial to patch (for example) pandoc to use this to detect which contents are in the file. > > Cheers, > Merijn > > > On 16 Aug 2014, at 06:51 , p.k.f.holzenspies(a)utwente.nl wrote: > > Dear Merijn, > > > > Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) > > > > Regards, > > Philip > > > > > > ________________________________________ > > Van: Glasgow-haskell-users <glasgow-haskell-users-bounces(a)haskell.org> namens Merijn Verstraaten <merijn(a)inconsistent.nl> > > Verzonden: zaterdag 16 augustus 2014 00:40 > > Aan: haskell-prime(a)haskell.org; glasgow-haskell-users(a)haskell.org > > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > > > Ola! > > > > I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: > > > > There was no real opposition to the general idea, the only real objection to the original proposal was that “Foo.lhs.md” and “Foo.md.lhs” would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md” and “Foo.md+lhs”. > > > > According to MS documentation and testing the + should not be an issue on windows, the + doesn’t collide with any other haskell compiler (at least, not any I’m aware off) and since the report doesn’t specify any module name resolution mechanism, it does not conflict with the report either. > > > > My personal preferences goes to either “.lhs+md” or “.md+lhs”, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is “.lhs+*” or “.*+lhs”. > > > > Are there any objections to this? If not, I’m just going to produce a patch + ticket as there were no real objections to the proposal last time. > > > > Cheers, > > Merijn > > > > On 16 Mar 2014, at 05:56 , Merijn Verstraaten <merijn(a)inconsistent.nl> wrote: > >> Ola! > >> > >> I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. > >> > >> Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) > >> > >> The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. > >> > >> Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. > >> > >> I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. > >> > >> Pros: > >> - Tool authors can more easily determine non-haskell content of literate haskell files > >> - Currently valid module names will not break > >> - Report doesn't specify behaviour, so GHC can do whatever it likes > >> > >> Cons: > >> - Someone has to implement it > >> - ?? > >> > >> Discussion: 4 weeks > >> > >> Cheers, > >> Merijn > >> > > > _______________________________________________ > Glasgow-haskell-users mailing list > Glasgow-haskell-users(a)haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users > >

1 0

Re: Revival: PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 16 Aug '14

16 Aug '14

Hey Philip, This proposal is not because *GHC* needs to know anything about markdown/rST, in fact, GHC is already perfectly happy to take a literate haskell files that’s written in markdown, since it just strips the non-haskell bits and only compiles the haskell code. The problem is OTHER tools. For example, I have literate haskell files for my blog posts, how does my blog software know whether my lhs file is markdown, rST, TeX, or what not? I can just name my files using anyway I want (like “Foo.md.lhs”) to have these tools detect the format, but then GHC will no longer compile my files. This is the problem I’m trying to solve with this proposal, once we settle on some extension format like this, it’s trivial to patch (for example) pandoc to use this to detect which contents are in the file. Cheers, Merijn On 16 Aug 2014, at 06:51 , p.k.f.holzenspies(a)utwente.nl wrote: > Dear Merijn, > > Do you even need a separate extension or filename convention for this? Can't you just call it lhs and expand the definition thereof to include markdown? (I suggested something similar before, but objections were raised that having too good and too broad an unlitter might lead to the bit-rot of the flag to employ external unlitters. I didn't quite understand that objection, but didn't pursue it) > > Regards, > Philip > > > ________________________________________ > Van: Glasgow-haskell-users <glasgow-haskell-users-bounces(a)haskell.org> namens Merijn Verstraaten <merijn(a)inconsistent.nl> > Verzonden: zaterdag 16 augustus 2014 00:40 > Aan: haskell-prime(a)haskell.org; glasgow-haskell-users(a)haskell.org > Onderwerp: Revival: PROPOSAL: Literate haskell and module file names > > Ola! > > I raised this proposal earlier this year and got to busy to follow up, this week I was suddenly reminded and decided to reraise this. To summarise the discussion up until this point: > > There was no real opposition to the general idea, the only real objection to the original proposal was that “Foo.lhs.md” and “Foo.md.lhs” would collide with the naming scheme used by JHC on case insensitive filesystems. Alternative proposal raised during the discussion: "Foo+md.lhs", "Foo.lhs+md” and “Foo.md+lhs”. > > According to MS documentation and testing the + should not be an issue on windows, the + doesn’t collide with any other haskell compiler (at least, not any I’m aware off) and since the report doesn’t specify any module name resolution mechanism, it does not conflict with the report either. > > My personal preferences goes to either “.lhs+md” or “.md+lhs”, since GHC currently tries every alternative in turn, I propose to just extend this list to look for any file whose extension is “.lhs+*” or “.*+lhs”. > > Are there any objections to this? If not, I’m just going to produce a patch + ticket as there were no real objections to the proposal last time. > > Cheers, > Merijn > > On 16 Mar 2014, at 05:56 , Merijn Verstraaten <merijn(a)inconsistent.nl> wrote: >> Ola! >> >> I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. >> >> Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) >> >> The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. >> >> Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. >> >> I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. >> >> Pros: >> - Tool authors can more easily determine non-haskell content of literate haskell files >> - Currently valid module names will not break >> - Report doesn't specify behaviour, so GHC can do whatever it likes >> >> Cons: >> - Someone has to implement it >> - ?? >> >> Discussion: 4 weeks >> >> Cheers, >> Merijn >>

1 0

PROPOSAL: Literate haskell and module file names
by Merijn Verstraaten 15 Aug '14

15 Aug '14

Ola! I didn't know what the most appropriate venue for this proposal was so I crossposted to haskell-prime and glasgow-haskell-users, if this isn't the right venue I welcome advice where to take this proposal. Currently the report does not specify the mapping between filenames and module names (this is an issue in itself, it essentially makes writing haskell code that's interoperable between compilers impossible, as you can't know what directory layout each compiler expects). I believe that a minimal specification *should* go into the report (hence, haskell-prime). However, this is a separate issue from this proposal, so please start a new thread rather than sidetracking this one :) The report only mentions that "by convention" .hs extensions imply normal haskell and .lhs literate haskell (Section 10.4). In the absence of guidance from the report GHC's convention of mapping module Foo.Bar.Baz to Foo/Bar/Baz.hs or Foo/Bar/Baz.lhs seems the only sort of standard that exists. In general this standard is nice enough, but the mapping of literate haskell is a bit inconvenient, it leaves it completelyl ambiguous what the non-haskell content of said file is, which is annoying for tool authors. Pandoc has adopted the policy of checking for further file extensions for literate haskell source, e.g. Foo.rst.lhs and Foo.md.lhs. Here .rst.lhs gets interpreted as being reStructured Text with literate haskell and .md.lhs is Markdown with literate haskell. Unfortunately GHC currently maps filenames like this to the module names Foo.rst and Foo.md, breaking anything that wants to import the module Foo. I would like to propose allowing an optional extra extension in the pandoc style for literate haskell files, mapping Foo.rst.lhs to module name Foo. This is a backwards compatible change as there is no way for Foo.rst.lhs to be a valid module in the current GHC convention. Foo.rst.lhs would map to module name "Foo.rst" but module name "Foo.rst" maps to filename "Foo/rst.hs" which is not a valid haskell module anyway as the rst is lowercase and module names have to start with an uppercase letter. Pros: - Tool authors can more easily determine non-haskell content of literate haskell files - Currently valid module names will not break - Report doesn't specify behaviour, so GHC can do whatever it likes Cons: - Someone has to implement it - ?? Discussion: 4 weeks Cheers, Merijn

5 7

Proposal: Treat OtherLetter as lower case in the grammar
by Edward Kmett 14 Aug '14

14 Aug '14

Back in 2008 or so, GHC changed the behavior of unicode characters in the parser that parse as OtherLetter to make them parse as lower case so that languages like Japanese that lack case could be used in identifier names: https://ghc.haskell.org/trac/ghc/ticket/1103 In a recent thread on reddit Lennart Augustsson pointed out that this change was never backported to Haskell'. http://www.reddit.com/r/haskell/comments/2dce3d/%E0%B2%A0_%E0%B2%A0_string_… Would it make sense to adopt this change in the language standard? Marlow when he made the change to GHC noted he was considering bringing it up to Haskell' but here we are 6 years later. -Edward Kmett

2 1

Infix declaration: digit or integer?
by Björn Peemöller 07 Aug '14

07 Aug '14

Hello Haskell-Prime, I just discovered that the Haskell 2010 report allows the precedence of infix declarations to be an integer instead of just a digit. Therefore, also the following declarations are allowed: -- compiles infix 0x7 <$> infix 0o7 <$> -- does not compile because of precedence out of range infix 0xa <$> infix 0oa <$> infix 123 <$> Interestingly, the in section 4.4.2 (Fixity Declarations) the report says: > The *integer* in a fixity declaration must be in the range 0 to 9. as well as > If the *digit* is omitted, level 9 is assumed. This is of course no problem, I'm just curious if there is some motivation for integer I'm not aware of. Kind Regards, Björn

1 0

Proposal - Foreign enum support
by Merijn Verstraaten 19 Apr '14

19 Apr '14

Cross-post to haskell-prime in case there's any interest for including this into the report's FFI specification. Proposal - Foreign enum support =============================== At the moment the FFI does not have a convenient way with interacting enums (whether proper enums or CPP defines) in C (like languages). Both enums and CPP defined enums are major parts of large C APIs and they are thus crucial to writing foreign bindings. A few examples: SDL_image defines the following enum: typedef enum { IMG_INIT_JPG = 0x00000001, IMG_INIT_PNG = 0x00000002, IMG_INIT_TIF = 0x00000004, IMG_INIT_WEBP = 0x00000008 } IMG_InitFlags; OpenCL specifies the following typedefs + CPP defined enum: typedef uint32_t cl_uint __attribute__((aligned(4))); typedef cl_uint cl_platform_info; /* cl_platform_info */ #define CL_PLATFORM_PROFILE 0x0900 #define CL_PLATFORM_VERSION 0x0901 #define CL_PLATFORM_NAME 0x0902 #define CL_PLATFORM_VENDOR 0x0903 #define CL_PLATFORM_EXTENSIONS 0x0904 OpenCL functions will return the above CPP defines as return values of type cl_platform_info. Current Solutions ----------------- In many cases someone wrapping such a C library would like to expose these enums as a simple sum type as this has several benefits: type safety, the ability to use haskell constructors for pattern matching, exhaustiveness checks. Currently the GHC FFI, as specified by Haskell2010, only marshalls a small set of foreign types and newtypes with exposed constructors of these types. As such there seem two approaches to wrap these enums: 1. Implement an ADT representing the enum and write a manual conversion function between the ADT and the corresponding C type (e.g. CInt -> Foo and Foo -> CInt). 2. Use a tool like c2hs to automatically generate the ADT and conversion function. In both cases the foreign functions are imported using the corresponding C type in their signature (reducing type safety) and the user is forced write trivial wrappers for every imported function to convert the ADT to the relevant C type and back. This is both tedious to write and costly in terms of code produced, in case of c2hs one calls "toEnum . fromIntegral" and "fromIntegral . fromEnum" for every argument/result even though this could trivially be a no-op. Worse, since c2hs uses the Enum class for it's conversion to/from C types it generates Enum instances like: instance Enum Foo where fromEnum Bar = 1 fromEnum Baz = 1337 toEnum 1 = Bar toEnum 1337 = Baz toEnum unmatched = error ("PlatformInfo.toEnum: Cannot match " ++ show unmatched) Since succ/pred and enumFromTo's default implementations assume enums convert to continuous sequence of Int this means the default generated enum instances crash. This problem could be overcome by making c2hs' code generation smarter, but this does not eliminate the tediousness of wrapping all foreign imported functions with marshalling wrappers, NOR does it eliminate the overhead of all this useless marshalling. Proposal -------- Add a new foreign construct for enums, the syntax I propose below is rather ugly and ambiguous and thereforeopen to bikeshedding, but I prefer explaining based on a concrete example. foreign enum CInt as Foo where Bar = 1 Baz Quux = 1337 Xyzzy = _ This would introduce a new type 'Foo' with semantics approximately equivalent too "newtype Foo = Foo CInt" plus the pattern synonyms "pattern Bar = Foo 1; pattern Baz = 2; pattern Quux = 1337; pattern Xyzzy = Foo _". Explicit listing of the value corresponding to a constructor should be optional, missing values should just increment by one from the previous (like C), if the initial value is missing, it should assume to start from 0. Values do not need to be contiguous. Users should be able to use these constructors as normal in pattern match (really, this mostly follows to semantics of the above pattern synonyms). The foreign import/export functionality should invisibly marshall Foo to the underlying foreign type (as is done for newtypes). I'm unsure about the support for a wildcard constructor like Xyzzy. If there is support for a wildcard, it should be optional. On the upside a wildcard means the marshalling is no longer a partial function. The downside is that it makes desugaring the use of enums in patterns harder. It seems clear that f Xyzzy = {- ... -} f Bar = {- ... -} f Baz = {- ... -} f Quux = {- ... -} Should not have the same semantics as: f (Foo _) = {- ... -} f (Foo 1) = {- ... -} f (Foo 2) = {- ... -} f (Foo 1337) = {- ... -} So in the presence of wildcards, the Foo enum can't trivially be desugared into pattern synonyms after checking exhaustiveness. Pros: 1. Foreign imports are slightly more type safe, as one can now write: foreign import ccall "someFoo.h" someFoo :: Foo -> Ptr () -> IO () Preventing users from passing an arbitrary CInt to an argument expecting a specific enum. 2. No need to write marshalling functions to/from ADT to obtain exhaustiveness checks and pattern matching 3. Cheaper as marshalling Foo to CInt is a no-op 4. toEnum/fromEnum can simply map to contiguous sequence of Int as this Int mapping is no longer used for marshalling Cons: 1. Non-standard extension of the FFI 2. Someone has to implement it 3. Wildcards constructors would present difficulties desugaring pattern matches to a simple newtype. 4. ?? What Would Need to be Done? --------------------------- 1. Parser needs to be extended to deal with parsing of enum declarations. 2. Pattern matches of an enum type need to be checked for exhaustiveness and desugared to the underlying type's representation. 3. Extend foreign imports/exports to marshall enums properly. If there's no objections I'm willing to take a stab at implementing this, although I'd probably need some help with GHC's internals (although I could bug #ghc for that). Cheers, Merijn

3 2

Trac detected an internal error
by Henk-Jan van Tuyl 03 Feb '14

03 Feb '14

L.S., I am trying to register as a user in the Haskell prime trac, but I get the error message: --------------------------- Oops… Trac detected an internal error: IOError: [Errno 2] No such file or directory: '' There was an internal error in Trac. It is recommended that you notify your local Trac administrator with the information needed to reproduce the issue. To that end, you could a ticket. The action that triggered the error was: POST: /register TracGuide — The Trac User and Administration Guide --------------------------- I tried to register with the browsers Opera, FireFox and Internet Explorer; each gave the same message. Regards, Henk-Jan van Tuyl -- Folding@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 --

1 0