[Haskell-cafe] Call for Contributions - Haskell Communities and Activities Report, November 2010 edition
Dear all, It is time to collect contributions for the 19th edition of the Haskell Communities Activities Report http://www.haskell.org/communities/ Submission deadline: 1 November 2010 (please send your contributions to hcar at haskell.org, in plain text or LaTeX format) This is the short story: * If you are working on any project that is in some way related to Haskell, please write a short entry and submit it. Even if the project is very small or unfinished or you think it is not important enough -- please reconsider and submit an entry anyway! * If you are interested in an existing project related to Haskell that has not previously been mentioned in the HCAR, please tell me, so that I can contact the project leaders and ask them to submit an entry. * Feel free to pass on this call for contributions to others that might be interested. More detailed information: The Haskell Communities Activities Report is a bi-annual overview of the state of Haskell as well as Haskell-related projects over the last, and possibly the upcoming six months. If you have only recently been exposed to Haskell, it might be a good idea to browse the May 2010 edition -- you will find interesting topics described as well as several starting points and links that may provide answers to many questions. Contributions will be collected until the submission deadline. They will then be compiled into a coherent report that is published online as soon as it is ready. As always, this is a great opportunity to update your webpages, make new releases, announce or even start new projects, or to talk about developments you want every Haskeller to know about! Looking forward to your contributions, Janis (current editor) FAQ: Q: What format should I write in? A: The required format is a LaTeX source file, adhering to the template that is available at: http://haskell.org/communities/11-2010/template.tex There is also a LaTeX style file at http://haskell.org/communities/11-2010/hcar.sty that you can use to preview your entry. If you do not know LaTeX, then use plain text. If you modify an old entry that you have written for an earlier edition of the report, you should already have received your old entry as a template (provided I have your valid email address). Please modify that template, rather than using your own version of the old entry as a template. Q: Can I include images? A: Yes, you are even encouraged to do so. Please use .jpg format, then. Q: Should I send files in .zip archives or similar? A: No, plain file attachements are the way. If you have several entries to submit, it helps if you send them in separate emails. Q: How much should I write? A: Authors are asked to limit entries to about one column of text. This corresponds to approximately one page, or 40 lines of text, with the above style and template. A general introduction is helpful. Apart from that, you should focus on recent or upcoming developments. Pointers to online content can be given for more comprehensive or historic overviews of a project. Images do not count towards the length limit, so you may want to use this opportunity to pep up entries. There is no minimum length of an entry! The report aims for being as complete as possible, so please consider writing an entry, even if it is only a few lines long. Q: Which topics are relevant? A: All topics which are related to Haskell in some way are relevant. We usually had reports from users of Haskell (private, academic, or commercial), from authors or contributors to projects related to Haskell, from people working on the Haskell language, libraries, on language extensions or variants. We also like reports about distributions of Haskell software, Haskell infrastructure, books and tutorials on Haskell. Reports on past and upcoming events related to Haskell are also relevant. Finally, there might be new topics we do not even think about. As a rule of thumb: if in doubt, then it probably is relevant and has a place in the HCAR. You can also ask the editor. Q: Is unfinished work relevant? Are ideas for projects relevant? A: Yes! You can use the HCAR to talk about projects you are currently working on. You can use it to look for other developers that might help you. You can use it to write wishlist items for libraries and language features you would like to see implemented. Q: If I do not update my entry, but want to keep it in the report, what should I do? A: Tell the editor that there are no changes. The old entry will typically be reused in this case, but it might be dropped if it is older than a year, to give more room and more attention to projects that change a lot. Do not resend complete entries if you have not changed them.
Re: [Haskell-cafe] Re: A question regarding cmdargs package
This makes me curious. What's the use case where you want to allow the user to pass arguments on the command line, but you don't want that user to be able to use '--help' to find out what arguments may be passed? When you don't want to bother defining the help options/descriptions? :p (alternatively, you may wish to provide a more full-featured version like what darcs does by using a pager) You can already do this with CmdArgs. If you use cmdArgsMode/process it returns a structure populated to say what to do next (i.e. display a help message), but you are welcome to do something different, or do what it says in a different way. However, I can see some people might want to remove help entirely, so I'll try and find a balance. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Eta-expansion destroys memoization?
Simon Marlow wrote: Interesting. You're absolutely right, GHC doesn't respect the report, on something as basic as sections! The translation we use is (e op) == (op) e once upon a time, when the translation in the report was originally written (before seq was added) this would have been exactly identical to \x - e op x, so the definition in the report was probably used for consistency with left sections. We could make GHC respect the report, but we'd have to use (e op) == let z = e in \x - z op x to retain sharing without relying on full laziness. We should keep in mind that this was changed deliberately in ghc 6.6, in order to support postfix operators. http://www.haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html The motivating example was the factorial operator which can currently be written as (n !) in ghc-Haskell. Cheers, Bertram ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: A question regarding cmdargs package
Hi, Am Dienstag, den 12.10.2010, 16:42 +1100 schrieb Ivan Lazar Miljenovic: On 12 October 2010 16:32, Magnus Therning mag...@therning.org wrote: This makes me curious. What's the use case where you want to allow the user to pass arguments on the command line, but you don't want that user to be able to use '--help' to find out what arguments may be passed? When you don't want to bother defining the help options/descriptions? :p note that people expect cmd --help to at least do nothing. So if your program is called launchMissiles, please make it at least spit out a message like your evil dictator was too lazy to write a help message when it is called with --help. (That is if you are sharing your program. Not sure if you should share launchMissiles at all.) Greetings, Joachim -- Joachim Breitner e-Mail: m...@joachim-breitner.de Homepage: http://www.joachim-breitner.de ICQ#: 74513189 Jabber-ID: nome...@joachim-breitner.de signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Desired behaviour of rounding etc.
On 09/10/2010 10:07, Daniel Fischer wrote: On Saturday 09 October 2010 06:34:32, Lennart Augustsson wrote: That code is incorrect. You can't assume that the base for floating point numbers is 2, that's something you have to check. (POWER6 and z9 has hardware support for base 10 floating point.) -- Lennart Well, in light of -- We assume that FLT_RADIX is 2 so that we can use more efficient code #if FLT_RADIX != 2 #error FLT_RADIX must be 2 #endif properFraction (F# x#) = case decodeFloat_Int# x# of (# m#, n# #) - let m = I# m# n = I# n# in if n= 0 then (fromIntegral m * (2 ^ n), 0.0) appearing in the RealFrac instance for Float, I thought it would be a safe optimisation to use for Float and Double in GHC.Float (oddly, FLT_RADIX == 2 is only used for Float, not for Double). I can of course wrap the base 2 code in an #if FLT_RADIX == 2 and have general code for other bases, but as long as the #error stays, that seems superfluous. Making the assumption is fine (as we do in the code above), but the important thing is to make the build fail in a very noisy way if the assumption turns out to be wrong (as above). Cheers, Simon On Fri, Oct 8, 2010 at 2:08 PM, Daniel Fischerdaniel.is.fisc...@web.de wrote: The methods of the RealFrac class produce garbage when the value lies outside the range of the target type, e.g. Prelude GHC.Float truncate 1.234e11 :: Int -- 32-bits -1154051584 and, in the case of truncate, different garbage when the rewrite rule fires: Prelude GHC.Float double2Int 1.234e11 -2147483648 I'm currently working on faster implementations of properFraction, truncate, round, ceiling and floor for Float and Double, so I'd like to know - does it matter at all what garbage is returned in the above case? - if it does, what is the desired behaviour (at least for Int, I can't cater for all possibilities)? On a related note, in my benchmarks, truncFloatGen :: Integral a = Float - a truncFloatGen = fromInteger . truncFloatInteger truncFloatInteger :: Float - Integer truncFloatInteger x = case decodeFloat x of (m,e) | e == 0 - m | e 0 - let s = -e in if m 0 then - ((-m) `shiftR` s) else m `shiftR` s | otherwise - m `shiftL` e is more than twice as fast as GHC.Float.float2Int, the corresponding for Double almost twice as fast as double2Int. Can anybody confirm that the above is faster than float2Int on other machines/architectures? Cheers, Daniel ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Libraries mailing list librar...@haskell.org http://www.haskell.org/mailman/listinfo/libraries ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] a couple of cabal related questions
Hello, recently I've cabalized my program and it brought some problems. First of all, I made use of 'import Paths_package name' functionality to get the path of installed data files. It works great, but now I can no longer run my program in ghci because this module is auto-generated by cabal. I tried to supply my own. This way ghci works, but my stub module gets compiled into the binary in place of auto-generated. And things break again. What's the best way to overcome it? And another question. I'd like to make my program output it's version string. Of course, I can hardcode it into sources, but I've already specified one in the cabal file. Is there any way to get it back in the run time? Thanks, Dmitry ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On Tue, Oct 12, 2010 at 10:20, Dmitry V'yal akam...@gmail.com wrote: Hello, recently I've cabalized my program and it brought some problems. First of all, I made use of 'import Paths_package name' functionality to get the path of installed data files. It works great, but now I can no longer run my program in ghci because this module is auto-generated by cabal. I tried to supply my own. This way ghci works, but my stub module gets compiled into the binary in place of auto-generated. And things break again. What's the best way to overcome it? Create a file called .ghci in the directory where you run ghci and make it contains something like this: :set -idist/build/autogen And another question. I'd like to make my program output it's version string. Of course, I can hardcode it into sources, but I've already specified one in the cabal file. Is there any way to get it back in the run time? It's in Paths_package name as the variable 'version'. /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Eta-expansion destroys memoization?
On Tue, Oct 12, 2010 at 4:34 AM, Bertram Felgenhauer bertram.felgenha...@googlemail.com wrote: Simon Marlow wrote: Interesting. You're absolutely right, GHC doesn't respect the report, on something as basic as sections! The translation we use is (e op) == (op) e once upon a time, when the translation in the report was originally written (before seq was added) this would have been exactly identical to \x - e op x, so the definition in the report was probably used for consistency with left sections. We could make GHC respect the report, but we'd have to use (e op) == let z = e in \x - z op x to retain sharing without relying on full laziness. We should keep in mind that this was changed deliberately in ghc 6.6, in order to support postfix operators. http://www.haskell.org/ghc/docs/6.6/html/users_guide/release-6-6.html The motivating example was the factorial operator which can currently be written as (n !) in ghc-Haskell. From http://www.haskell.org/ghc/docs/6.6/html/users_guide/syntax-extns.html#postfix-operators Since this extension goes beyond Haskell 98, it should really be enabled by a flag; but in fact it is enabled all the time. (No Haskell 98 programs change their behaviour, of course.) Which is not true, but is probably true enough. Of course, there is now a flag http://www.haskell.org/ghc/docs/6.12.2/html/users_guide/syntax-extns.html#postfix-operators but it seems that the non-standard interpretation of (e !) is still kept even without it. Without the flag, it type checks as if you had written \x - e ! x but it still behaves as if you had written (!) e. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Client-extensible heterogeneous types
Greetings, I'm looking for dynamic dispatch on extensible sets of types. Here is a more detailed explanation of what I mean: # Consider the following Python code as representative of something # you might see in Object-Orineted programs in all sorts of languages. # Create an abstract type from abc import ABCMeta, abstractmethod class Abstract: __metaclass__ = ABCMeta @abstractmethod def method(self): pass # Provide some reifications of the abstract type class Variant1(Abstract): def method(self): return Variant 1 stuff class Variant2(Abstract): def method(self): return Variant 2 stuff # Provide some utilities to process these data def heterogeneousProcessor(data): return [datum.method() for datum in data] # If you wrap all the above up in a library, clients can easily extend # it with their own new types which will still work within the # framework class ClientDefined(Abstract): def method(self): return Client-defined stuff heterogeneousContainer = [Variant1(), Variant2(), ClientDefined()] result = heterogeneousProcessor(heterogeneousContainer) -- In Haskell, on the one hand, the heterogeneity is easily provided -- by algebraic data types data AbstractHeterogeneous = VariantHeterogeneous1 | VariantHeterogeneous2 methodHeterogeneous VariantHeterogeneous1 = Variant 1 stuff methodHeterogeneous VariantHeterogeneous2 = Variant 2 stuff heterogeneousProcessor dataa = [methodHeterogeneous datum | datum - dataa] heterogeneousContainer = [VariantHeterogeneous1, VariantHeterogeneous2] resultHeterogeneous = heterogeneousProcessor heterogeneousContainer -- But in order to extend the set of variants, the client would have -- to modify the source code, changing the definiton of -- AbstractHeterogeneous and methodHeterogeneous, both of which belong -- to the library. -- On the other hand, the extensibility is easily provided by type -- classes -- Library code: class AbstractExtensible a where methodExtensible :: a - String instance AbstractExtensible () where methodExtensible _ = Variant 1 stuff instance AbstractExtensible Char where methodExtensible _ = Variant 2 stuff -- Client extension: instance AbstractExtensible Int where methodExtensible _ = Client-defined stuff -- but in this case, there is no heterogeneity: you cannot create the -- equivalent of heterogeneousContainer above -- heterogeneousExtensibleContainer = resultExtensible :: [String] resultExtensible = [methodExtensible (), methodExtensible 'a', methodExtensible (1::Int)] I can't see a Haskell solution which combines both of these orthogonal features without losing the benefits of the type system. (For example, I could create my own, weak, type system with tags to identify the type and maps to do the dispatch.) So my question is, what would be the Haskell approach to combining heterogeneity (as provided by variant (algebraic) types) with type-extensibility (as provided by type classes), without losing the benefits of Haskell's type system? I haven't looked into Template Haskell, but i guess that it is likely to provide a solution. But is there a solution in plain Haskell? Thanks. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Client-extensible heterogeneous types
To do this I would use dynamic types (via Data.Dynamic). There are more typeful ways to deal with heterogeneous structures[*], but if clients can easily extend it with their own new types you've pretty much defined what dynamic types solve. [*] See the HList papers and library and various solutions to the expression problem. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 04:06 , Sittampalam, Ganesh wrote: While I agree with the potential benefits, I also worry that you will end up making something that is far less well tested in practice. For widely used and fairly low-level libraries like gnutls, openssl and zlib, I'm just skeptical that the benefits outweigh the risks and costs. I see your point, but I would be prepared to trust a clean, typesafe (and especially if it's pure) Haskell implementation over the Cthulhu's-tentacles that is openssl. :) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0VikACgkQIn7hlCsL25Wt/QCgneAyuCttwnyrHG4vuC22sNBp Y7gAnAtKUoNekXUb61ISYwnmSkZWJejM =3+oI -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Data.Judy
Hi, Are there any plans to extent the current Data.Judy package to include bindings to JudySL and JudyHS? There's a standalone binding to JudySL by Andrew Choi that is usable but it would of course be better to have the functionality in the Data.Judy package proper. Thanks Tom ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: tls, native TLS/SSL protocolimplementation
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 04:41 , Brandon Moore wrote: particular about cryptographic primitives. Some side channel attacks seem to call for a very low-level language, to make it easier to verify that e.g. execution time and the memory access pattern does not depend on the key. It's hard enough to predict execution times for Haskell code at the best of times :) - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0V4cACgkQIn7hlCsL25V0VwCg1GrZkqrGU0CswG/KSQvHO+hJ B2QAn269l6o58G0AeRlyWV9lRTaFF6K6 =6RTp -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Hi Gregory, ... No, but there is no point in using a formalism that adds complexity without adding functionality. Arrows are more awkward to use than monads because they were intentionally designed to be less powerful than monads in order to cover situations in which one could not use a monad. When your problem is solved by a monad there is no point in using arrows since an arrow require you to jump through extra hoops to accomplish the same goal. As I understood, John Hughes invented the arrows as a generalisation of monads, you say it's a less powerful concept. I'm a bit puzzled with that. Could you explain these different views. ... Yes, but the = operator lets you do the same thing with monads, and in fact I use it all the time to do point-free programming with monads, so this isn't at all an advantage that arrows have over monads. yes, I agree. What about the other combinators (, ***,...)? ... No, that is not at all the problem with arrows. The problem with arrows is that they are more restrictive than monads in two respects. First, unlike monads, in general they do not let you perform an arbitrary action in response to an input. ... It's rather easy to define some choice combinators. Or am I missing the point? ... Second, they place restrictions on how you define the input arguments of the arrow because you can't feed the output of one arrow into to input of the next unless said input is captured in the arrows type. To be more concrete about my second point, suppose you have some monadic action f :: a - b - m c How would you structure this same action as an arrow? One thing that you could do is take one of the arguments and turn it into the input of the arrow: f' :: a - Arrow b c But now you can't feed the output of an arrow into the first argument. yes, this a common pattern, a function f' with an extra argument of type a, and sometimes you want to call f' with some value, e.g. f' 42, sometimes the extra argument must be computed from the arrow input, let's say with an arrow g. For this case in hxt there is a combinator ($) with signature ($) :: (c - a b d) - a b c - a b d With that combinator you can write f' $ g The combinator does the following: The input of the whole arrow is fed into g, g computes some result and this result together with the input is used for evaluating f'. The ($) is something similar to ($). Alternatively, you could pack both arguments into the input of the arrow: f'' :: Arrow (a,b) c Great, but now you have made it more awkward to use f'' because you have ... yes, that become rather clumsy. ... In conclusion, while I greatly appreciate you taking the time to explain your reasoning, it still looks to me like there is nothing you have gained by using arrows except adding extra unnecessary complexity in your library. So, your advice is to throw away the whole arrow stuff in hxt-10 and redefined (or rename) the combinators on the basis of monads? Cheers, Uwe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 10/11/10 03:37 , Michael Snoyman wrote: verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I think you need to decide which community you intend to support, actually. On the one hand, a professional organization will prefer to have real names, real pictures, etc. On the other, if you want to be a central coordinating spot for the existing Haskell community, many of us are far better known by nicknames and identicons. If you want to support both, then perhaps you need multiple portals, with people wanting to be identified professionally registering appropriately in order to show up in the professional portal. But then you have the difficulty of how to show content in each portal (for example, a forum discussion might be cited in the professional forum, but what if some or all of the contributors were on the community side? You might show names and pictures from the professional side and some kind of placeholder for those not registered professionally, but then you need to worry about the folks who want to keep their professional and online identities separate. - -- brandon s. allbery [linux,solaris,freebsd,perl] allb...@kf8nh.com system administrator [openafs,heimdal,too many hats] allb...@ece.cmu.edu electrical and computer engineering, carnegie mellon university KF8NH -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.10 (Darwin) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/ iEYEARECAAYFAky0XIoACgkQIn7hlCsL25VCsQCfVPHZFM3ZY0syuCQ55P78R5a9 hnkAnimXEzujTNifh5jgwnQyMsrZmwo0 =Fppp -END PGP SIGNATURE- ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Client-extensible heterogeneous types
[Sorry Stephen, didn't mean to take this off-list, hence the resend.] On 2010 Oct 12, at 14:31, Stephen Tetley wrote: To do this I would use dynamic types (via Data.Dynamic). Ah, yes, I've just stumbled upon these while trying to figure out what APPLY or FUNCALL would mean in Haskell. There are more typeful ways to deal with heterogeneous structures[*], but if clients can easily extend it with their own new types you've pretty much defined what dynamic types solve. Cool. I've just started experimenting with implementing the dynamism by holding functions (methods) alongside data in a variant type. I think I'll see what I learn by taking this a bit further, before digging into Data.Dynamic, but it's good to know there is some prior art to turn to in the long run. Many thanks. Reading the GHC docs on Data.Dynamic, I infer that Data.Dynamic is non- standard, but, in principle, portable to other implementations. Is that understanding correct? [*] See the HList papers and library and various solutions to the expression problem. This seems to be extremely relevant too, though I think that I'll stick to my own experiment and Data.Dynamic to start with. Thanks very much. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] pointers for EDSL design
2010/10/12 o...@okmij.org:
An alternative approach to model sharing at the object level is the
technique I use for modelling context-free grammars in my PADL 2011
paper Explicitly Recursive Grammar Combinators... Using ideas from
the Multirec generic programming library and some recent Haskell type
system extensions (most importantly GADTs and type families), you can
do this in a well-typed way for sets of mutually recursive
object-level expressions.
I guess you are using what I call `the initial embedding' of an object
language. Somehow I prefer the final embedding.
No. In the library, I use both embedding styles for different
purposes, but what I was referring to here (the construction of
production rules) is actually implemented using what you call a typed
tagless-final embedding. I see the technique as an encoding of
*recursion* in a typed tagless final object language in such a way
that the recursion is observable in the host language.
Suppose you have the following (logically inconsistent ;)) code (in
Haskell notation):
term1 :: Int
term1 = if term2 then 1 else 2
term2 :: Bool
term2 = term1 == 2
and you want to model it in the typed tagless final encoding of simply
typed lambda calculus from the examples in your online typed tagless
final lecture notes [1] extended with implicit arbitrary recursion.
Then you could do
data Term1
data Term2
data TermDomain ix where
Term1 :: TermDomain Term1
Term2 :: TermDomain Term2
data family TermVal ix
newtype instance TermVal Term1 = TV1 {unTV1 :: Int}
newtype instance TermVal Term2 = TV2 {unTV2 :: Bool}
class ExtraSymantics repr where
if_ :: repr h Bool - repr h a - repr h a - repr h a
eq_int :: repr h Int - repr h Int - repr h Bool
class RecSymantics repr phi | repr - phi where
ref :: phi ix - repr h (TermVal ix)
terms :: (Functor (repr h), Symantics repr, ExtraSymantics repr,
RecSymantics repr TermDomain) = TermDomain ix - repr h
(TermVal ix)
terms Term1 = fmap TV1 $ if_ (fmap unTV2 (ref Term2)) (int 1) (int 2)
terms Term2 = fmap TV2 $ eq_int (fmap unTV1 (ref Term1)) (int 2)
In this way, the embedding models the object language recursion in
such a way that the recursion remains observable in the host language
because you can implement it the way you want in your RecSymantics
instance. Possible needs for this observable recursion could be that
you want to do some form of recursion depth-bounded evaluation or some
form of static analysis or whatever... Such modifications are
fundamentally impossible if you model object language recursion
naively using direct host language recursion.
For my parsing library, I need these techniques to get a good view on
the recursion in the grammar. This allows me perform grammar
transformations and analysis.
Dominique
Footnotes:
[1] http://okmij.org/ftp/tagless-final/course/#infin1
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Haskellers.com recent changes (and I need some volunteers)
On Mon, Oct 11, 2010 at 3:24 PM, Michael Snoyman mich...@snoyman.comwrote: On Mon, Oct 11, 2010 at 2:44 PM, Magnus Therning mag...@therning.org wrote: On Mon, Oct 11, 2010 at 13:14, John Lato jwl...@gmail.com wrote: From: Michael Snoyman mich...@snoyman.com Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I agree that it would be nice to use only real pictures, however I wouldn't want to leave out those who choose not to use any image at all. What about a site policy that user images must be real pictures (if they exist), and violations can be flagged/blocked? Although, I don't know how this would interact with using OpenID, which appears to be most of the users currently displaying an identicon. I think it would be wrong to have haskellers.com impose restrictions on what image I put on gravatar. My image on gravatar pops up in numerous other sites (I believe stackoverflow, ohloh, flickr, etc) and I'm not necessarily happy with putting my photo everywhere, even though I'd be fine with putting it on haskellers.com. So, instead I'd like to see the use of gravatar become optional. Then if haskellers.org could require a photo, and I could simply choose not to get my cartoon image from gravatar. An obvious extension would be to allow me to get the image from other sources in the future, maybe an option to grab a picture out of an album on Facebook, or Flickr? So firstly, just to clarify, I was never recommending we make real photos a requirement to have an account on Haskellers. I was simply talking about the 10 random profiles that get shown on the homepage: I think it gives a more professional feel to the site if we see 10 real people and not Bart Simpson. That was my question. I generally agree on this point, however having a profile on the homepage (even if it is randomly selected) provides a great deal of publicity and legitimacy to that profile (as much as haskellers.com can provide!). I think this should be equally available to users who for whatever reason do not wish to share a photo image. Now, the idea of using something besides gravatar is a fair point. I know personally I *like* it when sites use gravatar, as it's one less site I have to upload my image to. Otherwise, I need to search around for my preferred profile image, crop it to whatever that site wants, hope they'll scale it nicely, etc. From the site maintainer standpoint, gravatar also means there's less moving parts on Haskellers, and it decreases our bandwidth significantly, which is definitely something to consider. I'll definitely put some thought into providing an alternative to gravatar. In the meanwhile, an option you have is to add a second gravatar email address. This works especially well with Gmail accounts, where you can just use a + sign (eg, michael+haskell...@snoyman.com michael%2bhaskell...@snoyman.com). I'm not saying this is ideal, but if you want to have your real photo up, it will work today. That seems to be reasonable. Although this is only an issue if there's some sort of real-image restriction to the functionality of haskellers.com. I don't think the implementation should be difficult once the policy is decided. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Gregory, I use arrows (especially list arrows) in a lot of my projects and find them (after some training) easier to work with than monands. Code that I write point-free using arrows generally contains fewer bugs than code I write in monadic style. On Oct 11, 2010, at 8:48 PM, Gregory Crosswhite wrote: Uwe, Thank you for your reply. On 10/11/10 6:20 AM, Uwe Schmidt wrote: I thing, this is not a question of functionality, it's a question of style. Of course everything in hxt could have been done with monads, but does this also mean: Everything must have been done with monads? No, but there is no point in using a formalism that adds complexity without adding functionality. Arrows are more awkward to use than monads because they were intentionally designed to be less powerful than monads in order to cover situations in which one could not use a monad. When your problem is solved by a monad there is no point in using arrows since an arrow require you to jump through extra hoops to accomplish the same goal. I think it is unfair to say that arrows add complexity over monads. This statement can only be true to people who actually know monads and do not know arrows. This has more to do with the direction of one's knowledge than the 'complexity' (whatever this means) of a programming abstraction. Don't see arrows a less restricted monads, see them as a generalization of functions, than it will all make sense. Use them in situations that need generalization of functions, not in cases that require the power of monads. Arrows are a generalisation of functions, so if you know all about working with functions you know (almost) all about working with arrows. When generalizing a pure algorithm, something like f3 . f2 . f1, or in Unix pipe style f1 f2 f3, you don't have to rewrite the code, you just generalize function composition. Yes, but the = operator lets you do the same thing with monads, and in fact I use it all the time to do point-free programming with monads, so this isn't at all an advantage that arrows have over monads. I'd rather use (.) for composition of expressions than (=) and I'd rather use the 'id' for identity than return. Writing my arrow computations point-free as if they were functions feels far less clumsy and a far more readable than monadic style. When constructing code, it is of course sometimes simpler to start with a point wise version and then refactor and rewrite it into a more compact point free version. The problem with arrows seems, that the arrow style forces to start with the point free style. And that may be the main hurdle in mind. No, that is not at all the problem with arrows. The problem with arrows is that they are more restrictive than monads in two respects. First, unlike monads, in general they do not let you perform an arbitrary action in response to an input. Second, they place restrictions on how you define the input arguments of the arrow because you can't feed the output of one arrow into to input of the next unless said input is captured in the arrows type. This restriction, though not always, can be very useful. This restriction allows you to do full inspection of the arrow expression. This inspection can in some cases be used to serialize an arrow computation of statically optimize it to a more efficient form. When you don't need the power of Monads (or ArrowApply) why use a formalism that does provide this power? That will only make it harder to reason about your program, which isn't quite the Haskell way. To be more concrete about my second point, suppose you have some monadic action f :: a - b - m c How would you structure this same action as an arrow? One thing that you could do is take one of the arguments and turn it into the input of the arrow: f' :: a - Arrow b c But now you can't feed the output of an arrow into the first argument. Alternatively, you could pack both arguments into the input of the arrow: f'' :: Arrow (a,b) c Great, but now you have made it more awkward to use f'' because you have to always pack the arguments into a tuple, so that for example if one of the arguments is a constant then you can no longer easily use currying. The advantage of f over both alternatives is that you don't have to waste any of your time fitting multiple input arguments into the input type of an arrow. In fact, if the first argument to f'' is usually a constant, then f'' is arguably more awkward to use in a point-free setting than f, because instead of being able to write a = f 42 = b You have to write something like a (const 42 id) f'' b Of course, if the first argument were *always* a constant then you could use f', but then you lose the ability to ever feed in the output of an arrow into the first argument. So in short, arrows force you to make choices and trade-offs that never come up when using monads.
Re: [Haskell-cafe] Client-extensible heterogeneous types
From: Jacek Generowicz jacek.generow...@cern.ch So my question is, what would be the Haskell approach to combining heterogeneity (as provided by variant (algebraic) types) with type-extensibility (as provided by type classes), without losing the benefits of Haskell's type system? I haven't looked into Template Haskell, but i guess that it is likely to provide a solution. But is there a solution in plain Haskell? It's not plain Haskell, but I'm surprised nobody mentioned the ExistentialQuantification extension, which unless I'm missing something provides exactly what you want. John ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Make your Darcs repositories hashed?
Hey Haskellers (and darcs-users CC'ed) On Sat, Oct 09, 2010 at 23:08:12 +, Jason Dagit wrote: I answered you immediate question in a different email. Now I'll do a bit of explanation on why people want hashed. Thanks to Jason for the explanation. I've linked to it from http://wiki.darcs.net/RepositoryFormats so that we'll have an easier time in the future encouraging people to move to the hashed format. Also: If you don't have darcs 2.4.4, you can upgrade to the hashed format by doing: cd /srv/code/myrepo darcs get . ~/myrepo-hashed rm -rf ~/myrepo-hashed/_darcs/prefs cp -R _darcs/prefs ~/myrepo-hashed/_darcs/prefs mv ~/myrepo-hashed/_darcs _darcs.new mv _darcs _darcs.old mv _darcs.new _darcs rm -rf ~/myrepo-hashed rm -rf _darcs.old I may put this on the wiki. We had pruned this sort of thing away in favour of the optimize --upgrade command, in the interest of tidiness, but getting recent Darcs into people's hands takes a while. Also, the maintainers behind code.haskell.org are aware about the need for a Darcs 2.4.4 upgrade (I filed a request on 15 Sep). We're looking into an easy way to do this on Debian Etch. See also * http://wiki.darcs.net/RepositoryFormats The three formats in a nutshell * http://wiki.darcs.net/DarcsTwo#hashed-repository-format More about hashed repositories (covers a lot of the same stuff Jason did) * http://lists.osuosl.org/pipermail/darcs-users/2010-August/024941.html Discussion on eventually retiring support for old-fashioned repositories I can guarantee that at least Darcs 2.5 (the upcoming release) will continue to provide full support for old-fashioned repositories. But they are going away eventually so that we can focus on making Darcs better. Thanks! -- Eric Kow http://www.nltg.brighton.ac.uk/home/Eric.Kow For a faster response, try +44 (0)1273 64 2905 or xmpp:ko...@jabber.fr (Jabber or Google Talk only) signature.asc Description: Digital signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Client-extensible heterogeneous types
On 12 October 2010 14:08, Jacek Generowicz jacek.generow...@cern.ch wrote: Reading the GHC docs on Data.Dynamic, I infer that Data.Dynamic is non-standard, but, in principle, portable to other implementations. Is that understanding correct? Yes - Data.Dynamic uses some GHC specifics but there are other lightweight encodings of dynamic types that I think just use existential types (which John Lato mentioned). ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Desired behaviour of rounding etc.
On Tuesday 12 October 2010 11:18:39, Simon Marlow wrote: On 09/10/2010 10:07, Daniel Fischer wrote: On Saturday 09 October 2010 06:34:32, Lennart Augustsson wrote: That code is incorrect. You can't assume that the base for floating point numbers is 2, that's something you have to check. (POWER6 and z9 has hardware support for base 10 floating point.) -- We assume that FLT_RADIX is 2 so that we can use more efficient code #if FLT_RADIX != 2 #error FLT_RADIX must be 2 #endif Making the assumption is fine (as we do in the code above), but the important thing is to make the build fail in a very noisy way if the assumption turns out to be wrong (as above). Cheers, Simon Are there any other places where FLT_RADIX == 2 is assumed? (grepping the .hs, .lhs and .h files in the source tree for FLT_RADIX revealed nothing else.) If that's the only place where e.g. base 10 floating point would fail, we should make it work for that too. If on the other hand base 2 is assumed in other places, for primops, whatever, and that assumption is not going to be changed, I'd prefer not to litter the source with dead code. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On 12.10.2010 13:45, Magnus Therning wrote: On Tue, Oct 12, 2010 at 10:20, Dmitry V'yalakam...@gmail.com wrote: Hello, recently I've cabalized my program and it brought some problems. First of all, I made use of 'import Paths_package name' functionality to get the path of installed data files. It works great, but now I can no longer run my program in ghci because this module is auto-generated by cabal. I tried to supply my own. This way ghci works, but my stub module gets compiled into the binary in place of auto-generated. And things break again. What's the best way to overcome it? Create a file called .ghci in the directory where you run ghci and make it contains something like this: :set -idist/build/autogen And another question. I'd like to make my program output it's version string. Of course, I can hardcode it into sources, but I've already specified one in the cabal file. Is there any way to get it back in the run time? It's in Paths_package name as the variable 'version'. /M That's perfectly what I was looking for, thanks a lot! By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Windows binary for latest darcs head
Does anyone have a Windows binary for the latest GHC darcs head or at least October 8th they could send me. Many thanks in advance, Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Haskellers.com survey
Hey all, Guessing popular consensus based on what people write on the mailing list is not exactly statistically sound. So instead, I've put up some of our open questions- along with some other questions I've wanted to ask- in a survey. If you are interested in the future of Haskellers, I encourage you to fill it out. https://spreadsheets.google.com/viewform?formkey=dG8tcVhBdzRSS1lkdVV6U281emtRMWc6MQ Michael ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com wrote: On 12.10.2010 13:45, Magnus Therning wrote: On Tue, Oct 12, 2010 at 10:20, Dmitry V'yalakam...@gmail.com wrote: Hello, recently I've cabalized my program and it brought some problems. First of all, I made use of 'import Paths_package name' functionality to get the path of installed data files. It works great, but now I can no longer run my program in ghci because this module is auto-generated by cabal. I tried to supply my own. This way ghci works, but my stub module gets compiled into the binary in place of auto-generated. And things break again. What's the best way to overcome it? Create a file called .ghci in the directory where you run ghci and make it contains something like this: :set -idist/build/autogen And another question. I'd like to make my program output it's version string. Of course, I can hardcode it into sources, but I've already specified one in the cabal file. Is there any way to get it back in the run time? It's in Paths_package name as the variable 'version'. /M That's perfectly what I was looking for, thanks a lot! By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere? I don't know, I think I found it in the source more or less by mistake :-) /M -- Magnus Therning (OpenPGP: 0xAB4DFBA4) magnus＠therning．org Jabber: magnus＠therning．org http://therning.org/magnus identi.ca|twitter: magthe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RealFrac methods for Double and Float
On Tue, Oct 12, 2010 at 10:02 AM, Tyson Whitehead twhiteh...@gmail.com wrote: On October 11, 2010 15:12:12 Daniel Fischer wrote: GHC's new code generator does some incredible stuff with the code for Float's RealFrac instance, properFraction has become about _seven times_ faster, floor and ceiling about _thirteen times_ and round about _10.5 times_ (values for my box, the exact numbers will differ, but the tendency will be the same). Out of curiosity, by new code generator, are you meaning just the stock GHC 7 code path or are you meaning the new now available but disabled by default unless you use some flag (which I forget right now) code generation path. Cheers! -Tyson When I did the GHC 7 timings I simply ran the shell script provided in the linked tarball - no funny business. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Data.Judy
tomdoris: Hi, Are there any plans to extent the current Data.Judy package to include bindings to JudySL and JudyHS? There's a standalone binding to JudySL by Andrew Choi that is usable but it would of course be better to have the functionality in the Data.Judy package proper. Thanks Tom Patches will be accepted! I'm not currently working on this though. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: RealFrac methods for Double and Float
On Tuesday 12 October 2010 17:15:14, Antoine Latter wrote: On Tue, Oct 12, 2010 at 10:02 AM, Tyson Whitehead twhiteh...@gmail.com wrote: On October 11, 2010 15:12:12 Daniel Fischer wrote: GHC's new code generator does some incredible stuff with the code for Float's RealFrac instance, properFraction has become about _seven times_ faster, floor and ceiling about _thirteen times_ and round about _10.5 times_ (values for my box, the exact numbers will differ, but the tendency will be the same). Out of curiosity, by new code generator, are you meaning just the stock GHC 7 code path or are you meaning the new now available but disabled by default unless you use some flag (which I forget right now) code generation path. Cheers! -Tyson When I did the GHC 7 timings I simply ran the shell script provided in the linked tarball - no funny business. Antoine Yep, just a vanilla perf build of HEAD. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On Tue, Oct 12, 2010 at 8:56 AM, Uwe Schmidt u...@fh-wedel.de wrote: No, but there is no point in using a formalism that adds complexity without adding functionality. Arrows are more awkward to use than monads because they were intentionally designed to be less powerful than monads in order to cover situations in which one could not use a monad. When your problem is solved by a monad there is no point in using arrows since an arrow require you to jump through extra hoops to accomplish the same goal. As I understood, John Hughes invented the arrows as a generalisation of monads, you say it's a less powerful concept. I'm a bit puzzled with that. Could you explain these different views. These are the same thing, the difference is whether you're talking about how many different concepts are compatible with an abstract structure as opposed to what can be done universally with such a structure. Adding the ability to do more things with a structure necessarily reduces the number of concepts that structure applies to. Perhaps a more familiar example is the relationship Functor Applicative Monad. Going left to right adds power, making generic code more expressive but reducing the number of concepts that can be represented as instances; going right to left adds generality, limiting what generic code can do but enabling more instances. That said, I dislike calling arrows a generalization of monads--it's not incorrect as such, but I don't think it aids understanding. It really is much better to think of them as generalized functions, which they explicitly are if you look at the borrowed category theory terminology being used. They're generalized monads only in the sense that functions (a - m b) form arrows in a category, as far as I can tell. No, that is not at all the problem with arrows. The problem with arrows is that they are more restrictive than monads in two respects. First, unlike monads, in general they do not let you perform an arbitrary action in response to an input. ... It's rather easy to define some choice combinators. Or am I missing the point? The key point is that arrows in full generality--meaning instances of Arrow only, not other type classes--are not higher-order because no internal application operator is provided. The ArrowApply class gives you full higher-order generalized functions, at the cost of giving up some useful limitations (read: static guarantees about code behavior) that make reasoning about arrow-based structures potentially easier. So, a general arrow can perform different actions and produce different output based on input it receives, but it can't take *other arrows* and pick different ones to use depending on its input. The combinator does the following: The input of the whole arrow is fed into g, g computes some result and this result together with the input is used for evaluating f'. The ($) is something similar to ($). There's no shortage of ways to deal with the issue, but they all rely on using combinator *functions*, not arrows. The result is that arrow-based expressions tend to be internally less flexible, following pre-defined paths, similar to how expressions using Applicative can't embed control flow the way ones using Monad can. Which is fine for many purposes, of course. Essentially, arrows lend themselves best to composing first-order computations to create larger computations with a fixed structure. If you find yourself forced to frequently use ArrowApply or other means of eliminating higher-order structure--e.g., anything that results in an arrow with an output type that contains fewer instances of the arrow's own type constructor than does the input type--it may be worth considering if arrows are really what you want to use. Personally, though, I think monads are really overkill in many cases and strongly prefer, where possible, to use Applicative or Arrow. - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
Dear Sebastiaan, I would first refer to the description of the Change function in a paper by Erik Meijer (an Haskeller among the designers of F#): http://portal.acm.org/citation.cfm?id=1297027.1297078 In short, programmers will learn something new only if the improvement is worth the effort of the paradigm shift. Below I add my opinions on the specific problem. A disclaimer: I am unfamiliar with monads myself, I claim awareness of a meta-problem, which is IMHO more important. On Oct 12, 3:29 pm, Sebastiaan Visser hask...@fvisser.nl wrote: Gregory, I use arrows (especially list arrows) in a lot of my projects and find them (after some training) easier to work with than monands. Code that I write point-free using arrows generally contains fewer bugs than code I write in monadic style. I think it is unfair to say that arrows add complexity over monads. This statement can only be true to people who actually know monads and do not know arrows. This has more to do with the direction of one's knowledge than the 'complexity' (whatever this means) of a programming abstraction. Were you writing a paper, your comment would be fully valid. Here we're talking about a library for people to use in practice. In the middle, somebody should make sure that people without a PhD can learn arrows, by providing documentation. The problem might be just educational, and it's not restricted to arrows, but it is still a valid problem. When you write a library for general consumption (like here), you should strive to have a simple and effective interface for people. Try to think of what's happening. Even the existence of this thread is surprising. Haskell programmers, and experienced ones, are discussing about how to express a two arguments function with arrows. Can you imagine a C programmer asking that? The answer would be RTFM or STFW, or less polite than that. And that's GOOD. You can use arrows because you got an useful intuition of them. Good for you. The problem is partially the same as with monads, only to a greater extent: monads can be easy if you don't try to relate them to category theory, and they are indeed considered easy in F# (see the same paper). Again, the problem is maybe mostly educational, but it is entirely valid. Of course, the root question is: what is the purpose of Haskell? 1) Is it to produce pure research, which might then be reused in production to actually affect software engineering, and used directly by blessed PhD students? 2) Or should Haskell be used as such? Some people argue for 2), but the research bias of the community is still quite strong. And you can't achieve 2) well working with a research methodology. For instance, somebody needs to write _complete_ documentation (I see there is some, but it doesn't cover the basic questions you are discussing), intended for users, rather than papers. Like it happens for any other language. Of course, nobody _has to do_ anything. I'm a PhD student, I couldn't work on any of this because it wouldn't count for my career. But at least I'm aware my work won't be usable for purpose 2). (Intermediate situations, like writing a paper _and_ a dumbed-down version for general consumption, are also possible of course). Best regards ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On Tue, Oct 12, 2010 at 8:56 AM, Uwe Schmidt u...@fh-wedel.de wrote:
No, but there is no point in using a formalism that adds complexity
without adding functionality. Arrows are more awkward to use than
monads because they were intentionally designed to be less powerful than
monads in order to cover situations in which one could not use a monad.
On Tue, Oct 12, 2010 at 9:49 AM, C. McCann c...@uptoisomorphism.net wrote
Essentially, arrows lend themselves best to composing first-order
computations to create larger computations with a fixed structure. If
you find yourself forced to frequently use ArrowApply or other means
of eliminating higher-order structure--e.g., anything that results in
an arrow with an output type that contains fewer instances of the
arrow's own type constructor than does the input type--it may be worth
considering if arrows are really what you want to use.
Personally, though, I think monads are really overkill in many cases
and strongly prefer, where possible, to use Applicative or Arrow.
Well I am compelled to add my two cents worth to this conversation. I like
to use examples, so that is what I will do. I am going to use a simple one,
and you may wonder why I used an arrow to represent this little computation,
but the main reason is that it fits the way I think better then if's ,
guards, cases, in or where clauses. The entirety of a computation is right
there in my face. The other thing that I will explain after showing this
little example function {arrow under the hood} is that it leads to more
thinking of composing into even more higher orderness, until you have a
single function definition that can be the entire program.
Function splitMiddle:
Takes a list and returns a pair consisting of the
list split into two equal parts.
splitMiddle :: forall a. [a] - ([a], [a])
splitMiddle =
(id (length flip div 2))
(\(xs,a) - splitAt a xs)
usage:
splitMiddle [1..10]
([1,2,3,4,5],[6,7,8,9,10])
OKAY here is where the thoughts can come in to play and are a direct
result of the pointfree style that is adopted as a direct result of using
arrow
notation. To split the list of words of a line of text you may do this
initially:
splitMiddle $ words Now is the time to come to the aid of our country
([Now,is,the,time,to,come],[to,the,aid,of,our,country])
Then it occurs that well hell, why not move the words function into the
arrow:
(words splitMiddle) Now is the time to come to the aid of our country
([Now,is,the,time,to,come],[to,the,aid,of,our,country])
That can be turned into a new function with great ease and clarity:
splitSentence :: String - ([String], [String])
splitSentence = words splitMiddle
Then maybe I decide, hey, I only want the second half of the sentence:
sndHalfSentence :: String - [String]
sndHalfSentence = words splitMiddle snd
or if I have defined splitSentence as above:
sndHalfSentence :: String - [String]
sndHalfSentence = splitSentence snd
doing the function fstHalfSentence is obvious in that the mechanics
are right there to see and no variables to muck it up, just change the
snd to fst :
fstHalfSentence :: String - [String]
fstHalfSentence = splitSentence fst
The other nice use of arrow is INSIDE of a monadic structure:
Now is the time to come to the aid of our country = (return words
concat)
Nowisthetimetocometotheaidofourcountry
which can become the definition of squeeze:
squeeze :: [Char] - [Char]
*Big3 let squeeze cs = cs = (return words concat)
squeeze Now is the time to come to the aid of our country
Nowisthetimetocometotheaidofourcountry
and then of course you can do a few sentences instead of only
one,if you change the definition with the simple addition of an
applicative operator to the mix.
squeezeSentenceF
:: forall (f :: * - *). (Functor f) = f [Char] - f [Char]
squeezeSentenceF css = (squeeze $) css
squeezeSentenceF [This is how to do a list of sentences,
It makes use of applicatives too]
[Thisishowtodoalistofsentences,Itmakesuseofapplicativestoo]
notice that this is more general then just mapping as it applies to any
functor, of which the Maybe monad has an instance..
so:
squeezeSentenceL (Just This is how to do a Maybe sentence)
Just ThisishowtodoaMaybesentence
works just nicely. I think that the more you mix and match ALL of the tools
and
do a little experimentation with them, that it then begins to be a situation
where
your thoughts of how to compose things are not locked down to one way and it
opens up your mind to many possibilities. I am a proponent of having and
using
ALL the available tools in a mix and match way if need be. About the only
thing
you have to do to use any of the various tools in the same line of code is
to remember
to use a parenthetic bit of separation between one and the next.
metacode
xss = ( ((g h) $) return) so you are using a monadic bind to
shove something of {functor f, monad m} embodied in xss such that f
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On 10/12/10 5:56 AM, Uwe Schmidt wrote: Hi Gregory, As I understood, John Hughes invented the arrows as a generalisation of monads, you say it's a less powerful concept. I'm a bit puzzled with that. Could you explain these different views. Consider the following example: f :: Int - m a f i = monads !! (i *5 `mod` length monads) where monads = [...] :: [m a] In this case, we see that the action chosen by f is a non-trivial function of the input argument. In general, there is no way that we can represent this equivalently as an arrow. The reason why is because, unlike monads, in general arrows do not give you arbitrary freedom to choose the action performed by the arrow. It is true that one can get this freedom back for arrows which are instances of ArrowApply, but that that point what you really have is a monad with different notation. Hughes himself said that when your arrow is an instance of ArrowApply, you are better off just sticking with monads. The reason for the existence of arrows is because allowing the user to arbitrarily choose actions restricts the power that the creator of a library has to do stuff behind the scenes with these actions. To see why, suppose we are chaining together two arrows like so: f :: Arrow a b g :: Arrow b c h :: Arrow a c h = f g When defining the composition operator , the library author has the power to open up both of the actions f and g, which gives him lots of power in defining what h should be. By contrast, suppose we are chaining together two monads like this: f :: Monad b g :: b - Monad c h :: Monad c h = f = g When defining the composition operator =, the library author can look inside f, but he has no way of knowing which action will be chosen by g, so he cannot use this information to decide what h should be. The motivation Hughes gave for arrows was parsers that have a static part in them; he pointed out that using monads we have no way to access and combine these static parts, so we needed to come up with a formalism that let us have a nice combinator framework like monads but which allows us to break open components so that we can combine them in interesting ways. So in short, arrows (relative to monads) take away some of the power of the user to choose actions as a function of the input in order to give library authors more power to define how actions are combined. In this sense arrows are less powerful from a user perspective than monads, except in the case where an arrow is an instance of ArrowApply in which case they are ... Yes, but the= operator lets you do the same thing with monads, and in fact I use it all the time to do point-free programming with monads, so this isn't at all an advantage that arrows have over monads. yes, I agree. What about the other combinators (, ***,...)? A couple of points in response. First, though it is less convenient, you can use those combinators if you wrap your arrow inside the Kleisli newtype wrapper, which is something I have occasionally done. Second, while I see your point that there are some combinators that arrows have that are not defined for monads, there are not that many of them, and it would be trivial to write special instances of them for monads; it seems to me that the price of making versions of these operators for monads is less than the price of having to re-implement all of the existing monad combinators and libraries using arrow notation just to not have to redefined monad versions of , etc. ... No, that is not at all the problem with arrows. The problem with arrows is that they are more restrictive than monads in two respects. First, unlike monads, in general they do not let you perform an arbitrary action in response to an input. ... It's rather easy to define some choice combinators. Or am I missing the point? No, in general arrows do not allow you to define choice combinators. Having said that, you *can* give the user some power to choose between fixed choices action in exchange for possibly losing power from your perspective a library author. If your arrow is an instance of ArrowChoice, then you give your user the ability to choose between a fixed set of predefined actions. However, the user is not able to compute an arbitrary action in response to an input. To get this power, you need to make your arrow an instance of ArrowApply, in which case you really aren't getting any benefit from the perspective of either a user *or* a library author over using a monad. yes, this a common pattern, a function f' with an extra argument of type a, and sometimes you want to call f' with some value, e.g. f' 42, sometimes the extra argument must be computed from the arrow input, let's say with an arrow g. For this case in hxt there is a combinator ($) with signature ($) :: (c - a b d) - a b c - a b d With that combinator you can write f' $ g
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote: Hughes himself said that when your arrow is an instance of ArrowApply, you are better off just sticking with monads. Well, this is not necessarily good advice. It is true that ArrowApply will preclude some sort of static analysis. But, this does not mean that you cannot do the static analysis on the pieces of code that *can* be written using less powerful arrow combinators. The same can be said about Applicative, Monad, etc. The combinators in the former could be implemented in ways that allow some extra analysis to be done, while those in the latter are still available when absolutely necessary. I believe the Utrecht parsing library does this, and encourages parsers to be written in applicative style as much as possible for this reason. If you have nothing like that to gain, though, it may make sense to jettison arrows due merely to syntactic considerations and the like, though. -- Dan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On 10/12/10 12:39 PM, Gene A wrote: splitMiddle :: forall a. [a] - ([a], [a]) splitMiddle = (id (length flip div 2)) (\(xs,a) - splitAt a xs) But is that really easier to understand at a glance then splitMiddle xs = splitAt (length xs `div` 2) xs ? It seems to me that while point-free style is nice and I personally us it extensively, sticking to it religiously can sometimes lead to code that is *less* clear. Also, I don't see why one would prefer over the standard function composition operator, .. Using this and uncurry you could actually make your point-free style definition much more succinct and arguably easier to read: splitMiddle = uncurry splitAt . ((`div` 2) . length id) OKAY here is where the thoughts can come in to play and are a direct result of the pointfree style that is adopted as a direct result of using arrow notation. [...] I completely agree with you that point-free style is nice; I am certainly not arguing against it. However, it can be over-kill, and there is no reason that I can see why using the arrow notation in place of the standard function notation . helps one write function in a point-free style. The other nice use of arrow is INSIDE of a monadic structure: Now is the time to come to the aid of our country = (return words concat) Nowisthetimetocometotheaidofourcountry [...] Your use of a monad here both redundant and obfuscatory; a much simpler version of this code is (concat . words) Now is the time to come to the aid of our country squeezeSentenceF :: forall (f :: * - *). (Functor f) = f [Char] - f [Char] squeezeSentenceF css = (squeeze $) css squeezeSentenceF [This is how to do a list of sentences, It makes use of applicatives too] [Thisishowtodoalistofsentences,Itmakesuseofapplicativestoo] [...] You aren't really using applicative style here, you are just defining a shorthand for calling fmap squeeze. Also, your function could be expressed in point-free style as follows: squeezeSentenceF = fmap squeeze I think that the more you mix and match ALL of the tools and do a little experimentation with them, that it then begins to be a situation where your thoughts of how to compose things are not locked down to one way and it opens up your mind to many possibilities. I am a proponent of having and using ALL the available tools in a mix and match way if need be. I agree, but what I oppose is the choice of fancy tools because they are fancy rather than because they get the job done better than simple tools, because the fancy tools often carry a price with them over the simpler tools. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Protocol buffer network examples
Hi I am trying to read and write delimited messages[3] using protocol-buffers [1,2] over a socket. I have managed to write delimited messages and I was looking for examples of reading delimited messages. Maybe somebody has an example of reading delimited messages from a socket? The Haskell protocol-buffer[1] package mostly uses bytestrings, but I need to read from a socket. Of cause, I can use the bytestring package to read X number of bytes from a socket-handle. But it is impossible to know what X is, before you start parsing the message, as even integers are variable length in protocol buffers. Hope somebody can help, Mads Lindstrøm [1] http://hackage.haskell.org/package/protocol-buffers [2] http://code.google.com/p/protobuf/ [3] Delimited messages is a protocol buffers technique, where one writes the size of the message before the actual message: http://code.google.com/apis/protocolbuffers/docs/techniques.html#streaming ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On 10/12/10 6:29 AM, Sebastiaan Visser wrote: Gregory, I use arrows (especially list arrows) in a lot of my projects and find them (after some training) easier to work with than monands. Code that I write point-free using arrows generally contains fewer bugs than code I write in monadic style. So what it is that you like is the point-free style rather than the use of arrows. There is nothing stopping you from using point-free style with monads, and I personally prefer to do so when I can. So to repeat this again, I am not arguing against point-free style, I am arguing against basing libraries on arrows instead of monads unless one specifically needs the more general structure of the arrows because otherwise it makes life less convenient for the user as (among other reasons) it introduces extra syntax and prevents use of standard monad combinators and libraries. I think it is unfair to say that arrows add complexity over monads. This statement can only be true to people who actually know monads and do not know arrows. This has more to do with the direction of one's knowledge than the 'complexity' (whatever this means) of a programming abstraction. I can assure you that I have spent a lot of time looking at arrows and even once wrote and used instance of Arrow myself in a situation where a monad would not have been appropriate. To be specific: the additional complexity comes from the fact that additional notation is needed to accomplish the same goal, and from the fact that standard monad combinators and libraries cannot be used. This isn't simply a matter of being unfamiliar with arrows. Don't see arrows a less restricted monads, see them as a generalization of functions, than it will all make sense. Use them in situations that need generalization of functions, not in cases that require the power of monads. I am not sure what you are getting at with this, because your description contradicts my usual notion of when one uses monads and arrows --- namely, when one is working with a structure that fits one or the other of the two patterns and one wants to leverage special libraries and/or syntax. Arrows are a generalisation of functions, so if you know all about working with functions you know (almost) all about working with arrows. When generalizing a pure algorithm, something like f3 . f2 . f1, or in Unix pipe style f1 f2 f3, you don't have to rewrite the code, you just generalize function composition. Yes, but the= operator lets you do the same thing with monads, and in fact I use it all the time to do point-free programming with monads, so this isn't at all an advantage that arrows have over monads. I'd rather use (.) for composition of expressions than (=) and I'd rather use the 'id' for identity than return. Writing my arrow computations point-free as if they were functions feels far less clumsy and a far more readable than monadic style. Fair enough, but again, in exchange for these two operators you lose monadic combinators and libraries and introduce additional syntax. When constructing code, it is of course sometimes simpler to start with a point wise version and then refactor and rewrite it into a more compact point free version. The problem with arrows seems, that the arrow style forces to start with the point free style. And that may be the main hurdle in mind. No, that is not at all the problem with arrows. The problem with arrows is that they are more restrictive than monads in two respects. First, unlike monads, in general they do not let you perform an arbitrary action in response to an input. Second, they place restrictions on how you define the input arguments of the arrow because you can't feed the output of one arrow into to input of the next unless said input is captured in the arrows type. This restriction, though not always, can be very useful. This restriction allows you to do full inspection of the arrow expression. This inspection can in some cases be used to serialize an arrow computation of statically optimize it to a more efficient form. I agree completely! This is *exactly* the kind of time when it is appropriate to use an arrow. The choice of whether to use an arrow or a monad should be based on the structure of the underlying system, with the latter to be preferred unless there is a good reason to choose the former. When you don't need the power of Monads (or ArrowApply) why use a formalism that does provide this power? That will only make it harder to reason about your program, which isn't quite the Haskell way. Because, again, it makes the life of the user of your library easier --- for example, when they decide to use it in a way that is perfectly legitimate but is not something you had thought of in advance. Put another way, why should one place an arbitrary restriction on the user when there is nothing gained by it? I've worked with HXT quite a lot and find XML
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On Tue, Oct 12, 2010 at 3:00 PM, Paolo G. Giarrusso p.giarru...@gmail.com wrote: Were you writing a paper, your comment would be fully valid. Here we're talking about a library for people to use in practice. In the middle, somebody should make sure that people without a PhD can learn arrows, by providing documentation. The problem might be just educational, and it's not restricted to arrows, but it is still a valid problem. Oh, for crying out loud, no it isn't. I don't have a PhD. I don't have any graduate degree at all. I didn't learn anything about functional programming back when I was an undergraduate at a not-exactly-prestigious school, never mind category theory or abstract algebra or any of that stuff, and I only started even learning Haskell barely a year ago. Arrows are easy to understand. Yes, really. I'll agree that a lot of libraries on hackage could stand to have better documentation and examples of usage--and I've not actually used HXT itself so I can't speak to how well it does--but I honestly cannot begin to imagine how using a fairly straightforward type class that's part of the core libraries included with the most popular compiler is a problem. When you write a library for general consumption (like here), you should strive to have a simple and effective interface for people. Arrows *are* a simple and effective interface. Whether they're the best interface to choose for any specific library is a trickier question, of course, but that's because choosing how to structure a library interface is always difficult. Try to think of what's happening. Even the existence of this thread is surprising. Haskell programmers, and experienced ones, are discussing about how to express a two arguments function with arrows. Can you imagine a C programmer asking that? The answer would be RTFM or STFW, or less polite than that. And that's GOOD. You can use arrows because you got an useful intuition of them. Good for you. There's only one way to express a general arrow with two inputs: Use a tuple, because general arrows can't be curried. The discussion is about converting a two-argument function to an arrow directly vs. using one argument as a parameter to a function that constructs a single-input arrow, and the only reason it's an issue is because the syntax for supplying a constant argument to an arrow is a bit clunkier than doing so for a function. A better analogy might be programmers using some OO language discussing whether some piece of usually-static data that an object needs should be a method parameter (likely creating a bunch of redundant code) or set just once by a constructor parameter (awkward in those cases where it does need to change). It is, as Sebastiaan Visser said, an engineering problem, not a conceptual problem. Avoiding arrows would simply produce a different set of engineering problems to consider. Some people argue for 2), but the research bias of the community is still quite strong. And you can't achieve 2) well working with a research methodology. For instance, somebody needs to write _complete_ documentation (I see there is some, but it doesn't cover the basic questions you are discussing), intended for users, rather than papers. Like it happens for any other language. I do get a little tired of finding libraries whose only documentation consists of a couple papers, found in PDF form on the author's university homepage (or worse, no documentation at all). But expecting a library like HXT to walk someone through how to use libraries that are included with GHC seems a bit unreasonable. Of course, nobody _has to do_ anything. I'm a PhD student, I couldn't work on any of this because it wouldn't count for my career. But at least I'm aware my work won't be usable for purpose 2). (Intermediate situations, like writing a paper _and_ a dumbed-down version for general consumption, are also possible of course). I don't like the idea that things need to be dumbed-down for general use. Programmers aren't stupid and they can learn new ideas. Talking about stuff like it's some crazy incomprehensible deep magic that only super-geniuses can understand is silly and not helpful. ...Well, that all probably came out sounding harsher than I intended, my apologies if so. I'm just a little weary of seeing ideas like arrows made out to be more complicated than they really are; I honestly think at least 90% of what makes them seem difficult is people telling each other how difficult they are! - C. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Windows binary for latest darcs head
If oktober 7th would do you can get it at http://www.haskell.org/ghc/dist/current/dist/ http://www.haskell.org/ghc/dist/current/dist/ghc-7.1.20101007-i386-windows.e xe maybe a newer build would show up soon. From: haskell-cafe-boun...@haskell.org [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of Aaron Gray Sent: Tuesday, October 12, 2010 16:43 To: Haskell-Cafe Subject: [Haskell-cafe] Windows binary for latest darcs head Does anyone have a Windows binary for the latest GHC darcs head or at least October 8th they could send me. Many thanks in advance, Aaron ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: Who is afraid of arrows, was Re: [Haskell-cafe] ANNOUNCE: Haskell XML Toolbox Version 9.0.0
On 10/12/10 1:22 PM, Dan Doel wrote: On Tuesday 12 October 2010 4:02:06 pm Gregory Crosswhite wrote: Hughes himself said that when your arrow is an instance of ArrowApply, you are better off just sticking with monads. Well, this is not necessarily good advice. It is true that ArrowApply will preclude some sort of static analysis. But, this does not mean that you cannot do the static analysis on the pieces of code that *can* be written using less powerful arrow combinators. Okay, you make a good point here; it might be the case that it is worth implementing an Arrow interface in order to provide a set of combinators that can do static analysis and hence confer some sort of benefit such as improved performance. The same can be said about Applicative, Monad, etc. The combinators in the former could be implemented in ways that allow some extra analysis to be done, while those in the latter are still available when absolutely necessary. I believe the Utrecht parsing library does this, and encourages parsers to be written in applicative style as much as possible for this reason. Darnit, you are using my own arguments against me here. ;-) I say this because earlier in this forum I personally argued that it there are times when it is beneficial to have the Applicative instance not directly follow the Monad instance so that you do interesting things that you can't do with the Monad instance, such as running computations in parallel. Thus, likewise I am forced to see your point and conclude that it might be useful sometimes to define an Arrow instance in addition to a Monad instance so that the Arrow instance can take advantage of the Arrow structure to do interesting things. This has definitely given me food for thought; thank you. If you have nothing like that to gain, though, it may make sense to jettison arrows due merely to syntactic considerations and the like, though. Yes, I agree, and in fact this the point that I have been trying to make all along. Cheers, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Make your Darcs repositories hashed?
One minor but important note: the hashed format is *not* readable with a darcs-1 program: (after a darcs optimize --upgrade in /opt/repositories/controls/darcs/apps/HoBiCaT) frank...@aragon:~/tmp /usr/bin/darcs --version 1.0.9rc1 (release candidate 1) frank...@aragon:~/tmp /usr/bin/darcs get /opt/repositories/controls/darcs/apps/HoBiCaT Invalid repository: /srv/csr/repositories/controls/darcs/apps/HoBiCaT darcs: /srv/csr/repositories/controls/darcs/apps/HoBiCaT/_darcs/inventory: openBinaryFile: does not exist (No such file or directory) frank...@aragon:~/tmp /opt/darcs/bin/darcs --version 2.0.2 (release) frank...@aragon:~/tmp /opt/darcs/bin/darcs get /opt/repositories/controls/darcs/apps/HoBiCaT Copying patches, to get lazy repository hit ctrl-C... Finished getting. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] The Haskell theme
To kick off discussion about Haskell's general theme, as discussed recently, here's some random ideas. Going with the original colours of the nominated Haskell logo, and kinda what's been done here: http://new-www.haskell.org/haskellwiki/Haskell http://img840.imageshack.us/img840/3577/ideasv.png To download the Inkscape SVG grab it here: http://chrisdone.com/designs/haskell-theme-1.svg I don't know what I was thinking here but it seemed like fun: http://img412.imageshack.us/img412/1827/rect5935.png I get bored really quickly, I was alright for 15 minutes and then I lost the will to point and click. Anyway, I was thinking rather than trying to come up with a brilliant all-encompassing design, we could agree on conventions: * colours * headings * spacing * links * the particular incarnation of the logo etc. I'm pretty happy to go with the colour theme of http://new-www.haskell.org/haskellwiki/Haskell Haskellers.com also makes me think we need an umbrella theme that encompasses all Haskell sites. Maybe we should do a theme poll like the logo poll. I don't know. Regardless, I think we do need to decide on something and stick with it. Should this discussion be taken to the web devel mailing list? Is that appropriate? ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Client-extensible heterogeneous types
On Oct 12, 2010, at 4:24 AM, Jacek Generowicz wrote: I can't see a Haskell solution which combines both of these orthogonal features without losing the benefits of the type system. (For example, I could create my own, weak, type system with tags to identify the type and maps to do the dispatch.) Is there any particular reason why you want to actually to mirror Python code? I think that letting the programmer design domain specific control structures is rather the point of Haskell. Instead of relying on a one-sized fits all solution (which only really fits one kind of problem), you write your own. And it is typically easier to write the control structure than it is to implement it using the OO patterns, because of the notion of irreducible complexity. For example, the Factory pattern constructs a functor. You can write the essential semantics of doing this with a single Functor instance, instead of writing multiple classes which implement the semantics, while relying on implicit, and possibly ill-fitting semantics of method dispatch. The other OO patterns make this objection stronger. If you can write a UML diagram, you can turn it into a commutative diagram, and write less code by implementing its arrows. An OO class hierarchy is a very specific functor over objects (which attaches methods to objects). Haskell provides the Functor type class. Write your generic functions for specific functors: -- The varying input types. Will be attached to arbitrary values by the Functor instance. data A = A -- Variant 1 data B = B -- Variant 2 -- Some normalized Output type. data Output = Output -- The new control structure. data Attaches a = AttachesA A a | AttachesB B a -- Stick your conditional (varying) semantics in here. Corresponds to heterogeneousProcessor. -- The output presumably depends on whether A or B is attached, so this function is not equivalent -- to something of the form fmap (f :: a - Output) (attaches :: Attaches a) runAttaches :: Attaches a - Attaches Output runAttaches = undefined -- This corresponds roughly to heterogeneousProcessor(heterogeneousContainer): processedOutputs :: [Attaches a] - [(Attaches Output)] processedOutputs as = fmap runAttaches as -- Functor instance. Now you have a way to treat an (Attaches a) value just like you would an a. (modulo calling fmap) instance Functor Attaches where fmap f (AttachesA A a) = (AttachesA A (f a)) fmap f (AttachesB B a) = (AttachesB B (f a)) ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Make your Darcs repositories hashed?
On Tue, Oct 12, 2010 at 2:02 PM, Ben Franksen ben.frank...@online.dewrote: One minor but important note: the hashed format is *not* readable with a darcs-1 program: Sorry about that. The support for hashed repos existed long before 2.0 was released and so I misremembered the hashed support as appearing in a 1.x release. It looks like you need at least 2.0 to read darcs 1 hashed repos. Upgrading to a modern darcs client is advised and is only a 'cabal install darcs' away. I was under the impression that even debian stable has moved on to 2.x releases. How is it that you have a 1.0.9 release candidate client still? Jason ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Yi on Windows
Does anyone use Yi on Windows? I've managed to get it to build and run, but it doesn't seem to pick up a config file. This seems to be an issue identified over a year ago: http://code.google.com/p/yi-editor/issues/detail?id=269. This would seem to render the editor almost completely useless on Windows. The whole point is to have an editor you can customize in Haskell. Any suggestions appreciated. Thanks Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: A question regarding cmdargs package
Neil Mitchell wrote: This makes me curious. What's the use case where you want to allow the user to pass arguments on the command line, but you don't want that user to be able to use '--help' to find out what arguments may be passed? I wanted to create a clone of an existing program that had no help option and instead gave the help output if it saw an invalid option. When you don't want to bother defining the help options/descriptions? :p (alternatively, you may wish to provide a more full-featured version like what darcs does by using a pager) You can already do this with CmdArgs. If you use cmdArgsMode/process it returns a structure populated to say what to do next (i.e. display a help message), but you are welcome to do something different, or do what it says in a different way. However, I can see some people might want to remove help entirely, so I'll try and find a balance. The point here was not so much removing --help, but rather that I want to have control over the 'standard' options (help,version,verbosity) in the same way as for the rest. My program might not have a version, so why offer --version? Or maybe I want a different name for it because the -V is already used for something else, which I cannot change for backwards compatibility. I might want another name for --help, for instance -h. The standard -? does not work in all shells/configurations and --help might look strange if all other options are of the one-dash-one-character sort. I would also like to configure the help text for the standard options, for instance for i18n or because I like starting with a lower case letter or... Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: A question regarding cmdargs package
Joachim Breitner wrote: Am Dienstag, den 12.10.2010, 16:42 +1100 schrieb Ivan Lazar Miljenovic: On 12 October 2010 16:32, Magnus Therning mag...@therning.org wrote: This makes me curious. What's the use case where you want to allow the user to pass arguments on the command line, but you don't want that user to be able to use '--help' to find out what arguments may be passed? When you don't want to bother defining the help options/descriptions? :p note that people expect cmd --help to at least do nothing. So if your program is called launchMissiles, please make it at least spit out a message like your evil dictator was too lazy to write a help message when it is called with --help. (That is if you are sharing your program. Not sure if you should share launchMissiles at all.) launchMissiles = putStrLn Boom! (just kidding :) BTW another cool feature of an auto-magic option parsing lib is the GNU standard -- (arguments after this are not to be treated as options). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Haskellers.com recent changes (and I need some volunteers)
Roman Cheplyaka wrote: On Mon, 11 Oct 2010 13:09:00 +0200, Vo Minh Thu not...@gmail.com wrote: 2010/10/11 Roman Cheplyaka r...@ro-che.info: On Mon, 11 Oct 2010 11:54:12 +0100, Magnus Therning mag...@therning.org wrote: On Mon, Oct 11, 2010 at 08:37, Michael Snoyman mich...@snoyman.com wrote: [...] Also, now 10 random profiles will be displayed on the homepage. Only verified users will be displayed here. I'm also considering adding a new status as well: real picture, so that only people with real images (not cartoons, not identicons) can show up on the homepage. I think this might give a more professional feel. Thoughts? I'd be weary of making that a requirement, there are good reasons for not putting your picture on the web, just like there are good reasons to not use your real name :-) ... just like there are good reasons not to publish yourself in a public catalogue (such as haskellers.com) at all. I have nothing against anonymity. I voted against requirement of real names on hackage. But in this particular case, the whole point to be in the listing is to present yourself. So I find the above proposal very reasonable. Hi, In the belgian law, an employer can (of course) request a faithful resume, but cannot request the resume to contain a picture of you. This is a clear example where you wish to advertise yourself, but not necessarily with a picture. Anyway, I don't think it is difficult to imagine situations where one doesn't wish to show a picture of his/her face. Agree. But then there should be no picture at all for a given person. As Michael said -- no cartoons, no identicons. Why not? They can say more about a person than a picture (not some generic, auto-chosen one, of course). Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Re: Make your Darcs repositories hashed?
Jason Dagit wrote: On Tue, Oct 12, 2010 at 2:02 PM, Ben Franksen ben.frank...@online.dewrote: One minor but important note: the hashed format is *not* readable with a darcs-1 program: Sorry about that. The support for hashed repos existed long before 2.0 was released and so I misremembered the hashed support as appearing in a 1.x release. It looks like you need at least 2.0 to read darcs 1 hashed repos. Upgrading to a modern darcs client is advised and is only a 'cabal install darcs' away. I was under the impression that even debian stable has moved on to 2.x releases. How is it that you have a 1.0.9 release candidate client still? Have you ever worked at a public institution? I recommend the experience... ;-) Seriously, the server is a debian etch (!) system. Also called debian old-stable. Of course I have long since installed newer version of darcs, but since I am not root there I cannot put it into /usr/local, so I cannot completely rule out the possibility that other users still use the ancient /usr/bin/darcs and will now have problems when they darcs get. I do _not_ expect that this will lead to any serious trouble, as the latest stable darcs is just a small addition to the PATH away. Still, users should be warned that darcs-2.x is required. Cheers Ben ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] a couple of cabal related questions
On 13 October 2010 02:00, Magnus Therning mag...@therning.org wrote: On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com wrote: By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere? I don't know, I think I found it in the source more or less by mistake :-) Yeah, I think that's the common consensus; there is _some_ documentation of the Paths_foo module in the Cabal user guide, but it doesn't cover much. One thing I do wish was possible: the ability to use a stub Paths_foo module for testing purposes (as currently you have to have done a cabal configure cabal build to get it), but I couldn't find a way to do so without Cabal packaging the stub version when creating the distribution tarball :s -- Ivan Lazar Miljenovic ivan.miljeno...@gmail.com IvanMiljenovic.wordpress.com ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] The Haskell theme
On Oct 6, 2010, at 12:10 PM, Don Stewart wrote: * haskell visual design group? + consistent color themes across haskell.org sites. + consistent haskell branding. On Oct 12, 2010, at 2:17 PM, Christopher Done wrote: To kick off discussion about Haskell's general theme, as discussed recently, here's some random ideas. I was there for the BoF discussion, and this was one of the topics I was there to discuss. I spent some time beforehand looking at what other successful language communities do w.r.t. visual design. I found that none of the communities had a single theme; most had two or three. but these themes were visually harmonious. Furthermore, I found that they were used consistently, and that the various themes were generally at the same level of polish. For Haskell I think this means that while it isn't essential that we have a single common theme on all properties, it is important that various site designers think of the whole look of Haskell when designing their projects. This means leaning toward consistent colors, and logo form, rather than exact layout. Further, it seems more important that our projects get designers who will do a thorough job, and less important that it be a single central design group. It is no accident that the new Haddock backend looks like the new wiki design: Thomas Schilling (nominolo) supplied the initial style sheet that the Haddock team used to build the Ocean theme. I think this exemplifies what we should strive for: The two projects look well together, look like they have a relationship, and both are full treatments of their subjects. It isn't so important that they have identical layouts or details. Since parts of the Hackage site integrate so closely with the Haddock output, I've been asked if I would take a stab at styling the new Hackage (or at least the package pages). I'll be aiming to make that fit, but without being 100% rigid about conformance to the Ocean output. http://img840.imageshack.us/img840/3577/ideasv.png Lovely ideas there and I think a Haskell project built on those lines would continue to look well with the wiki and Haddock. I don't know what I was thinking here but it seemed like fun: http://img412.imageshack.us/img412/1827/rect5935.png For some projects, I could imagine this feel would be more appropriate - yet still, there is enough tie-in to make it part of the family. Maybe we should do a theme poll like the logo poll. I don't know. Regardless, I think we do need to decide on something and stick with it. Should this discussion be taken to the web devel mailing list? Is that appropriate? I'd lean toward us putting these thoughts down in the wiki, and developing a set of guide posts for styling Haskell, rather than a strict set of policies. - Mark ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Yi on Windows
That bug is probably no longer correct. We now use the dyre package for loading the config. Does anybody know if dyre works on Windows in general? On Tue, Oct 12, 2010 at 5:39 PM, Peter Marks pe...@indigomail.net wrote: Does anyone use Yi on Windows? I've managed to get it to build and run, but it doesn't seem to pick up a config file. This seems to be an issue identified over a year ago: http://code.google.com/p/yi-editor/issues/detail?id=269. This would seem to render the editor almost completely useless on Windows. The whole point is to have an editor you can customize in Haskell. Any suggestions appreciated. Thanks Peter ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- Jeff Wheeler Undergraduate, Electrical Engineering University of Illinois at Urbana-Champaign ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: Polyvariadic functions operating with a monoid
I have turned the code into a library and put it up on github here:
http://github.com/kevinjardine/polyToMonoid
The library includes two versions of the function: ptm does not
require a termination function but does not allow partial evaluation
either. ctm is more composable (returning a function that consumes the
next parameter) and requires a termination function trm to return the
result.
The source includes thorough Haddock friendly comments with examples.
My plan is to upload it to Hackage later this week but I wondered if
anyone had any comments before I do.
Kevin
On Oct 11, 11:08 am, Kevin Jardine kevinjard...@gmail.com wrote:
It also appears that we need type families to reconstruct the original
Haskell list system using polyToMonoid.
instance (a ~ a') = Monoidable a [a'] where
toMonoid a = [a]
testList = putStrLn $ show $ polyToMonoid (mempty :: [a]) a b c
Given this instance of Monoidable, you can put any number of values
after
polyToMonoid (mempty :: [a]) as long as they are exactly the same
type.
In other words, this acts exactly like the usual Haskell list, going
back to my original point that polyToMonoid is a sort of generalised
list or a function that takes a bunch of values that can be stuck
together in some way.
I am a bit surprised that the (a ~ a') is needed, but Haskell will
not compile this code with the more usual
instance Monoidable a [a] where
toMonoid a = [a]
Kevin
On Oct 11, 9:54 am, Kevin Jardine kevinjard...@gmail.com wrote:
Hi Oleg,
I've found that if I also add two other slightly scary sounding
extensions: OverlappingInstances and IncoherentInstances, then I can
eliminate the unwrap function *and* use your type families trick to
avoid the outer type annotation.
My latest code is here:
{-# LANGUAGE TypeSynonymInstances, FlexibleInstances,
MultiParamTypeClasses, TypeFamilies #-}
{-# LANGUAGE OverlappingInstances, IncoherentInstances #-}
module PolyTest where
import Data.Monoid
class Monoid m = Monoidable a m where
toMonoid :: a - m
squish :: Monoidable a m = m - a - m
squish m a = (m `mappend` (toMonoid a))
class Monoid m = PolyVariadic m r where
polyToMonoid :: m - r
instance (Monoid m', m' ~ m) = PolyVariadic m m' where
polyToMonoid acc = acc
instance (Monoidable a m, PolyVariadic m r) = PolyVariadic m (a-r)
where
polyToMonoid acc = \a - polyToMonoid (squish acc a)
Here are three examples. The resulting notation is short enough now
that I am no longer tempted to use CPP.
All you need to do is to specify the type for mempty. And even this
can be skipped if you want to put in the specific mempty value
(although I think that the type annotation is often better if slightly
longer as it documents clearly what monoid the result is being mapped
into).
-- [String] example
instance Show a = Monoidable a [String] where
toMonoid a = [show a]
testStringList = putStrLn $ show $ polyToMonoid (mempty :: [String])
True () (Just (5::Int))
-- String example
instance Show a = Monoidable a String where
toMonoid a = show a
testString = putStrLn $ polyToMonoid (mempty :: String) True () (Just
(5::Int))
-- product example
instance Monoid Double where
mappend = (*)
mempty = (1.0) :: Double
instance Monoidable Int Double where
toMonoid = fromIntegral
instance Monoidable Double Double where
toMonoid = id
testProduct = putStrLn $ show $ polyToMonoid (mempty :: Double) (5 ::
Int) (2.3 :: Double) (3 :: Int) (8 :: Int)
main = do
testStringList
testString
testProduct
$ runhaskell PolyTest.hs
[True,(),Just 5]
True()Just 5
276.0
Kevin
On Oct 11, 2:39 am, o...@okmij.org wrote:
Sorry, I'm still catching up. I'm replying to first few messages.
instance Show a = Monoidable a [String] where
toMonoid a = [show a]
main = putStrLn $ unwrap $ polyToMonoid [] True () (Just (5::Int))
fails to compile.
The error message points to the first problem:
No instances for (Monoidable Bool [a],
Monoidable () [a],
...
The presence of the type variable 'a' means that the type checker
doesn't know list of what elements you want (in other words, the
context is not specific enough to instantiate the type variable
a). Thus, we need to explicitly tell that we wish a list of strings:
test3 = putStrLn $ unwrap $polyToMonoid ([]::[String]) True () (Just
(5::Int))
Now we get a different error, which points to the real problem this
time: the expression `unwrap ' appears as an argument to
putStrLn. That means that we are required to produce a String as a
monoid. Yet we specified ([]::[String]) as mempty, which is unsuitable
as mempty for the String monoid. If we desire the [String] monoid as
the result, we need to change the context. For example,
test3 = mapM_
Re: [Haskell-cafe] a couple of cabal related questions
On Tue, Oct 12, 2010 at 10:41 PM, Ivan Lazar Miljenovic ivan.miljeno...@gmail.com wrote: On 13 October 2010 02:00, Magnus Therning mag...@therning.org wrote: On Tue, Oct 12, 2010 at 15:34, Dmitry V'yal akam...@gmail.com wrote: By the way, the 'version' variable doesn't mentioned in Cabal user guide, or at least I missed it. Is it documented somewhere? I don't know, I think I found it in the source more or less by mistake :-) Yeah, I think that's the common consensus; there is _some_ documentation of the Paths_foo module in the Cabal user guide, but it doesn't cover much. One thing I do wish was possible: the ability to use a stub Paths_foo module for testing purposes (as currently you have to have done a cabal configure cabal build to get it), but I couldn't find a way to do so without Cabal packaging the stub version when creating the distribution tarball :s I've used CPP, something like: module MyPaths ( export contents of Paths_magic ) where #ifdef SOME_DEF_SET_BY_CABAL import Paths_magic #else mock implementation of paths magic here #endif Then in your .cabal file declare the define which causes it to use the real magic paths module. When not compiling via cabal, you'll at least have something sensible (like the current directory or something). I'm pretty sure I didn't make this up, but I have used it. It's a bit of a pain to set up, though. Antoine ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: Re: A question regarding cmdargs package
The point here was not so much removing --help, but rather that I want to have control over the 'standard' options (help,version,verbosity) in the same way as for the rest. My program might not have a version, so why offer --version? Or maybe I want a different name for it because the -V is already used for something else, which I cannot change for backwards compatibility. I might want another name for --help, for instance -h. The standard -? does not work in all shells/configurations and --help might look strange if all other options are of the one-dash-one-character sort. I would also like to configure the help text for the standard options, for instance for i18n or because I like starting with a lower case letter or... That i18n is a fantastic argument - and one that really means cmdargs has no choice but to support all the attributes on help/version. BTW another cool feature of an auto-magic option parsing lib is the GNU standard -- (arguments after this are not to be treated as options). cmdargs also supports this by default. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
