Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
Twan van Laarhoven wrote: My point is that desugaring "x.f" to "(f x)" and treating some instances of "(f x)" as "(ModuleToGuess.f x)" are two separate things. In the current proposal these two are combined, but I see no reason to do so. To be a bit more concrete, I would propose: * General Type Directed Name Resolution (GTDNR): For every function application "f x" in the program where "f" is a name, "f" is resolved based on the type of the argument "x". Note that I am not saying that this is necessarily a good idea, it is just a possible alternative to the current TDNR proposal. I'm not a big fan of any of the TDNR proposals I've seen (I think we still haven't found the right way to do it without it being just a hack), but I can give one good reason for why these two parts of the proposal are grouped together. You suggest that GTDNR might not be a good idea, well why not? One reason is that it can potentially lead to a whole lot of guessing, slowing the compiler down dramatically and maybe even so much guessing that there are multiple whole-program resolutions (oh noes!). So how can we control that combinatorial exploration of alternatives? One way would be to restrict the places where we allow guessing. There's still potential room for combinatorial explosions but they're greatly reduced, both because we reduce the number of variables in the problem (so the combinatorics are smaller), and because we (generally) will have a good deal of non-variable context to anchor the disambiguation process and hopefully resolve the variables easily. -- Live well, ~wren ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: feldspar-language
On Fri, Nov 20, 2009 at 4:14 AM, Warren Henning wrote: > Interesting to see actual generated code. > > Is this like code generation systems for database applications where > you stick stuff into string templates (e.g., a generator in Ruby on > Rails), or is it actually compiling an embedded domain specific > language? Atom is not a macro expansion language by any stretch. It does let you write primitive actions as C strings, but the core of the language is based on GADTs and type classes. In fact, the example I posted contained no custom primitive actions; the C code was rendered purely from the core datatypes. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: feldspar-language
Interesting to see actual generated code. Is this like code generation systems for database applications where you stick stuff into string templates (e.g., a generator in Ruby on Rails), or is it actually compiling an embedded domain specific language? On Thu, Nov 19, 2009 at 6:55 PM, Tom Hawkins wrote: > Yes, but only by creating a custom primitive (see 'action'). But then > you're writing in C, not Atom. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Fwd: [Haskell-cafe] ANNOUNCE: feldspar-language
-- Forwarded message -- From: Tom Hawkins Date: Thu, Nov 19, 2009 at 9:31 PM Subject: Re: [Haskell-cafe] ANNOUNCE: feldspar-language To: Emil Axelsson On Thu, Nov 19, 2009 at 5:58 PM, Emil Axelsson wrote: > Hi Tom, thanks for the code! > > Is my understanding correct that `filter` in the C code performs evaluation > of one cycle, and someone else will take care of calling it repeatedly on > the input stream? This is correct. In our application there is no buffered steam. Instead this code is processing data immediately after it is sampled by the ADCs; in our case once every 1ms. > > Is there a way to avoid rolling out the summation loops fully? Yes, but only by creating a custom primitive (see 'action'). But then you're writing in C, not Atom. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: gnome-keyring 0.1 (bindings to libgnome-keyring)
For those interested, I've just released 0.2 -- no new features, but it's got a slightly cleaner API. Fewer modules, proper datetime types, and a few more documentation entries. And the innards are sane now. https://dl.dropbox.com/u/1947532/gnome-keyring_0.2/index.html http://hackage.haskell.org/package/gnome-keyring ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: community.haskell.org is down
On Thu, 2009-11-19 at 21:15 +, Neil Mitchell wrote: > Hi, > > community.haskell.org isn't responding, I get connection failures. Ta, sorted. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: bindings-SDL 1.0.2, the domain specific language for FFI description
> I had two structs, one of which used the other as a field type. > I was using the generated identifier of the first as the type > for the second, so it had the form c'STRUCT_NAME. So the field > macro looked like this: > > #field foo , c'STRUCT_NAME > > It did not like this, complaining about the single quote. > > I have since noticed the notation in the > documentation. Perhaps the actual bug is that this notation was > not pointed out in prose? I believe I forgot to write a section with that information, as well as others one would like to know from start. I wrote a new section trying to fix that in 'how to use it' topic. http://bitbucket.org/mauricio/bindings-dsl/wiki/HowToUseIt I'm not sure I have already got to a point where documentation is clear and complete enough but not too long and boring. If you also thing some parts of documentation were not helpful, or if more is missing, please let me know. Thanks for your feedback. Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] prologue junk on ppc (debian)
Got the following: Building uvector-0.1.0.5... [ 1 of 13] Compiling Data.Array.Vector.Prim.Text ( Data/Array/Vector/Prim/Text.hs, dist/build/Data/Array/Vector/Prim/Text.o ) Prologue junk?: .type sD7_entry, @function sD7_entry: # 25 "/tmp/ghc14266_0/ghc14266_0.hc" 1 That seems bad... The Glorious Glasgow Haskell Compilation System, version 6.10.4 This is the deb ghc6 package for unstable. Cabal was installed using ghc 6.8.x. I tried re-installing a couple of other cabal packages, including hps and bytestring, and they went through without a hitch. Brian ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] community.haskell.org is down
Hi, community.haskell.org isn't responding, I get connection failures. Thanks, Neil ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANN: bindings-SDL 1.0.2, the domain specific language for FFI description
Maurício CA wrote: > My only complaint is that the macros get confused if you use a > Haskell type that has a single quote in it. Can you give me an example? It turns out that I read the documentation incorrectly, but here is what I was trying to do. I had two structs, one of which used the other as a field type. I was using the generated identifier of the first as the type for the second, so it had the form c'STRUCT_NAME. So the field macro looked like this: #field foo , c'STRUCT_NAME It did not like this, complaining about the single quote. I have since noticed the notation in the documentation. Perhaps the actual bug is that this notation was not pointed out in prose? - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Literate refactoring?
I'd like to ask the cafe's advice on how to 'do this right'. The situation is that we've got 2 literate Haskell programs which we would like to refactor. In fact, this refactoring will ultimately unify these 2 separate programs into a single framework. Every refactoring step is well-defined and induces a discrete modification. These programs also come with tests of their own, which we would like to refactor along with the code. In the end, we would like to obtain: 1. For each discrete step, full working programs, with tests and literate comments 2. A technical report which describes all the steps from #1 above, as a literate Haskell document. For the TechReport, we don't need to be able to extract working code from it, but the code which is in it should be chunks of the working programs, not 'independent'. Especially as some of the 'discrete steps' will result in dead ends, which we want to document, but not otherwise pursue. In other words, the set of "discrete programs" do not form a total linear order, but is more like a linear order with a few short branches hanging off of it. We were thinking that using some combination of scripts, 'patches', features from subversion and literate Haskell documents should allow us to do this. In an ideal world, it would be nice if what we stored was only (generalized) patches, and we could generate #1 and #2 above from that. [These patches would be generalized because they would contain descriptions of what the patch is about, as well as actual patches; though perhaps that description is really just a patch to the TechReport, we're not sure]. We were able to envision a number of different partial solutions, but somehow none of them 'came together' well enough to feel satisfactory. Instead of biasing the cafe's thinking by laying those pieces out, I figured I would lay out the high-level requirements, and let creative solutions come in. Jacques ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANN: bindings-SDL 1.0.2, the domain specific language for FFI description
> I did not notice when this was released, but I saw it on Hackage > yesterday and, with it, wrote some of the easiest bindings to a > fairly complex C API I've written in a while. This package is > excellent! Thank you for sharing it. Thanks. My hope is that it saves as much time from users as the support from this community saved for me. > My only complaint is that the macros get confused if you use a > Haskell type that has a single quote in it. Can you give me an example? Best, Maurício ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANN: bindings-SDL 1.0.2, the domain specific language for FFI description
I did not notice when this was released, but I saw it on Hackage yesterday and, with it, wrote some of the easiest bindings to a fairly complex C API I've written in a while. This package is excellent! Thank you for sharing it. My only complaint is that the macros get confused if you use a Haskell type that has a single quote in it. - Jake ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: (possibly) a list comprehensions question
You're right. I do that sometimes, but I must make a habit of "hoogling". 2009/11/19 yair...@gmail.com > > This is what happens all the time, the thing I am trying to implement is > already in the library! > > You can easily find those library functions using Hoogle. > In this case Hoogle gives the "sequence" function as its second result > for the query "[[a]] -> [[a]]": > > Data.List transpose :: [[a]] -> [[a]] > Prelude sequence :: Monad m => [m a] -> m [a] > > See: http://haskell.org/hoogle/?hoogle=%5B%5Ba%5D%5D+-%3E+%5B%5Ba%5D%5D > > On Nov 19, 3:58 pm, Ozgur Akgun wrote: > > Thanks for the both quick answers. > > > > This is what happens all the time, the thing I am trying to implement is > > already in the library! > > > > Neil, > > I clearly understood the way you implemented. Actually I had a similar > > implementation with some problems, one of which is the base-case you > > mentioned. > > > > Eugene, > > I'll definitely have a look at the implementation of sequence. > > > > Cheers! > > > > 2009/11/19 Neil Brown > > > > > > > > > > > > > Ozgur Akgun wrote: > > > > >> Anyway, just forget the fact that these funstions do not do a check on > the > > >> length of the input list for a moment. My question is, how can I > generalize > > >> this function to accept a list of lists of arbitrary length, and > produce the > > >> required result. > > > > > Hi, > > > > > The concise solution is the list monad, as already posted. If that > > > confuses you, here is a version using list comprehensions (well, > mostly): > > > > > allPossibilities :: [[a]] -> [[a]] > > > allPossibilities [] = [[]] > > > allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] > > > > > The second line prefixes all possibilities from the later lists with > every > > > element from the the first list. Note that the base-case is crucial; > if it > > > is the empty list [], that "xs <- allPossibilities ls" will not find > any > > > elements, and thus the list comprehension becomes the empty list, and > the > > > whole thing falls apart. Thus the base case must be the list > containing the > > > empty list, so that you have one possibility arising at the end upon > which > > > to prefix the items. Hope that makes sense... > > > > > Thanks, > > > > > Neil. > > > > -- > > Ozgur Akgun > > > > ___ > > Haskell-Cafe mailing list > > haskell-c...@haskell.orghttp:// > www.haskell.org/mailman/listinfo/haskell-cafe > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] How to show record syntax?
Just an aside, derived Show doesn't try to be truly minimal with respect to
superfluous ()'s at this point, for instance it doesn't take into
consideration that when using infixl or infixr you can elide them on one
side, so there is already a precedent for the fact that the ()'s that get
used are not minimal.
That said, I think there is nothing wrong with using the fact that records
bind tighter than application, and 'fixing the grammar' to prevent that
would break a fair bit of code -- I know that I for one use it fairly often.
So, I'm not in favor of proposing a breaking change to the grammar for
Haskell' that removes this functionality.
Eliding the superfluous parens around records in derived Show feels like the
right solution as it imparts less noise in the output.
A very minor concern would be making sure that Read can handle input with or
without the superfluous parentheses, but as I understand things that should
come more or less for free, given that they just wrap the value.
This would let values that were serialized on an older version continue to
be read in the current version, for people who are using Show as a data
storage format.
-Edward Kmett
On Tue, Nov 17, 2009 at 11:14 AM, Sean Leather wrote:
> A while back, I was working on the Show function for EMGM [1] and verifying
> its output vs. that of GHC's when I discovered (I thought) a minor
> difference between what was necessary and what GHC did for record syntax.
> Labeled construction and update, according to the Report [2], have higher
> precedence than function application. This means that I can do the following
>
> > module Main where
> > data A = A {x :: Int} deriving Show
> > main = print $ Just A {x = 5}
>
> without putting parentheses around A {x = 5}. If I run this in GHCi,
>
> *Main> main
> Just (A {x = 5})
>
> I see that the derived show in GHC adds parentheses around the record
> value.
>
> This led to an issue report [3] which developed a few responses. Some don't
> like the grammar as defined, because, at a glance, it appears too much like
> function application. Others noted that Hugs does not add the parentheses
> and wanted to see consistency between compilers.
>
> In the spirit of the GHC Bug Sweep [4] and finding resolution, I put the
> question to the wider community. How should we show record syntax? Should we
> try to ensure consistency between the compilers? Should we try to print as
> few parentheses as possible? Should we write a Haskell' proposal to "fix"
> the grammar and make Just A {x=5} illegal? What do you think?
>
> [1]
> http://hackage.haskell.org/packages/archive/emgm/0.3.1/doc/html/Generics-EMGM-Functions-Show.html
> [2] http://www.haskell.org/onlinereport/exps.html#sect3
> [3] http://hackage.haskell.org/trac/ghc/ticket/2530
> [4] http://hackage.haskell.org/trac/ghc/wiki/BugSweep
>
> Regards,
> Sean
>
> ___
> Haskell-Cafe mailing list
> Haskell-Cafe@haskell.org
> http://www.haskell.org/mailman/listinfo/haskell-cafe
>
>
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] If you haven't bought any of Knuth's fascicles yet, this is definitely the one to get. Bitwise Tricks & Techniques
One of Knuth's sources is the well-named book "Hacker's Delight" by Henry S. Warren; see hackersdelight.org ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: (possibly) a list comprehensions question
> This is what happens all the time, the thing I am trying to implement is already in the library! You can easily find those library functions using Hoogle. In this case Hoogle gives the "sequence" function as its second result for the query "[[a]] -> [[a]]": Data.List transpose :: [[a]] -> [[a]] Prelude sequence :: Monad m => [m a] -> m [a] See: http://haskell.org/hoogle/?hoogle=%5B%5Ba%5D%5D+-%3E+%5B%5Ba%5D%5D On Nov 19, 3:58 pm, Ozgur Akgun wrote: > Thanks for the both quick answers. > > This is what happens all the time, the thing I am trying to implement is > already in the library! > > Neil, > I clearly understood the way you implemented. Actually I had a similar > implementation with some problems, one of which is the base-case you > mentioned. > > Eugene, > I'll definitely have a look at the implementation of sequence. > > Cheers! > > 2009/11/19 Neil Brown > > > > > > > Ozgur Akgun wrote: > > >> Anyway, just forget the fact that these funstions do not do a check on the > >> length of the input list for a moment. My question is, how can I generalize > >> this function to accept a list of lists of arbitrary length, and produce > >> the > >> required result. > > > Hi, > > > The concise solution is the list monad, as already posted. If that > > confuses you, here is a version using list comprehensions (well, mostly): > > > allPossibilities :: [[a]] -> [[a]] > > allPossibilities [] = [[]] > > allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] > > > The second line prefixes all possibilities from the later lists with every > > element from the the first list. Note that the base-case is crucial; if it > > is the empty list [], that "xs <- allPossibilities ls" will not find any > > elements, and thus the list comprehension becomes the empty list, and the > > whole thing falls apart. Thus the base case must be the list containing the > > empty list, so that you have one possibility arising at the end upon which > > to prefix the items. Hope that makes sense... > > > Thanks, > > > Neil. > > -- > Ozgur Akgun > > ___ > Haskell-Cafe mailing list > haskell-c...@haskell.orghttp://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
Nicolas Pouillard wrote: The TDNR proposal really tries to do two separate things: 1. Record syntax for function application. The proposal is to tread "x.f" or a variation thereof the same as "(f x)" It is more like "(ModuleToGuess.f x)" than "(f x)". My point is that desugaring "x.f" to "(f x)" and treating some instances of "(f x)" as "(ModuleToGuess.f x)" are two separate things. In the current proposal these two are combined, but I see no reason to do so. To be a bit more concrete, I would propose: * General Type Directed Name Resolution (GTDNR): For every function application "f x" in the program where "f" is a name, "f" is resolved based on the type of the argument "x". Note that I am not saying that this is necessarily a good idea, it is just a possible alternative to the current TDNR proposal. Twan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Some useful TH templates
Hi,
I wrote some Template Haskell templates that I think may be of use to others.
The first generates "in" and "with" functions for newtypes.
For example, using it one can replace this code (from TypeCompose):
> inFlip :: ((a~>b) -> (a' ~~> b')) -> (Flip (~>) b a -> Flip (~~>) b' a')
> inFlip = (Flip .).(. unFlip)
>
> inFlip2 :: ((a~>b) -> (a' ~~> b') -> (a'' ~~~> b''))
>-> (Flip (~>) b a -> Flip (~~>) b' a' -> Flip (~~~>) b'' a'')
> inFlip2 f (Flip ar) = inFlip (f ar)
>
> inFlip3 :: ((a~>b) -> (a' ~~> b') -> (a'' ~~~> b'') -> (a''' > b'''))
> -> (Flip (~>) b a -> Flip (~~>) b' a' -> Flip (~~~>) b'' a'' -> Flip
> (>) b''' a''')
> inFlip3 f (Flip ar) = inFlip2 (f ar)
with this code:
> {-# LANGUAGE TemplateHaskell #-}
> import Data.Newtype
> $(mkInNewtypeFuncs [1..3] ''Flip)
The second template is for accessing ADTs in the Maybe monad. For example:
> {-# LANGUAGE TemplateHaskell #-}
> import Data.ADT.Getters
> data Blah a = NoBlah | YesBlah a | ManyBlah a Int
> $(mkADTGetters ''Blah)
Generates:
> gNoBlah :: Blah a -> Maybe ()
> gYesBlah :: Blah a -> Maybe a
> gManyBlah :: Blah a -> Maybe (a, Int)
I'm more than willing to upload these templates to hackage (or rather,
split them out of an unrelated package),
but all I need is a suggestion for a package name :)
For now you can find these here:
http://hackage.haskell.org/package/peakachu
Hoping someone else will find it useful,
cheers,
Yair
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (possibly) a list comprehensions question
Thanks for the both quick answers. This is what happens all the time, the thing I am trying to implement is already in the library! Neil, I clearly understood the way you implemented. Actually I had a similar implementation with some problems, one of which is the base-case you mentioned. Eugene, I'll definitely have a look at the implementation of sequence. Cheers! 2009/11/19 Neil Brown > Ozgur Akgun wrote: > >> Anyway, just forget the fact that these funstions do not do a check on the >> length of the input list for a moment. My question is, how can I generalize >> this function to accept a list of lists of arbitrary length, and produce the >> required result. >> > > Hi, > > The concise solution is the list monad, as already posted. If that > confuses you, here is a version using list comprehensions (well, mostly): > > allPossibilities :: [[a]] -> [[a]] > allPossibilities [] = [[]] > allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] > > The second line prefixes all possibilities from the later lists with every > element from the the first list. Note that the base-case is crucial; if it > is the empty list [], that "xs <- allPossibilities ls" will not find any > elements, and thus the list comprehension becomes the empty list, and the > whole thing falls apart. Thus the base case must be the list containing the > empty list, so that you have one possibility arising at the end upon which > to prefix the items. Hope that makes sense... > > Thanks, > > Neil. > -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (possibly) a list comprehensions question
Ozgur Akgun wrote: Anyway, just forget the fact that these funstions do not do a check on the length of the input list for a moment. My question is, how can I generalize this function to accept a list of lists of arbitrary length, and produce the required result. Hi, The concise solution is the list monad, as already posted. If that confuses you, here is a version using list comprehensions (well, mostly): allPossibilities :: [[a]] -> [[a]] allPossibilities [] = [[]] allPossibilities (l:ls) = [ x : xs | x <- l, xs <- allPossibilities ls] The second line prefixes all possibilities from the later lists with every element from the the first list. Note that the base-case is crucial; if it is the empty list [], that "xs <- allPossibilities ls" will not find any elements, and thus the list comprehension becomes the empty list, and the whole thing falls apart. Thus the base case must be the list containing the empty list, so that you have one possibility arising at the end upon which to prefix the items. Hope that makes sense... Thanks, Neil. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] (possibly) a list comprehensions question
You can easily use "sequence". The less easy part is understanding why it works. Are you familiar with monads? If you are not, try to take the source code of 'sequence', inline it and understand why *that* works. Prelude> map sum $ sequence [[1,2], [10,20], [100,200]] [111,211,121,221,112,212,122,222] 2009/11/19 Ozgur Akgun : > Hi Cafe! > > I am struggling with an interesting problem while defining a function. It > looks quite easy to me, but I couldn't manage to have a proper > implementation yet. > To illustrate what I'm trying to achive, I'll introduce special cases of the > desired function, and hopefully build towards a solution step by step. > > -- simplest case, taking 2 lists as parameters and returning a list of list > containing every possible pair (but represented as lists) > allPossibilities2 :: [a] -> [a] -> [[a]] > allPossibilities2 listX listY = [ [x,y] | > x <- listX, > y <- listY] > > -- sample output > -- allPossibilities2 [1,2,3] [7,8,9] > -- [[1,7],[1,8],[1,9],[2,7],[2,8],[2,9],[3,7],[3,8],[3,9]] > > > -- simplest case with 3 parameters instead of 2 > allPossibilities3 :: [a] -> [a] -> [a] -> [[a]] > allPossibilities3 listX listY listZ = [ [x,y,z] | > x <- listX, > y <- listY, > z <- listZ] > > -- allPossibilities3 [1,2] [3,4,5] [6,7] > -- > [[1,3,6],[1,3,7],[1,4,6],[1,4,7],[1,5,6],[1,5,7],[2,3,6],[2,3,7],[2,4,6],[2,4,7],[2,5,6],[2,5,7]] > > > These are easy and work just fine. All I want to do is to generalize this > function receiving n lists as parameters and doing the simple action > described above. Since I cannot pass variable number of parameters to a > function, I'll use list of lists from now on. > Following are the implementations of the same functions with different types > (instead of two lists, a list of lists assumed to caontain those 2 elements) > > allPossibilities2' :: [[a]] -> [[a]] > allPossibilities2' list = [ [x,y] | > x <- list !! 0, > y <- list !! 1] > > -- allPossibilities2' [[1,2,3],[7,8,9]] > -- [[1,7],[1,8],[1,9],[2,7],[2,8],[2,9],[3,7],[3,8],[3,9]] > > allPossibilities3' :: [[a]] -> [[a]] > allPossibilities3' list = [ [x,y,z] | > x <- list !! 0, > y <- list !! 1, > z <- list !! 2] > > -- allPossibilities3' [[1,2],[3,4,5],[6,7]] > -- > [[1,3,6],[1,3,7],[1,4,6],[1,4,7],[1,5,6],[1,5,7],[2,3,6],[2,3,7],[2,4,6],[2,4,7],[2,5,6],[2,5,7]] > > > This is ugly! > > Anyway, just forget the fact that these funstions do not do a check on the > length of the input list for a moment. My question is, how can I generalize > this function to accept a list of lists of arbitrary length, and produce the > required result. > > I hope I managed to make my point clear enough. Waiting for suggestions. > > Regards, > > -- > Ozgur Akgun > > ___ > Haskell-Cafe mailing list > Haskell-Cafe@haskell.org > http://www.haskell.org/mailman/listinfo/haskell-cafe > > -- Eugene Kirpichov Web IR developer, market.yandex.ru ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] (possibly) a list comprehensions question
Hi Cafe! I am struggling with an interesting problem while defining a function. It looks quite easy to me, but I couldn't manage to have a proper implementation yet. To illustrate what I'm trying to achive, I'll introduce special cases of the desired function, and hopefully build towards a solution step by step. -- simplest case, taking 2 lists as parameters and returning a list of list containing every possible pair (but represented as lists) allPossibilities2 :: [a] -> [a] -> [[a]] allPossibilities2 listX listY = [ [x,y] | x <- listX, y <- listY] -- sample output -- allPossibilities2 [1,2,3] [7,8,9] -- [[1,7],[1,8],[1,9],[2,7],[2,8],[2,9],[3,7],[3,8],[3,9]] -- simplest case with 3 parameters instead of 2 allPossibilities3 :: [a] -> [a] -> [a] -> [[a]] allPossibilities3 listX listY listZ = [ [x,y,z] | x <- listX, y <- listY, z <- listZ] -- allPossibilities3 [1,2] [3,4,5] [6,7] -- [[1,3,6],[1,3,7],[1,4,6],[1,4,7],[1,5,6],[1,5,7],[2,3,6],[2,3,7],[2,4,6],[2,4,7],[2,5,6],[2,5,7]] These are easy and work just fine. All I want to do is to generalize this function receiving n lists as parameters and doing the simple action described above. Since I cannot pass variable number of parameters to a function, I'll use list of lists from now on. Following are the implementations of the same functions with different types (instead of two lists, a list of lists assumed to caontain those 2 elements) allPossibilities2' :: [[a]] -> [[a]] allPossibilities2' list = [ [x,y] | x <- list !! 0, y <- list !! 1] -- allPossibilities2' [[1,2,3],[7,8,9]] -- [[1,7],[1,8],[1,9],[2,7],[2,8],[2,9],[3,7],[3,8],[3,9]] allPossibilities3' :: [[a]] -> [[a]] allPossibilities3' list = [ [x,y,z] | x <- list !! 0, y <- list !! 1, z <- list !! 2] -- allPossibilities3' [[1,2],[3,4,5],[6,7]] -- [[1,3,6],[1,3,7],[1,4,6],[1,4,7],[1,5,6],[1,5,7],[2,3,6],[2,3,7],[2,4,6],[2,4,7],[2,5,6],[2,5,7]] This is ugly! Anyway, just forget the fact that these funstions do not do a check on the length of the input list for a moment. My question is, how can I generalize this function to accept a list of lists of arbitrary length, and produce the required result. I hope I managed to make my point clear enough. Waiting for suggestions. Regards, -- Ozgur Akgun ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typefuck: Brainfuck in the type system
On Thu, Nov 19, 2009 at 10:47 AM, Cristiano Paris wrote: > On Mon, Nov 16, 2009 at 6:26 PM, Gwern Branwen wrote: >> ... >> Too late: >> ... >> http://hackage.haskell.org/package/loli > > What's the point with loli? Mrs Lopsided has all the loli. D -- Dougal Stanton dou...@dougalstanton.net // http://www.dougalstanton.net ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
On 19/11/2009 11:52, Sittampalam, Ganesh wrote: Yitzchak Gale wrote: Simon Marlow wrote: So then what shall we call the a -> () version? One possibility is to go back to calling it rnf. In light of apfelmus' comment, I vote for rnf. And in that case, how about the analogous alternative for seq itself: hnf :: a -> () I think it would be whnf since it doesn't evaluate under lambdas. I also vote for rnf, because we should have a good reason for changing names of things. Various people would prefer rnf. Ok, unless there are any further objections, I'll change the names back to class NFData a where rnf :: a -> () and also add deepseq :: a -> b -> b but I'll leave the module name as Control.DeepSeq. Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Some help needed to start Haskell with Yi
On Thu, 19 Nov 2009, Daniel Fischer wrote: A separate package for that orphan instance would be the best solution. I'm not sure that's really better. With a separate package, you'd have dependencies packageY, orphanInstance. When a new version of packageY with the instance is uploaded, things break in the same way. The fix is easy either way, delete the dependency orphanInstance or delete the orphan instance, but with a separate package, that stays around polluting hackage - or is there now a way to remove packages from hackage swiftly? This interim package can be modified in a way such that it exports an empty module for the versions of the base package that define the instance themselve. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Re: ANNOUNCE: deepseq-1.0.0.0
On 18/11/2009 04:05, Malcolm Wallace wrote: The documentation claim that "The default implementation of 'deepseq' is simply 'seq'" is not exactly right, as `deepseq` and `seq` have different signatures. Yes indeed. In order to use deepseq, it looks like I also need some way to force the () return value, e.g. let res = deepseq (my big computation) in res `seq` use res or let res = deepseq (my big computation) in case res of () -> use res or let !res = deepseq (my big computation) in use res Cheers, Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Typefuck: Brainfuck in the type system
On Mon, Nov 16, 2009 at 6:26 PM, Gwern Branwen wrote: > ... > Too late: > ... > http://hackage.haskell.org/package/loli What's the point with loli? Cristiano ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Wiki software?
> From: haskell-cafe-boun...@haskell.org > [mailto:haskell-cafe-boun...@haskell.org] On Behalf Of S. > Doaitse Swierstra > > How about: > > http://hackage.haskell.org/package/orchid > > a simple, but nice wiki produced by one of our students Sebastiaan > Visser, You can see it in action here: http://funct.org/wiki/ http://funct.org/wiki/#Building%20a%20Wiki%20in%20Haskell.html Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
Excerpts from Twan van Laarhoven's message of Thu Nov 19 00:59:25 +0100 2009: > Levi Greenspan wrote: > > What's the status of the TDNR proposal [1]? Personally I think it is a > > very good idea and I'd like to see it in Haskell'/GHC rather sooner > > than later. Working around the limitations of the current record > > system is one of my biggest pain points in Haskell and TDNR would be a > > major improvement. Thus I wonder if someone is actively working on > > this proposal? > > The TDNR proposal really tries to do two separate things: > > 1. Record syntax for function application. > The proposal is to tread "x.f" or a variation thereof the same as "(f x)" It is more like "(ModuleToGuess.f x)" than "(f x)". -- Nicolas Pouillard http://nicolaspouillard.fr ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
| The proposal has this sentence, apparently in reference to using | qualified imports: "This is sufficient, but it is just sufficiently | inconvenient that people don't use it much." Does this mean qualified | imports? I clarified. | One thing I'd really like that this would provide is shorter record | selection. "b.color" is a lot nicer than "Button.btn_color b". Or | would it? It seems like under a TDNR scheme to be able to write | "b.color" I'd have to either import "color" explicitly or go over to | the unqualified import world. Good qn. I added a subsection "Qualified imports" to discuss. | I don't really want to do the latter, | but I also wouldn't want to maintain explicit import lists. Also, as | far as I can see this doesn't provide is nice record update syntax. | If I can write "b.color" I want to be able to write "b2 = b.color := | red"! Yes, well see "Record syntax". Might be doable. | I think this will also lead to either lots of name shadowing warnings | or more trouble picking variable names. The short perspicuous names | this allows are also the most convenient for local variables. I don't | want to suddenly not be able to use a 'color' variable name because | some record has a 'color' field. A record system (and OO languages) | would have no trouble with 'let color = b.color' but as far as I can | see TDNR would have a problem. Good point. I added a subsection "Top-level disambiguation only" | So as far as records, TDNR doesn't seem too satisfactory. I think these points are all addressable, more or less as OO languages do, as mentioned above. Thanks for the suggestions Simon ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Status of TypeDirectedNameResolution proposal?
2009/11/18 Twan van Laarhoven : > > The TDNR proposal really tries to do two separate things: > > 1. Record syntax for function application. > The proposal is to tread "x.f" or a variation thereof the same as "(f x)" > > 2. Type directed name lookup. > The proposal is to look up overloaded names based on the type of the > first function argument. > > Why can't these be considered separately? Is there a good reason for not > using TDNR in normal function applications? The only argument I can think of > (compared to the record syntax) is that it would be a bigger change. Hi Twan Using the T combinator renamed to (#) for "x.f" was idiomatic Haskell a decade ago, vis: 'Client-side Web Scripting with HaskellScript" Erik Meijer, Daan Leijen and James Hook (PADL 1999) 'Modelling HTML in Haskell' Peter Thiemann (PADL 2000) Quoting Erik Meijer et al.: To reflect the influence of the OO style, we will use the postfix function application object # method = method object to mimic the object.method notation. For your first point, I'd vote for adding (#) to Data.Function... Best wishes Stephen ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Cabal + gfortran?
Hi Gregory, The package hmatrix [1] checks for LAPACK and BLAS (and GSL) using a simple script [2] (but it does not compile fortran sources, only a few C helper functions). [1] http://hackage.haskell.org/cgi-bin/hackage-scripts/package/hmatrix [2] http://perception.inf.um.es/cgi-bin/darcsweb.cgi?r=hmatrix;a=headblob;f=/configure.hs Gregory Crosswhite wrote: Hi, I want to set up a build that compiles fortran sources in addition to the Haskell, and which maybe also eventually checks for the existence of a library or two (specifically, LAPACK and BLAS). Does anyone here have a suggestion for where I should be looking to figure out how to do this, such as a package which uses such a setup that would provide an example? Thanks, Greg ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
