[Haskell-cafe] Munich Haskell Meeting
Dear all, we will meet again for our monthly Haskell Meeting in Munich on the 26th of April, at 19h30 at Cafe Puck. If you plan to join, please go to the site an click the button in order to reserve enough tables: http://www.haskell-munich.de/dates Also, consider joining us for our local Hackathon which will be held on Saturday, the 12th of May. See the details on the site. Until then, I wish all of you a good time, Heinrich -- -- hoerde...@funktional.info www.funktional.info -- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Correspondence between libraries and modules
On 4/22/12 6:30 PM, Alvaro Gutierrez wrote: On Sun, Apr 22, 2012 at 4:45 PM, Brandon Allberywrote: One reason: modules serve multiple purposes; one of these is namespacing, and in the case of interfaces to foreign libraries that may force a division that would otherwise not exist. Interesting. Could you elaborate on what the other purposes are, and perhaps point to an instance of the foreign library case? The main purpose of namespacing (IMO) is to separate concerns and make it easier to figure out how a project fits together. The primary goal of modules is to resolve namespacing issues. Consider one of my own libraries (chosen randomly via Safari's url autocompletion): http://hackage.haskell.org/package/bytestring-lexing When I inherited this package there were the Data.ByteString.Lex.Double and Data.ByteString.Lex.Lazy.Double modules, which were separated because they provide the same API but for strict vs lazy ByteStrings. Both of those modules are concerned with lexing floating point numbers. I inherited the package because I wanted to publicize some code I had for lexing integers in various formats. Since that's quite a different task than lexing floating point numbers, I put it in its own module: Data.ByteString.Lex.Integral. When dealing with FFI code, because of the impedance mismatch between Haskell and imperative languages like C, it's clear that there's going to be some massaging of the API beyond simply declaring FFI calls. As such, clearly we'd like to have separate modules for doing the low-level binding vs presenting a high-level API. Moreover, depending on what you're interfacing with, you may be forced to have multiple low-level modules. For example, if you use Google protocol buffers via the hprotoc package, then it will generate a separate module for each buffer type. That's fine, but usually it's not something you want to foist on your users. On the other hand, the main purpose of packages or libraries is as unit of distribution, code reuse, and separate compilation. Even with the Haskell culture of making small libraries, most worthwhile units of distribution/reuse/compilation tend to be larger than a single namespace/concern. Thus, it makes sense to have more than one module per package, because otherwise we'd need some higher level mechanism in order to manage the collections of package-modules which should be considered a single unit (i.e., clients will almost always want the whole bunch of them). However, centralization is prone to bottlenecks and systemic failure. As such, while it would be nice to ensure that a given module is provided by only one package, there is no mechanism in place to enforce this (except at compile time for the code that links the conflicting modules together). With few exceptions, it's considered bad form to knowingly use the same module name as is being used by another package. In part, it's bad form because egos are involved; but it's also bad form because there's poor technical support for resolving namespace collisions for module names. In GHC you can use -XPackageImports, which is workable but conflates issues of code with issues of provenance, which the Haskell Report intentionally keeps separate. However, until better technical support is implemented (not just for GHC, but also jhc, UHC,...) it's best to follow social practice. I'm confused as to how type families vs. fundeps play a role here -- as far as I can tell both are compiler extensions that do not provide modules. Both TFs (or rather associated types) and fundeps aim to solve the same problem. Namely: when using multi-parameter type classes, it is often desirable to declare that one parameter is wholly defined by other parameters, either for semantic reasons or (more often) to help type inference. Since they both aim to solve the same problem, this raises a new problem: for some given type class, do I implement it with TF/ATs or with fundeps? Some people figured to solve the new issue by implementing it both ways in separate packages, but reusing the same module names. (Witness for example mtl-2 aka monads-fd, vs monads-tf.) In practice, that didn't work out so well. Part of the reason for failure is that although fundeps and TF/ATs are formally equivalent in theory, in practice the implementation of TF/ATs has(had?) been missing some necessary machinery, and consequentially the TF/AT versions were not as powerful as the original fundep versions. Though the butterfly dependency issues certainly didn't help. I'm interested to see examples where two or more well-known yet unrelated modules clash under the same name; I can't imagine them coexisting in public very long -- wouldn't the confusion among users (e.g. when looking for documentation) be enough to either reconcile the modules or change one of the names? That's not much of a problem in practice. There are lots of different books with a Chapter 1,
[Haskell-cafe] Data-Type Serialization
Hi Café. I'm pondering over an old chestnut that I'd forgotten about until recently. I'd like to be able to express schemas for general recursive datatypes (excluding functions and possibly encoding bounds) and have an interactive constructor for that datatype generated automatically. Originally this idea came about as an XML/JS framework for creating advanced form inputs on the client-side, however, I'm interested in how this could be implemented idiomatically in Haskell. I'm guessing that the best way to go about this would be to capture the declaration in template Haskell, having a passthrough for the declaration itself, and also generating a representation that can be used for introspection and the creation of the interactive component. Ideally I'd like to integrate this concept into one of the web-frameworks such as Yesod so that complicated data-types can be constructed interactively on the client-side using (generated) javascript in order to get instantaneous feedback about validity of fields, etc, and avoid page reloads and even ajax communication. The details of the web-side of things would probably be quite messy, but if the Haskell side can be made general enough then this can be considered a separate problem :-) Has anyone had experience with trying to solve this, or a similar issue? What approach did you take? Did you use Template-Haskell, or something else? Thanks! ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Correspondence between libraries and modules
Thanks for your response. On Sun, Apr 22, 2012 at 4:45 PM, Brandon Allbery wrote: > One reason: modules serve multiple purposes; one of these is namespacing, > and in the case of interfaces to foreign libraries that may force a > division that would otherwise not exist. > Interesting. Could you elaborate on what the other purposes are, and perhaps point to an instance of the foreign library case? More generally, making libraries and modules one-to-one means that either > modules exist solely for libraries, or libraries must be artificially > split. Perhaps this indicates that modules have too many other functions, > but in that case you should propose an alternative system to replace them. > Oh, I don't intend to replace it -- at most I want to understand why the system is set up the way it is, what the cons/pros are, and so on. I've come across a lot of design discussions for various Haskell features, but not this one; are there any? As to multiple libraries providing the same module: the Haskell ecosystem > is still evolving and it's not always appropriate to give a particular > implementation sole ownership of a general module name. Type families vs. > functional dependencies are an example of this (theoretically type families > were considered superior but to date they haven't lived up to it and > recently some cases were shown that fundeps can solve but type families > can't; parallel monad libraries based on both still exist). New container > implementations have existed as standalone packages, some of which later > merge with standard packages while others are discarded. > I see. I didn't imagine there was as much variability with respect to module names and implementations as you suggest. I'm confused as to how type families vs. fundeps play a role here -- as far as I can tell both are compiler extensions that do not provide modules. I'm interested to see examples where two or more well-known yet unrelated modules clash under the same name; I can't imagine them coexisting in public very long -- wouldn't the confusion among users (e.g. when looking for documentation) be enough to either reconcile the modules or change one of the names? > Your proposal to reject this reflects a static library ecosystem that does > not exist. (It could be enforced dictatorially, but there is no Guido van > Rossum of Haskell and a mistake in an evolving system is difficult to fix > after the fact even with a dictator; we're already living with some > difficult to fix issues not related to modules.) > Right, assuming there could only be one implementation of a module, this is one of the main drawbacks; on the flip side, it is a "feature" in that there is no confusion as to what Foo.Bar.Qux means. As it is, any import requires out-of-band information in order to be resolved (both cognitively and by the compiler), in the form of the library it comes from. (There's also versioning information, but that could be equally specified per-library or per-module.) On the other hand, enforcing a single implementation is orthogonal to having a 1-to-1 module/library mapping. That is, you could allow multiple implementations either way. Alvaro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Correspondence between libraries and modules
On Sun, Apr 22, 2012 at 13:15, Alvaro Gutierrez wrote: > As I understand it, a library can provide any number of unrelated modules, > and conversely, a single module could be provided by more than one library. > I can see how this affords library authors more flexibility, but at a cost: > there is no longer a single, unified view of the library universe. (The > alternative would be for every module to be its own, hermetic library.) So > I'm very interested in the rationale behind that aspect of the library > system. > One reason: modules serve multiple purposes; one of these is namespacing, and in the case of interfaces to foreign libraries that may force a division that would otherwise not exist. More generally, making libraries and modules one-to-one means that either modules exist solely for libraries, or libraries must be artificially split. Perhaps this indicates that modules have too many other functions, but in that case you should propose an alternative system to replace them. As to multiple libraries providing the same module: the Haskell ecosystem is still evolving and it's not always appropriate to give a particular implementation sole ownership of a general module name. Type families vs. functional dependencies are an example of this (theoretically type families were considered superior but to date they haven't lived up to it and recently some cases were shown that fundeps can solve but type families can't; parallel monad libraries based on both still exist). New container implementations have existed as standalone packages, some of which later merge with standard packages while others are discarded. Your proposal to reject this reflects a static library ecosystem that does not exist. (It could be enforced dictatorially, but there is no Guido van Rossum of Haskell and a mistake in an evolving system is difficult to fix after the fact even with a dictator; we're already living with some difficult to fix issues not related to modules.) -- brandon s allbery allber...@gmail.com wandering unix systems administrator (available) (412) 475-9364 vm/sms ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Embed Haskell
Hi Rosario,
lhs2tex [1] has the '\eval' command. See section 12 of the manual.
Erik
[1] http://www.andres-loeh.de/lhs2tex/
On Sun, Apr 22, 2012 at 17:59, Rosario Borda wrote:
> Hi All,
>
> Is there a simple method for embed haskell in other languages, like latex?
>
> An example in quasiquotation notation:
>
> \documentclass{article}
> \title{Hello World}
> \begin{document}
> \maketitle
> Hello world! and reversed: [haskell: putStrLn reverse "Hello, World!"]
> \end{document}
>
> Many thanks, :)
> Rosario
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
Isn't this a special case already? I.e you already can default a string literal to anything you want, the only thing needed is a language pragma (and more obvious docs). The only "problem" is, that it's not part of the Haskell2010 report, and thus not supported in other compilers (or is it?). On Sun, Apr 22, 2012 at 8:51 PM, Johan Tibell wrote: > On Sun, Apr 22, 2012 at 10:37 AM, Brent Yorgey wrote: >> I do not think this is a bug. Since type classes are open, GHC does >> not do any reasoning of the form "X is the only instance in scope, so >> I will pick that one". Other instances could be added at any time >> (perhaps in other modules). In this particular instance, GHC has no >> reason to choose the Text instance other than the fact that it is the >> only instance in scope -- that is, type inference is not enough to >> determine that the Text instance should be chosen. >> >> However, I do agree that it would be nice to have a mechanism for >> specifying default instances for arbitrary (user-defined) type >> classes. > > Couldn't we make a special case for IsString, like we do for Num, > given it's special syntactic association with OverloadedStrings? > > -- Johan > > ___ > Glasgow-haskell-users mailing list > glasgow-haskell-us...@haskell.org > http://www.haskell.org/mailman/listinfo/glasgow-haskell-users -- Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Correspondence between libraries and modules
Hi there, I've only dabbled in Haskell, so please excuse my ignorance: why isn't there a 1-to-1 mapping between libraries and modules? As I understand it, a library can provide any number of unrelated modules, and conversely, a single module could be provided by more than one library. I can see how this affords library authors more flexibility, but at a cost: there is no longer a single, unified view of the library universe. (The alternative would be for every module to be its own, hermetic library.) So I'm very interested in the rationale behind that aspect of the library system. Thanks! Alvaro ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Embed Haskell
Hi All,
Is there a simple method for embed haskell in other languages, like latex?
An example in quasiquotation notation:
\documentclass{article}
\title{Hello World}
\begin{document}
\maketitle
Hello world! and reversed: [haskell: putStrLn reverse "Hello, World!"]
\end{document}
Many thanks, :)
Rosario
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
so how can I update the documentation? I asked some of the most experienced Haskell users at the Hackathon about this, and looked through any documentation I could find and there was nothing indicating I could do what you sent in your last message. On Sun, Apr 22, 2012 at 8:15 AM, Markus Läll wrote: > The core of it is in the GHC docs' overloaded strings section [1]. > > It could be clearer though -- reading about defaulting in the reports, > in the type defaulting section of GHC docs and in [1] can be a bit > confusing. > > [1] > http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings > > On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber wrote: >> Thanks Markus, I think you have saved the day! >> Even after googling for this extension and searching in the manual I >> am still coming up pretty blank. >> Is there somewhere I missed where this is documented or somewhere I >> can contribute documentation? >> >> On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll wrote: >>> ExtendedDefaultRules > > > > -- > Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
The core of it is in the GHC docs' overloaded strings section [1]. It could be clearer though -- reading about defaulting in the reports, in the type defaulting section of GHC docs and in [1] can be a bit confusing. [1] http://www.haskell.org/ghc/docs/latest/html/users_guide/type-class-extensions.html#overloaded-strings On Sun, Apr 22, 2012 at 4:54 PM, Greg Weber wrote: > Thanks Markus, I think you have saved the day! > Even after googling for this extension and searching in the manual I > am still coming up pretty blank. > Is there somewhere I missed where this is documented or somewhere I > can contribute documentation? > > On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll wrote: >> ExtendedDefaultRules -- Markus Läll ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
Thanks Markus, I think you have saved the day! Even after googling for this extension and searching in the manual I am still coming up pretty blank. Is there somewhere I missed where this is documented or somewhere I can contribute documentation? On Sun, Apr 22, 2012 at 4:47 AM, Markus Läll wrote: > ExtendedDefaultRules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] static linking with ghc?
Scott Lawrence gmail.com> writes: > Adding -optl-pthread fixes it for me. great! in my case, I also needed to add '-pgml g++' and together, this seems to work. Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] static linking with ghc?
On 22 April 2012 22:33, Johannes Waldmann wrote: > Hi. > > I want to produce a statically linked executable. > I am trying 'ghc --make -fforce-recomp -static -optl-static Main' > > but it gives lots of errors like > (.text+0xfa): undefined reference to `pthread_mutex_unlock' > collect2: ld returned 1 exit status I believe this is due to C libraries that are used in GHC's RTS; all Haskell libs are statically linked by default. > > A similar thing is mentioned here (see Caveat) > http://www.haskell.org/haskellwiki/Web/Literature/Static_linking > > The ghc user guide talks a great length about shared libs > http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.html > but I don't see anything on how to switch this off. > > - J.W. > > > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] static linking with ghc?
Adding -optl-pthread fixes it for me. On Sun, 22 Apr 2012, Johannes Waldmann wrote: Hi. I want to produce a statically linked executable. I am trying 'ghc --make -fforce-recomp -static -optl-static Main' but it gives lots of errors like (.text+0xfa): undefined reference to `pthread_mutex_unlock' collect2: ld returned 1 exit status A similar thing is mentioned here (see Caveat) http://www.haskell.org/haskellwiki/Web/Literature/Static_linking The ghc user guide talks a great length about shared libs http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.html but I don't see anything on how to switch this off. - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Scott Lawrence ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] static linking with ghc?
Hi. I want to produce a statically linked executable. I am trying 'ghc --make -fforce-recomp -static -optl-static Main' but it gives lots of errors like (.text+0xfa): undefined reference to `pthread_mutex_unlock' collect2: ld returned 1 exit status A similar thing is mentioned here (see Caveat) http://www.haskell.org/haskellwiki/Web/Literature/Static_linking The ghc user guide talks a great length about shared libs http://www.haskell.org/ghc/docs/latest/html/users_guide/using-shared-libs.html but I don't see anything on how to switch this off. - J.W. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] default instance for IsString
Hi Greg
You *can* have what you want -- enable extended defaulting and set
Text as default by
> {-# LANGUAGE ExtendedDefaultRules #-}
> default (Integer, Double, T.Text) -- keep the default defaults
At the moment you only by chance have one instance of NoDefault in
scope, which is why it shouldn't work at the moment.
(ExtendedDefaultRules is required because the standard defaulting
rules apply only when defaulting numeric literals.)
On Sun, Apr 22, 2012 at 7:55 AM, Greg Weber wrote:
> This is a better demonstration of the issue. I am going to open a GHC
> bug report, as I can't see how this behavior is desirable.
>
>
> {-# LANGUAGE OverloadedStrings #-}
> import Data.Text as T
>
> class NoDefault a where noDefault :: a -> Text
> instance NoDefault T.Text where noDefault = id
>
> main = print (noDefault "Hello!")
>
> default.hs:7:15:
> Ambiguous type variable `a0' in the constraints:
> (NoDefault a0) arising from a use of `noDefault'
> at default.hs:7:15-23
> (Data.String.IsString a0) arising from the literal `"Hello!"'
> at default.hs:7:25-32
> Probable fix: add a type signature that fixes these type variable(s)
> In the first argument of `print', namely `(noDefault "Hello!")'
> In the expression: print (noDefault "Hello!")
> In an equation for `main': main = print (noDefault "Hello!")
>
>
> On Sat, Apr 21, 2012 at 7:51 PM, Greg Weber wrote:
>> my actual use case looks more like this:
>>
>> {-# LANGUAGE OverloadedStrings #-}
>> {-# LANGUAGE FlexibleInstances, TypeSynonymInstances #-}
>>
>> import Data.Text as T
>>
>> class ShowT a where
>> showT :: a -> String
>>
>> instance ShowT T.Text where
>> showT = show
>>
>> instance ShowT String where
>> showT = show
>>
>> main = print (showT "Hello!")
>>
>> Ambiguous type variable `a0' in the constraints:
>> (ShowT a0) arising from a use of `showT' at default.hs:16:15-19
>> (Data.String.IsString a0) arising from the literal `"Hello!"'
>>
>>
>> So I actually want to define a default instance for a typeclass I
>> define that uses isString instances.
>>
>>
>>
>> On Sat, Apr 21, 2012 at 6:24 PM, Daniel Peebles wrote:
>>> I think it'll be hard to do that without putting Text in base, which I'm not
>>> sure anyone wants to do.
>>>
>>> Dan
>>>
>>> On Sat, Apr 21, 2012 at 8:20 PM, Greg Weber wrote:
I would like to default IsString to use the Text instance to avoid
ambiguous type errors.
I see defaulting capability is available for Num. Is there any way to
do this for IsString?
Thanks,
Greg Weber
___
Glasgow-haskell-users mailing list
glasgow-haskell-us...@haskell.org
http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>>>
>>>
>
> ___
> Glasgow-haskell-users mailing list
> glasgow-haskell-us...@haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
--
Markus Läll
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] "desactivate" my Show instance implementations temporarily
On 22 April 2012 19:55, TP wrote: > On Sunday 22 April 2012 19:37:19 Ivan Lazar Miljenovic wrote: > >> Is there any particular reason you're *not* using the defaults? > > This is a good question which I have asked myself. I have searched about the > topic, and found that: > > http://blog.romanandreg.com/post/13545420287/haskells-show-and-pretty- > printing-bad-practice > > So, according to this address, Show implementation should be used with Read so > as to have show.read equal to identity: this is the only "good practice > requirement". > > In my case, I use Show to print mathematical expressions, but it is not > strictly pretty printing (not over several lines as in classical Computer > Algebra Sytems). Why not using my own Show implementation to do that? For exactly the same reason you're discovering: Show/Read exist for debugging. Show and Read are meant to produce/read valid Haskell code (modulo [qualified] imports) so that you can work out what code is going wrong (and coincidentally used as a quick`n`dirty serialisation method). The term "pretty-printing" is meant in regards to producing _human-readable_ versions of your data (though the pretty-printing libraries can also be used to produce code formatted for some other tool to parse, etc.). Show/Read happen to be auto-derivable classes that implement one such form of pretty-printing (i.e. "printing" values that look like the actual source code that represents them). Let me provide you with a personal anecdote: when I took over maintaining the graphviz library, it was still using the Show class for printing (but a proper parser library for parsing), and it was working with the limited functionality it had. However, whenever I tried to do something new, I found problems: * Existing Show instances meant that it was very difficult to extend what the library could represent and then print properly. * As you've found, it can then be a PITA to debug because you have no idea what the internal values actually are. In the end, I eventually wrote a custom pretty-printing class (the existing pretty-printing classes had instances that didn't suit, just like Show) and it's worked a lot better since. The only time it's valid to override the default Show/Read instances is when the constructors aren't exported (e.g. Data.Map), but even then it should be valid Haskell (if you ignore imports, etc.). So leave Show/Read as they are, and write a custom function[s] that does the actual pretty-printing you want. -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] "desactivate" my Show instance implementations temporarily
On Sunday 22 April 2012 19:37:19 Ivan Lazar Miljenovic wrote: > Is there any particular reason you're *not* using the defaults? This is a good question which I have asked myself. I have searched about the topic, and found that: http://blog.romanandreg.com/post/13545420287/haskells-show-and-pretty- printing-bad-practice So, according to this address, Show implementation should be used with Read so as to have show.read equal to identity: this is the only "good practice requirement". In my case, I use Show to print mathematical expressions, but it is not strictly pretty printing (not over several lines as in classical Computer Algebra Sytems). Why not using my own Show implementation to do that? TP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] "desactivate" my Show instance implementations temporarily
On 22 April 2012 19:11, TP wrote: > Hello, > > I have a module where I have made several types as instances of the Show > typeclass. > > For debugging purpose, I would like to use the default implementation for Show > (the one obtained when using "deriving", which shows all the constructors). Is > there some option to do that, or have I to comment all the Show instances of > my code, and add "Show" in "deriving (...)" for each of my types? If this is > the only possibility, is there some script around here to do that > automatically? Is there any particular reason you're *not* using the defaults? > > Thanks in advance, > > TP > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com http://IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] "desactivate" my Show instance implementations temporarily
On Sun, Apr 22, 2012 at 11:11:51AM +0200, TP wrote: > Hello, > > I have a module where I have made several types as instances of the Show > typeclass. > > For debugging purpose, I would like to use the default implementation for > Show > (the one obtained when using "deriving", which shows all the constructors). > Is > there some option to do that, or have I to comment all the Show instances of > my code, and add "Show" in "deriving (...)" for each of my types? If this is > the only possibility, is there some script around here to do that > automatically? > > Thanks in advance, > > TP You could use some preprocessor's #if/#else/#endif pragmas. See here: http://stackoverflow.com/questions/6556778/using-if-else-endif-in-haskell L. -- Lorenzo Bolla http://lbolla.info pgppqbachV6j0.pgp Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] "desactivate" my Show instance implementations temporarily
Hello, I have a module where I have made several types as instances of the Show typeclass. For debugging purpose, I would like to use the default implementation for Show (the one obtained when using "deriving", which shows all the constructors). Is there some option to do that, or have I to comment all the Show instances of my code, and add "Show" in "deriving (...)" for each of my types? If this is the only possibility, is there some script around here to do that automatically? Thanks in advance, TP ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] http-enumerator: users?
OK, since no one seems interested in it anymore, I've deprecated the package. On Thu, Apr 19, 2012 at 12:33 PM, Michael Snoyman wrote: > Hi all, > > I'm wondering if there are still active users out there of > http-enumerator. Four months ago I released http-conduit, and since > then, my development efforts have gone almost exclusively there. At > this point, I'm not longer actively using http-enumerator on any of my > projects, and while I've backported any security fixes to > http-enumerator, it is otherwise not be updated. > > I see three possibilities for the future of http-enumerator: > > 1. Deprecate it in favor of http-conduit > 2. Someone else takes over as maintainer > 3. Turn it into a frontend for http-conduit, exposing an enumerator > interface. This will likely, though not necessarily, result in API > breakage > > I'm curious how others feel on this. If I don't hear anything back on > the topic, I'll assume that no one is interested in http-enumerator, > and thus will opt for option (1). > > Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
