[Haskell] ANNOUNCE: lens-family 1.0.0

[roconnor]

Before there was lens there was lens-family

I'm pleased to announce the second major release of 
the lens-family pacakges: lens-family-core-1.0.0 and lens-family-1.0.0.


They can be found at

* 
* 

I consider these packages to be kiddie-pool sized lens libraries for those 
people who are, for whatever reason, too intimidated by the lens library. 
I think this is a good way to get one's feet wet with lenses.  The type 
for lenses and traversals are completely compatible with the lens library.


This release brings two major developments to lens-family:

* Support for traversals and folds.

* The names have been all renamed to be mostly compatible with the lexicon 
developed by lens.


With a common lexicon, I hope that users will find it easy to transition 
from lens-family to lens when they outgrow the kiddie pool.


The lens-family-core package is a completely Haskell 98 package for those 
who need the compatibility. The lens-family package is a wrapper around 
lens-family-core that provides a few useful Rank 2 type synonyms to make 
using functional references a little easier.


P.S.  If edwardk is reading, I've used Ryan Ingram's definition from 
 
to implement alongside so that it works for both lenses and getters.  You 
probably want to do the same.


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] [Haskell-cafe] ANNOUNCE: lens-family-th 0.1.0.0

[roconnor]

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  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: lens-family 0.0.0

[roconnor]

I'm pleased to announce the first release of lens-family-core and 
lens-family.


This package provide first class(†) functional references. In addition to 
the usual operations of getting, setting and composition, plus integration 
with the state monad, lens families provide some unique features:


* Polymorphic updating
* Cast projection functions to read-only lenses
* Cast semantic editor combinators to modify-only lenses

(†) For optimal first-class support use the lens-family package with rank 
2 / rank N polymorphism. Lens.Family.Clone allows for first-class support 
of lenses for those who require Haskell 98.


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: partial-lens 0.0.1

[roconnor]

Do you miss null references from your old imperative programming days? 
Wish that the worlds best imperative language had null references?  Now 
your wishes have come true with the new partial-lens package!


partial-lens augment edwardk's data-lens package with partial lens. 
Partial lenses are like regular lenses but have the possibility of not 
referencing anything.  In other words, null references are possible.  One 
notable different with null references from this package is that you can 
set them without getting a run-time error.  Instead setting a null 
reference is a no-op; however it is possible to determine if setting 
failed from the return value of the assignment operation.


Actually I don't have any applications for partial lenses myself, so if 
you find this library useful, please let me know.  I wrote this mostly 
because we know what partial lenses are in theory (they are the coalgebras 
of the (Identity :+: Store b) comonad) but I wanted to see what a real 
library would look like.


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] An Alternative Data.List.Zipper

[roconnor]

On Sat, 17 Jan 2009, David Menendez wrote:


instance Applicative f => Applicative (Backwards f) where
   pure = B . pure
   f <*> x = B (unB f <**> unB x)


probably should be f <*> x = B (unB x <**> unB f)

anyhow, this should be part of Control.Applicative.


This may be terminological confusion. I would have said that a
PointedList *is* a zipper.


This is what I thought, and what how I initally advised Jeff.  However 
after carefully reading both 
 and 
 (Clowns to the left of me, 
jokers to the right), it is clear that formally a zipper focuses on a 
sub-list / sub-tree rather than focusing on a particular node of a list or 
a tree.  Hence zippers are not comonads.


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] ANNOUNCE: colour 0.0.0

[roconnor]

On Fri, 24 Oct 2008, Sebastian Sylvan wrote:


It would be nice if we could customize the gamma curve. Different devices have 
different gamma.
Some hardware even approximates the gamma curve with piecewise linear 
functions. This can make a
massive difference if you, e.g. degamma the image assuiming a gamma of 2.2 
(typical office LCD
screen), do some work on it, then convert to a gamma of 2.5 (typical TV - they 
assume TVs will be
in a darker background setting), then the graphics card reads this as sRGB with 
its own piecewise
linear approximation, then does some more work on it, and converts it back. 
Long story short, if
you can't get all of those steps right the errors can add up quickly and 
becomes very noticable.


That is a fair point.  I've only just started thinking about colour 
correction due to viewing environments.  I remembered that dealing with 
colour was difficult (which is why I'm writing this library), but I forgot 
exactly how difficult it was.


I just finished user defined linear RGB spaces in my development version. 
Allowing user defined non-linear RGB spaces would be a reasonable 
addition.



If it could read photoshop colour profiles that would be even better.


Perhaps ICC profiles would do?  Or are they the same thing?

--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] ANNOUNCE: colour 0.0.0

[roconnor]

http://hackage.haskell.org/cgi-bin/hackage-scripts/package/colour-0.0.0

I hope for this library to become the standard colour library for Haskell. 
Most software does not properly blend colours because they fail to 
gamma-correct the colours before blending.  Hopefully by using this 
library, Haskell programs dealing with colour blending will avoid this 
problem.


I am making an early release of my colour library to get some feedback. I 
am especially interested in getting feedback on the interfaces: should 
functions be renamed, should functions be moved, etc. Should I put black 
and white colours into Data.Colour?  Which is better form making a colour: 
(sRGB r g b) or (sRGB (r,g,b))?


Bug reports and any patches are also welcome.  Be warned, I haven't 
extensively tested this library yet.


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] Expecting more inlining for bit shifting

[roconnor]

Consider the following GHC code:

module Main where

import GHC.Word
import GHC.Base
import GHC.Prim
import Random

a `shiftRLT` b | b >=# 32# = int2Word# 0#
   | otherwise = a `uncheckedShiftRL#` b

(W32# x#) `shift` (I# i#)
| i# >=# 0#= W32# (narrow32Word# (x# `shiftL#` i#))
| otherwise= W32# (x# `shiftRLT` negateInt# i#)

x `shiftR`  i = x `shift`  (-i)

shift7 x = x `shiftR` 7
shift6 (W32# x) = (W32# (x `uncheckedShiftRL#` 6#))

main = do
  xs <- sequence (replicate 100
  (fmap (shift7 . fromIntegral) (randomIO::IO Int)))
  print (sum xs)

I have copied the definition of `shiftR` for Word32 into this file.

Suppose we want to shift a series of numbers by 7 bits.  One would expect 
GHC's inliner to notice that (-7) is indeed not greater than 0, and 
eliminate the branch in the definition of `shift`.  Further one would 
expect GHC to notice that 7 is indeed not gtreater than 32, and eliminate 
the branch in shiftRLT.  Thus one would expect the code generated by using 
shift7 to be identical to that being generated by shfit6 (with 7 replaced 
by 6).


But this appears not to be the case.  The code generated for shift7 (if I 
can read the C code correctly) is:

Sp[-1] = (-0x7U);
Sp[-2] = R1.p[1];
*Sp = (W_)&s2za_info;
Sp=Sp-2;
JMP_((W_)&Main_zdwshift_info);

while the code generated for shift6 is the lovely:

Hp=Hp+2;
if ((W_)Hp > (W_)HpLim) goto _c2Aa;
_s2xq = (R1.p[1]) >> 0x6U;
Hp[-1] = (W_)&GHCziWord_W32zh_con_info;
*Hp = _s2xq;
R1.p=Hp-1;
Sp=Sp+1;
JMP_(*Sp);
_c2Aa:
HpAlloc = 0x8U;
JMP_(stg_gc_enter_1);

My question is, why the discrepency?

--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] Performance, Optimization and Code Generation

[roconnor]

according to , GHC's 
rotate is implemented as


(W32# x#) `rotate` (I# i#)
| i'# ==# 0# = W32# x#
| otherwise  = W32# ((x# `shiftL32#` i'#) `or32#`
 (x# `shiftRL32#` (32# -# i'#)))
where
i'# = word2Int# (int2Word# i# `and#` int2Word# 31#)

So you can see that it takes i modulo 32 first (by anding it with 31). 
Perhaps one needs an uncheckedRotate32# function (if it doesn't exist).


Also, shouldn't the calls to shiftL32# and shiftRL32# be calls to 
uncheckedShiftL32# and uncheckedShiftR32# since i'# and (32# -# i'#) are 
provably safe?


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] semantice of seq

[roconnor]

On Wed, 19 Jul 2006, Duncan Coutts wrote:


Ah ok, I misunderstood. Well that'd be a bit odd too. No other function
behaves differently on different types except by use of type classes.


I agree it is quite odd, but the seq we have is already quite odd.


Furthermore, the fact is that seq on function types is actually useful
for controlling space and time behaviour, so it's not clear that we want
to ban it.


Do you have an example of use of seq on a function type?  (Of course I 
don't want to ban it, just change its behaviour.)


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

Re: [Haskell] semantice of seq

[roconnor]

On Tue, 18 Jul 2006, Duncan Coutts wrote:


On Tue, 2006-07-18 at 09:44 -0400, [EMAIL PROTECTED] wrote:

Would the problematic semantics of seq be resolved if seq did nothing on
function types?  That is to say

seq (\x -> undefined `asTypeOf` x) y reduced to y

and

seq (undefined `asTypeOf` id) y also reduced to y


I don't think so. You'd also have to avoid polymorphic types since they
can be used at function types. Basically you'd have to bring back the
Seq class. The rationale for removing the class and making seq
polymorphic is mentioned in the history of Haskell draft paper that was
recently advertised.


I don't understand.  At execution time, all the polymoric variables are 
gon, so we know the type of the parameter to seq.


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

[Haskell] semantice of seq

[roconnor]

Would the problematic semantics of seq be resolved if seq did nothing on 
function types?  That is to say


seq (\x -> undefined `asTypeOf` x) y reduced to y

and

seq (undefined `asTypeOf` id) y also reduced to y


--
Russell O'Connor  
``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 mailing list
Haskell@haskell.org
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[roconnor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

How about making default method for asin

asin x = atan(x/sqrt(1-x^2))

Can't be worse than the default for (**) ;-)

- -- 
Russell O'Connor[EMAIL PROTECTED]
   <http://www.math.berkeley.edu/~roconnor/>
``This is not a time, as it is never a time, to seek vengeance, but a
time to seek the courage to forgive'' -- George W. Bush
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE71gyFZG3em5NXM14RAsTUAKCfalnIJ/JsBDak0V7jhgesMGrg0ACg1mJr
3Yx6mHcAQ7nyy02UMTdG/L0=
=oJdQ
-END PGP SIGNATURE-


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell

RE: Haskell 98 - Standard Prelude - Floating Class

[roconnor]

-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1

On Mon, 15 Oct 2001, Lennart Augustsson wrote:

> Why not provide defaults for the inverse functions as well?
>
> asinh x = log (x + sqrt (1+x*x))
> acosh x = log (x + (x+1) * sqrt ((x-1)/(x+1)))
> atanh x = log ((x+1) / sqrt (1 - x*x))

That's a good idea too.
Is there a reason for defining acosh as above instead of

acosh x = log(x + sqrt(x*x-1))

- -- 
Russell O'Connor[EMAIL PROTECTED]
   <http://www.math.berkeley.edu/~roconnor/>
``This is not a time, as it is never a time, to seek vengeance, but a
time to seek the courage to forgive'' -- George W. Bush
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.0.6 (SunOS)
Comment: For info see http://www.gnupg.org

iD8DBQE7yv8aZG3em5NXM14RAqO2AJ4hsVYSbtFYgDmjturcQOr/AUbH0ACfTYKw
IZA2w18pSxdMAvZrLPoOJLM=
=+Pkw
-END PGP SIGNATURE-


___
Haskell mailing list
[EMAIL PROTECTED]
http://www.haskell.org/mailman/listinfo/haskell