Re: [Haskell-cafe] translation between two flavors of lexically-scoped type variables
Do you know why they switched over in GHC 6.6? If I were to speculate, I'd say it is related to GADTs. Before GADTs, we can keep conflating quantified type variables with schematic type variables. GADTs seem to force us to make the distinction. Consider this code: data G a where GI :: Int - G Int GB :: Bool - G Bool evG :: G a - a evG (GI x) = x evG (GB x) = x To type check the first clause of evG, we assume the equality (a ~ Int) for the duration of type checking the clause. To type-check the second clause, we assume the equality (a ~ Bool) for the clause. We sort of assumed that a is universally quantified, so we may indeed think that it could reasonably be an Int or a Bool. Now consider that evG above was actually a part of a larger function foo = ... where evG :: G a - a evG (GI x) = x evG (GB x) = x bar x = ... x :: Int ... x::a ... We were happily typechecking evG thinking that a is universally quantified when in fact it wasn't. And some later in the code it is revealed that a is actually an Int. Now, one of our assumptions, a ~ Bool (which we used to typecheck the second clause of evG) no longer makes sense. One can say that logically, from the point of view of _material implication_, this is not a big deal. If a is Int, the GB clause of evG can never be executed. So, there is no problem here. This argument is akin to saying that in the code let x = any garbage in 1 any garbage will never be evaluated, so we just let it to be garbage. People don't buy this argument. For the same reason, GHC refuses to type check the following evG1 :: G Int - Int evG1 (GI x) = x evG1 (GB x) = x Thus, modular type checking of GADTs requires us to differentiate between schematic variables (which are akin to `logical' variables, free at one time and bound some time later) and quantified variables, which GHC calls `rigid' variables, which can't become bound (within the scope of the quantifier). For simplicity, GHC just banned schematic variables. The same story is now played in OCaml, only banning of the old type variables was out of the question to avoid breaking a lot of code. GADTs forced the introduction of rigid variables, which are syntactically distinguished from the old, schematic type variables. We thus have two type variables: schematic 'a and rigid a (the latter unfortunately look exactly like type constants, but they are bound by the `type' keyword). There are interesting and sometimes confusing interactions between the two. OCaml 4 will be released any hour now. It is interesting to see how the interaction of the two type variables plays out in practice. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: Sifflet visual programming language, release 2.0.0.0
On Thu, 5 Jul 2012, gdwe...@iue.edu wrote: Sifflet and sifflet-lib 2.0.0.0, now available on Hackage! This version introduces a type checker and partial support for higher order functions in Sifflet, the visual, functional programming language and support system for students learning about recursion. You have implemented your own type-checker, right? I plan to add a type-checker to our live-sequencer project. [1] So far I have thought about using the Helium type checker but I have not done it so far. If you want to make your type-checker useful for other projects, you may put it into a separate package without the hard to install dependencies on cairo and glib. [1] http://www.youtube.com/watch?v=sXywCHR9WwE ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] ANNOUNCE: lens-family-th 0.1.0.0
On Fri, 6 Jul 2012, Dan Burton wrote:
Following the announcement of lens-family, I'm pleased to announce
lens-family-th 0.1.0.0, a Template Haskell library supplying macros to generate
lens-family lenses for fields of data types declared with record syntax.
Be warned that currently, type signatures are *not* generated alongside the
lens definitions. Type inference should correctly determine the type of the
generated lenses, but I have structured the library code so that in the future,
type signatures can also be generated. Patches welcome!
http://hackage.haskell.org/package/lens-family-th
I cannot help but wonder if it is better to *not* generate type signatures
(or at least have an option not to).
At the moment one can write:
import Lens.Family2.Stock
import Lens.Family2.TH
data Foo a = Foo { _bar :: Int, _baz :: a }
deriving (Show, Read, Eq, Ord)
$(mkLenses ''Foo)
-- | My documentation for the 'bar' lens.
bar :: Lens (Foo a) Int
-- | My documentation for the 'baz' lens.
baz :: LensFamily (Foo a) (Foo a') a a'
I don't know if it is possible to add haddock to functions whose type
signatures are generated by template haskell.
--
Russell O'Connor http://r6.ca/
``All talk about `theft,''' the general counsel of the American Graphophone
Company wrote, ``is the merest claptrap, for there exists no property in
ideas musical, literary or artistic, except as defined by statute.''
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: lens-family-th 0.1.0.0
On Sat, 7 Jul 2012, rocon...@theorem.ca wrote:
On Fri, 6 Jul 2012, Dan Burton wrote:
Following the announcement of lens-family, I'm pleased to announce
lens-family-th 0.1.0.0, a Template Haskell library supplying macros to
generate
lens-family lenses for fields of data types declared with record syntax.
Be warned that currently, type signatures are *not* generated alongside the
lens definitions. Type inference should correctly determine the type of the
generated lenses, but I have structured the library code so that in the
future, type signatures can also be generated. Patches welcome!
http://hackage.haskell.org/package/lens-family-th
I cannot help but wonder if it is better to *not* generate type signatures
(or at least have an option not to).
In data-accessor-template we generate type signatures, also because it
avoids warnings for missing type signatures. However it needed some
fine-tuning before it worked in all cases.
At the moment one can write:
import Lens.Family2.Stock
import Lens.Family2.TH
data Foo a = Foo { _bar :: Int, _baz :: a }
deriving (Show, Read, Eq, Ord)
$(mkLenses ''Foo)
-- | My documentation for the 'bar' lens.
bar :: Lens (Foo a) Int
-- | My documentation for the 'baz' lens.
baz :: LensFamily (Foo a) (Foo a') a a'
I don't know if it is possible to add haddock to functions whose type
signatures are generated by template haskell.
Could the documentation be an argument of mkLenses?
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Interest in typed relational algebra library?
Hello, I've been out of the Haskell game for a bit, but now I'm back. A couple of years ago I made a small library that implements relational algebra with types so that malformed queries and other operations are caught at compile time. It is heavily based off of the internals of HaskellDB (see http://hackage.haskell.org/packages/archive/haskelldb/2.1.1/doc/html/Database-HaskellDB-PrimQuery.html), but types so that it can actually be used directly instead of having to use HaskellDB's query monad. Besides the joy of using relational algebra directly in your code, this also means that you can make query-optimizing code in a type-safe way, you can subquery results returned by the database directly without accessing the database again and you have more options when converting from relation algebra to SQL or another query language. The library isn't quite ready for release, but I might want to work on it a bit and then release it. Is anyone interested in such a library? Paul Visschers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: lens-family-th 0.1.0.0
I don't know if it is possible to add haddock to functions whose type signatures are generated by template haskell. Could the documentation be an argument of mkLenses? Does haddock run on the template-haskell expanded code? -- Russell O'Connor http://r6.ca/ ``All talk about `theft,''' the general counsel of the American Graphophone Company wrote, ``is the merest claptrap, for there exists no property in ideas musical, literary or artistic, except as defined by statute.'' ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: lens-family-th 0.1.0.0
I don't know if it is possible to add haddock to functions whose type signatures are generated by template haskell. Could the documentation be an argument of mkLenses? Does haddock run on the template-haskell expanded code? TH macros must have type Q [Dec]. Dec has no constructor for comments, with the exception of pragmas. This might be feature request worthy, though it is a rather strange case to want to generate comments via a macro. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] [Haskell] ANNOUNCE: lens-family-th 0.1.0.0
On Sat, 7 Jul 2012, Dan Burton wrote: Could the documentation be an argument of mkLenses? Does haddock run on the template-haskell expanded code? TH macros must have type Q [Dec]. Dec has no constructor for comments, with the exception of pragmas. This might be feature request worthy, though it is a rather strange case to want to generate comments via a macro. Alternatively, Haddock allows you to document functions in the export list. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interest in typed relational algebra library?
Paul Visschers m...@paulvisschers.net wrote: I've been out of the Haskell game for a bit, but now I'm back. A couple of years ago I made a small library that implements relational algebra with types so that malformed queries and other operations are caught at compile time. It is heavily based off of the internals of HaskellDB (see http://hackage.haskell.org/packages/archive/haskelldb/2.1.1/doc/html/Database-HaskellDB-PrimQuery.html), but types so that it can actually be used directly instead of having to use HaskellDB's query monad. Besides the joy of using relational algebra directly in your code, this also means that you can make query-optimizing code in a type-safe way, you can subquery results returned by the database directly without accessing the database again and you have more options when converting from relation algebra to SQL or another query language. The library isn't quite ready for release, but I might want to work on it a bit and then release it. Is anyone interested in such a library? As someone who enjoyed the HaskellDB library I'm very interested in such a library, even though nowadays I mostly use acid-state. Greets, Ertugrul -- Not to be or to be and (not to be or to be and (not to be or to be and (not to be or to be and ... that is the list monad. signature.asc Description: PGP signature ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interest in typed relational algebra library?
I'd be interested in at least playing with it. On Saturday, July 7, 2012, Paul Visschers wrote: Hello, I've been out of the Haskell game for a bit, but now I'm back. A couple of years ago I made a small library that implements relational algebra with types so that malformed queries and other operations are caught at compile time. It is heavily based off of the internals of HaskellDB (see http://hackage.haskell.org/packages/archive/haskelldb/2.1.1/doc/html/Database-HaskellDB-PrimQuery.html), but types so that it can actually be used directly instead of having to use HaskellDB's query monad. Besides the joy of using relational algebra directly in your code, this also means that you can make query-optimizing code in a type-safe way, you can subquery results returned by the database directly without accessing the database again and you have more options when converting from relation algebra to SQL or another query language. The library isn't quite ready for release, but I might want to work on it a bit and then release it. Is anyone interested in such a library? Paul Visschers ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Odd HDBC connection bug
I found the solution to this problem: for both libraries, I had to wrap
calls in 'withRTSSignalsBlocked' from HDBC-mysql.
On 16 June 2012 00:32, William Shackleton w.shackle...@gmail.com wrote:
Hi
I'm having issues with HDBC when connecting to a remote MySQL server -
certain queries cause the DB connection to be lost. The following program
demonstrates this:
import Database.HDBC
import Database.HDBC.ODBC
main = do
conn - connectODBC DSN=owlro
putStrLn Connected
quickQuery' conn SELECT time, power FROM Power LIMIT 100; []
putStrLn Finished query 1
quickQuery' conn SELECT time, power FROM Power ORDER BY time; []
putStrLn Finished query 2
disconnect conn
The DSN points to a remote 32-bit Ubuntu 12.04 Server. The connection and
queries work using mysql and isql on the command line, and the table in
question contains about 1.3 million rows and only the columns id, time,
power.
When I compile and run this on a 64-bit Ubuntu 12.04 PC using HDBC-2.3.1.1
and HDBC-odbc-2.3.1.0 using GHC, I get the following (unwanted) output:
$ ghc Test.hs
$ ./Test
Connected
Finished query 1
Test: SqlError {seState = [\08S01\], seNativeError = -1, seErrorMsg =
execute execute: [\2013: [MySQL][ODBC 5.1
Driver][mysqld-5.5.24-0ubuntu0.12.04.1]Lost connection to MySQL server
during query\]}
This program finishes (and fails) in less than half a second.
When I run it using runhaskell however, the slow second query completes:
$ runhaskell Test.hs
Connected
Finished query 1
Finished query 2
I get the same result from ghci; this method takes about 10 seconds as
expected.
Basically, simple (short) queries complete, yet long ones crash the
connection. I also noticed similar results with HDBC-mysql.
Any ideas on what is causing this?
Thanks,
Will Shackleton
digitalsquid.co.uk
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] sample terms and interpreting program output from Tc Monad
Hi All: I'm still working through the following paper [1] and I wondered whether you could help me confirm my understanding of some sample terms and program output from the Tc Monad. For those interested, the language is specified in Parser.lhs available in the protoype here [2]. I understand these to be Rank 0 terms: (\(x::Int) . x) (0 :: Int) :: (forall. Int) -- value (\(x::Int). x) :: (forall. Int - Int) (\(x::a). x) :: (forall. a - a) Although the program prints forall, the absence of a type variable indicates Rank 0, correct? I understand these to be Rank 1 terms: (\x. x) :: (forall a. a - a) -- This is not the same as the third example above, right? This one identifies the type variable a, the one above does not. Also, there's no explicit annotation, it's inferred. (\x. \y. x) :: (forall a b. b - a - b) -- Still rank 1. Although there's no explicit annotation, the program infers the type variables and prints the forall and the appropriate type variables for the Rank 1 polytypes. I understand these to be Rank 2 terms: (\(x::(forall a. a)). 0) :: (forall. (forall a. a) - Int) The explicit forall annotation on the bound and binding variable x causes the program to infer a Rank 2 polytype as indicated by the - Int following the (forall a. a), while noting the absence of a type variable following the left-most forall printed by the program, correct? (\(x::(forall a. a - a)). x) :: (forall b. (forall a. a - a) - b - b) Also Rank 2, only one arrow to the right of (forall a. a - a) counts. The universal quantifier on type variable b ranges over the type variable a, correct? I understand this to be a Rank 3 term: (\(f::(forall a. a - a)). \(x::(forall b. b)). f (f x)) :: (forall c. (forall a. a - a) - (forall b. b) - c) The arrows to the right of the universally quantified a and b expressions qualify this as Rank 3. Type variable c ranges over type variables a and b, correct? Thanks for your help in better understanding this information. I'm home schooling myself on Haskell and community support is a big help. 1. Practical Type Inference for Arbitrary-Rank Types. 2.http://research.microsoft.com/en-us/um/people/simonpj/papers/higher-rank/ -- Rick ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] vector-simd: some code available, and some questions
All,
After my message of yesterday [1] I got down to it and implemented
something along those lines. I created a playground repository
containing the code at [2]. Initial benchmark results at [3]. More about
the benchmark at the end of this email.
First some questions and requests for help:
- I'm stuck with a typing issue related to 'sizeOf' calculation at [4].
I tried a couple of things, but wasn't able to figure out how to fix it.
- I'm using unsafePerformIO at [5], yet I'm not certain it's OK to do
so. Are there better (safer/performant/...) ways to get this working?
- Currently Alignment phantom types (e.g. A8 and A16) are not related to
each other: a function (like Data.Vector.SIMD.Algorithms.unsafeXorSSE42)
can have this signature:
unsafeXorSSE42 :: Storable a = SV.Vector SV.A16 a - SV.Vector SV.A16 a
- SV.Vector SV.A16 a
Yet, imaging I'd have an SV.Vector SV.A32 Word8 vector at hand, the
function should accept it as well (a 32-byte aligned vector is also
16-byte aligned). Is there any way to encode this at the type level?
That's about it :-)
As of now, I only implemented a couple of the vector API functions (the
ones required to execute my benchmark). Adding the others should be
trivial.
The benchmark works with Data.Vector.{Unboxed|Storable}.Vector (UV and
SV) vectors of Word8 values, as well as my custom
Data.Vector.SIMD.Vector type (MV) using 16-byte alignment (MV.Vector
MV.A16 Word8).
benchUV, benchSV and benchMV all take 2 pre-calculated Word8 vectors of
given size (1024 and 4096) and xor them pairwise into the result using
zipWith xor. benchMVA takes 2 suitable MV vectors and xor's them into
a third using a rather simple and unoptimized C implementation using
SSE4.2 intrinsics [6]. This could be enhanced quite a bit (I guess using
the prim calling convention, FFI overhead can be reduced as well).
Currently, only vectors of a multiple of 32 bytes are supported (mostly
because of laziness on my part).
As you can see, the zipWith Data.Vector.SIMD implementation is slightly
slower than the Data.Vector.Storable based one. I didn't perform much
profiling yet, but I suspect allocation and ForeignPtr creation is to
blame, this seems to be highly optimized in
GHC.ForeignPtr.mallocPlainForeignPtrBytes as used by
Data.Vector.Storable.
Thanks for any input,
Nicolas
[1] http://www.haskell.org/pipermail/haskell-cafe/2012-July/102167.html
[2] https://github.com/NicolasT/vector-simd/
[3] http://linode2.nicolast.be/files/vector-simd-xor1.html
[4]
https://github.com/NicolasT/vector-simd/blob/master/src/Data/Vector/SIMD/Algorithms.hs#L46
[5]
https://github.com/NicolasT/vector-simd/blob/master/src/Data/Vector/SIMD/Algorithms.hs#L43
[6]
https://github.com/NicolasT/vector-simd/blob/master/cbits/vector-simd.c#L47
___
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Interest in typed relational algebra library?
On Sat, 7 Jul 2012, Paul Visschers m...@paulvisschers.net wrote: Hello, I've been out of the Haskell game for a bit, but now I'm back. A couple of years ago I made a small library that implements relational algebra with types so that malformed queries and other operations are caught at compile time. It is heavily based off of the internals of HaskellDB (see http://hackage.haskell.org/packages/archive/haskelldb/2.1.1/doc/html/Database-HaskellDB-PrimQuery.html), but types so that it can actually be used directly instead of having to use HaskellDB's query monad. Besides the joy of using relational algebra directly in your code, this also means that you can make query-optimizing code in a type-safe way, you can subquery results returned by the database directly without accessing the database again and you have more options when converting from relation algebra to SQL or another query language. The library isn't quite ready for release, but I might want to work on it a bit and then release it. Is anyone interested in such a library? Paul Visschers Yes! And yes to first order predicate calculus too! oo--JS. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-simd: some code available, and some questions
On Sat, Jul 7, 2012 at 9:13 PM, Nicolas Trangez nico...@incubaid.com wrote: - Currently Alignment phantom types (e.g. A8 and A16) are not related to each other: a function (like Data.Vector.SIMD.Algorithms.unsafeXorSSE42) can have this signature: unsafeXorSSE42 :: Storable a = SV.Vector SV.A16 a - SV.Vector SV.A16 a - SV.Vector SV.A16 a Yet, imaging I'd have an SV.Vector SV.A32 Word8 vector at hand, the function should accept it as well (a 32-byte aligned vector is also 16-byte aligned). Is there any way to encode this at the type level? If the set of alignments you care about is finite, you could do: class AlignedToAtLeast n a instance AlignedToAtLeast A1 A1 instance AlignedToAtLeast A4 A1 instance AlignedToAtLeast A4 A4 instance AlignedToAtLeast A8 A1 instance AlignedToAtLeast A8 A4 instance AlignedToAtLeast A8 A8 instance AlignedToAtLeast A16 A1 instance AlignedToAtLeast A16 A4 instance AlignedToAtLeast A16 A8 instance AlignedToAtLeast A16 A16 instance AlignedToAtLeast A32 A1 instance AlignedToAtLeast A32 A4 instance AlignedToAtLeast A32 A8 instance AlignedToAtLeast A32 A16 instance AlignedToAtLeast A32 A32 in which as you can see the numbers of instances grows super-linearly with the number of alignments, but if there's only a handful it's not that bad. Then: unsafeXorSSE42 :: (Storable a, AlignedToAtLeast A16 align) = SV.Vector align a - SV.Vector align a - SV.Vector align a A problem with the above is that third parties can add more instances, breaking the safety. If this is a concern you could do: class AlignedToAtLeastImpl n a -- do not export this class! ...same instances as above... class AlignedToAtLeastImpl n a = AlignedToAtLeast n a -- export this class instance AlignedToAtLeastImpl n a = AlignedToAtLeast n a The drawback is that it requires UndecidableInstances, and (what bothers me more) the list of instances won't be present in the haddocks. So instead of the single instance above you could write all of them again manually for the exported class, which has the drawback that you have to write all of them again manually, but not the other two. An alternative solution is to encode all of the alignments in unary, which is more general; if they're all going to be a power of two you can store just the logarithm: data One data Twice n -- not practical to call it Double :) class AlignedToAtLeast n a instance AlignedToAtLeast One One instance AlignedToAtLeast One (Twice a) instance AlignedToAtLeast n a = AlignedToAtLeast (Twice n) (Twice a) type A1 = One type A4 = Twice (Twice A1) type A8 = Twice A4 type A16 = Twice A8 type A32 = Twice A16 and you can apply the same private class thing from above if you want. -- Your ship was caught in a monadic eruption. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-simd: some code available, and some questions
On Sat, Jul 7, 2012 at 9:59 PM, Gábor Lehel illiss...@gmail.com wrote: class AlignedToAtLeast n a instance AlignedToAtLeast A1 A1 instance AlignedToAtLeast A4 A1 instance AlignedToAtLeast A4 A4 instance AlignedToAtLeast A8 A1 instance AlignedToAtLeast A8 A4 instance AlignedToAtLeast A8 A8 instance AlignedToAtLeast A16 A1 instance AlignedToAtLeast A16 A4 instance AlignedToAtLeast A16 A8 instance AlignedToAtLeast A16 A16 instance AlignedToAtLeast A32 A1 instance AlignedToAtLeast A32 A4 instance AlignedToAtLeast A32 A8 instance AlignedToAtLeast A32 A16 instance AlignedToAtLeast A32 A32 Oh dang it. Sorry. All of these should be the other way around. Proofreading doesn't help if it's your brain that's fried. -- Your ship was caught in a monadic eruption. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-simd: some code available, and some questions
On Sat, 2012-07-07 at 21:59 +0200, Gábor Lehel wrote: An alternative solution is to encode all of the alignments in unary, which is more general; if they're all going to be a power of two you can store just the logarithm: data One data Twice n -- not practical to call it Double :) class AlignedToAtLeast n a instance AlignedToAtLeast One One instance AlignedToAtLeast One (Twice a) instance AlignedToAtLeast n a = AlignedToAtLeast (Twice n) (Twice a) type A1 = One type A4 = Twice (Twice A1) type A8 = Twice A4 type A16 = Twice A8 type A32 = Twice A16 and you can apply the same private class thing from above if you want. Very ingenious, thanks! I pushed this into [1], although export lists of all modules most likely will need some love once things get into shape. This also allows functions to become more general: unsafeXorSSE42 :: (Storable a, SV.AlignedToAtLeast SV.A16 o1, SV.Alignment o1, SV.AlignedToAtLeast SV.A16 o2, SV.Alignment o2, SV.AlignedToAtLeast SV.A16 o3, SV.Alignment o3) = SV.Vector o1 a - SV.Vector o2 a - SV.Vector o3 a I wonder whether GHC's upcoming type-level numerals could be useful in this situation as well. Nicolas [1] https://github.com/NicolasT/vector-simd/commit/a4f13745eb24d87a3628af13109f3e1d8232c925 ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-simd: some code available, and some questions
On Sun, Jul 8, 2012 at 12:21 AM, Nicolas Trangez nico...@incubaid.com wrote: On Sat, 2012-07-07 at 21:59 +0200, Gábor Lehel wrote: An alternative solution is to encode all of the alignments in unary, which is more general; if they're all going to be a power of two you can store just the logarithm: data One data Twice n -- not practical to call it Double :) class AlignedToAtLeast n a instance AlignedToAtLeast One One instance AlignedToAtLeast One (Twice a) instance AlignedToAtLeast n a = AlignedToAtLeast (Twice n) (Twice a) type A1 = One type A4 = Twice (Twice A1) type A8 = Twice A4 type A16 = Twice A8 type A32 = Twice A16 and you can apply the same private class thing from above if you want. Very ingenious, thanks! I pushed this into [1], although export lists of all modules most likely will need some love once things get into shape. This also allows functions to become more general: unsafeXorSSE42 :: (Storable a, SV.AlignedToAtLeast SV.A16 o1, SV.Alignment o1, SV.AlignedToAtLeast SV.A16 o2, SV.Alignment o2, SV.AlignedToAtLeast SV.A16 o3, SV.Alignment o3) = SV.Vector o1 a - SV.Vector o2 a - SV.Vector o3 a I wonder if you could get that a bit shorter... I suppose you could write: instance (AlignedToAtLeast n a, AlignedToAtLeast n b) = AlignedToAtLeast n (a, b) instance (AlignedToAtLeast n a, AlignedToAtLeast n b, AlignedToAtLeast n c) = AlignedToAtLeast n (a, b, c) ...and so on... though it feels a little strange semantically (relating a tuple to a scalar), but I don't see what harm can come of it. And then you can just write SV.AlignedToAtLeast SV.A16 (o1, o2, o3) in signatures. You can also make (Alignment n, Alignment a) a superclass constraint of AlignedToAtLeast, and write instances for Alignment inductively on One and Twice, and then you don't have to write Alignment o1 etc. separately either. So the signature would be just: unsafeXorSSE42 :: (Storable a, SV.AlignedToAtLeast SV.A16 (o1, o2, o3)) = SV.Vector o1 a - SV.Vector o2 a - SV.Vector o3 a which is friendlier. I wonder whether GHC's upcoming type-level numerals could be useful in this situation as well. I'd guess that this is what they're made for, but I haven't tried them. ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] vector-simd: some code available, and some questions
On Sat, 2012-07-07 at 21:13 +0200, Nicolas Trangez wrote: As you can see, the zipWith Data.Vector.SIMD implementation is slightly slower than the Data.Vector.Storable based one. I didn't perform much profiling yet, but I suspect allocation and ForeignPtr creation is to blame, this seems to be highly optimized in GHC.ForeignPtr.mallocPlainForeignPtrBytes as used by Data.Vector.Storable. I got the MV benchmark on-par with SV by reworking the allocation mechanism: no more FFI involved, but based on GHC.Exts.newAlignedPinnedByteArray# and some other trickery, see [1]. This could still be improved a little by using PlainPtr, but this is not exported by GHC.ForeignPtr. This did have a pretty big performance-impact on the SIMD-based benchmark, compare [2] to the old one [3]. I have no clue why the 4096 case now only uses twice the time of the 1024 one, unlike the expected 4x (+- as before). Nicolas [1] https://github.com/NicolasT/vector-simd/commit/5ec539167254435ef4e7d308706dcafae09504d2 [2] http://linode2.nicolast.be/files/vector-simd-xor2.html [3] http://linode2.nicolast.be/files/vector-simd-xor1.html ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] combining predicates, noob question
Ok , thanks for the answers, I understand now what liftM2 does. In this case would it be silly to use combinerPred (and maybe a newType Predicate a = a - Bool) for the sake of readability or shoud I stick with a - Bool and liftM2? thanks, Sebastián 2012/7/6 Brent Yorgey byor...@seas.upenn.edu On Fri, Jul 06, 2012 at 03:17:54PM -0300, Felipe Almeida Lessa wrote: On Fri, Jul 6, 2012 at 2:11 PM, Sebastián Krynski skryn...@gmail.com wrote: As I was using predicates (a - bool) , it appeared the need for combining them with a boolean operator (bool - bool - bool) in order to get a new predicate combining the previous two. So I wrote my function combinerPred (see code below). While I think this is JUST ok, i'm feeling a monad in the air. So.. where is the monad? combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = \x - op (pred1 x) (pred2 x) That's the `(-) a` monad: import Control.Applicative combinerPred :: (a - Bool) - (a - Bool) - (Bool - Bool - Bool) - (a - Bool) combinerPred pred1 pred2 op = op $ pred1 * pred2 By the way, I find it more natural to make 'op' the first argument, because it is more useful to partially apply combinerPred to an operation that it is to some predicates. Also, in that case combinerPred is simply liftA2: import Control.Applicative combinerPred :: (Bool - Bool - Bool) - (a - Bool) - (a - Bool) - (a - Bool) combinerPred = liftA2 -Brent ___ 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] vector-simd: some code available, and some questions
On Sun, 2012-07-08 at 01:40 +0200, Gábor Lehel wrote: unsafeXorSSE42 :: (Storable a, SV.AlignedToAtLeast SV.A16 o1, SV.Alignment o1, SV.AlignedToAtLeast SV.A16 o2, SV.Alignment o2, SV.AlignedToAtLeast SV.A16 o3, SV.Alignment o3) = SV.Vector o1 a - SV.Vector o2 a - SV.Vector o3 a I wonder if you could get that a bit shorter... I suppose you could write: instance (AlignedToAtLeast n a, AlignedToAtLeast n b) = AlignedToAtLeast n (a, b) instance (AlignedToAtLeast n a, AlignedToAtLeast n b, AlignedToAtLeast n c) = AlignedToAtLeast n (a, b, c) ...and so on... Once again, nifty! And implemented in [1]. though it feels a little strange semantically (relating a tuple to a scalar), but I don't see what harm can come of it. And then you can just write SV.AlignedToAtLeast SV.A16 (o1, o2, o3) in signatures. You can also make (Alignment n, Alignment a) a superclass constraint of AlignedToAtLeast, and write instances for Alignment inductively on One and Twice, and then you don't have to write Alignment o1 etc. separately either. So the signature would be just: unsafeXorSSE42 :: (Storable a, SV.AlignedToAtLeast SV.A16 (o1, o2, o3)) = SV.Vector o1 a - SV.Vector o2 a - SV.Vector o3 a which is friendlier. I implemented the inductive alignment calculation over One and Twice (good idea, and easy to do), but I don't get the thing about superclasses. I've been trying several approaches (including definitions based on forall and other trickery I never used before), but didn't get things to work, at least: the compiler always said I'd need UndecidableInstances, and that sounds scary... Care to elaborate? Thanks! Nicolas [1] https://github.com/NicolasT/vector-simd/commit/aedf25460b410e04a3d103befea59ebcb3903fdc ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
[Haskell-cafe] Best way to build a GHC backend?
Venerable Haskell Hackers, I love Haskell and think it should run everywhere. Now supposing I would like to build another backend for GHC, perhaps for Java Bytecode, .Net CIL, or JavaScript, What would be the best way to approach that? I can think of a few options: 1. Produce External Core with -fext-core and compile that with a completely separate compiler 2. Use the GHC apis to build a compiler that reuses a load of GHC's code, but has it's own backend 3. Add a new backend directly into GHC Any other options? While I'm on the subject, why has Haskell not been ported to the likes of the JVM, .NET CLR, or JavaScript? Are Haskell's non-strict semantics just too different from the semantics of these other platforms? SPJ is known for saying that Haskell's plan for world domination is support for many parallelism/concurrency idioms. I believe running on many platforms is just as important. From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course). Thoughts? --J Arthur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] Best way to build a GHC backend?
As to your porting of Haskell to the JVM question; the JVM would be unable to perform all the optimizations that GHC can do. There is really not much point in running slow code. JavaScript is interesting since the JIT compiler gets better all the time. On Sat, Jul 7, 2012 at 10:02 PM, Jonathan Geddes geddes.jonat...@gmail.comwrote: Venerable Haskell Hackers, I love Haskell and think it should run everywhere. Now supposing I would like to build another backend for GHC, perhaps for Java Bytecode, .Net CIL, or JavaScript, What would be the best way to approach that? I can think of a few options: 1. Produce External Core with -fext-core and compile that with a completely separate compiler 2. Use the GHC apis to build a compiler that reuses a load of GHC's code, but has it's own backend 3. Add a new backend directly into GHC Any other options? While I'm on the subject, why has Haskell not been ported to the likes of the JVM, .NET CLR, or JavaScript? Are Haskell's non-strict semantics just too different from the semantics of these other platforms? SPJ is known for saying that Haskell's plan for world domination is support for many parallelism/concurrency idioms. I believe running on many platforms is just as important. From my point of view, languages that cannot run on one of the 3 aforementioned platforms will become irrelevant. (with the exception of C, of course). Thoughts? --J Arthur ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe -- -- Regards, KC ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
