Bay Area Haskell Group Meeting on Thursday 18 October at Google's San Francisco office.

[Satnam Singh]

Hello,

I am hosting the next Bay Area Haskell meeting at Google's San Francisco office. Details here: https://sites.google.com/site/bayareahaskell/

Please let me know if you can come! We've laid on some food for the start of the meeting.

Cheers,

Satnam

[Zaki Manian]

I'm planning to attend.

--
You received this message because you are subscribed to the Google Groups "Bay Area Haskell Users Group" group.
To post to this group, send email to baha...@googlegroups.com.
To unsubscribe from this group, send email to bahaskell+...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Johan Tibell]

I'll be there!

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

[Andrii Tsymbala]

+1 for me

Thanks,
Andrii

[Shachaf Ben-Kiki]

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

I'll be there.

Shachaf

[Drew Haven]

I should make it.

--

[Sean Corfield]

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

Please let me know if you can come! We've laid on some food for the start of the meeting.

I'm planning to attend. It'll actually be my first BAHaskell meetup (and my Haskell is very, very rusty, not having used it for years!).

--
Sean A Corfield -- (904) 302-SEAN
An Architect's View -- http://corfield.org/
World Singles, LLC. -- http://worldsingles.com/

"Perfection is the enemy of the good."
-- Gustave Flaubert, French realist novelist (1821-1880)

[Jonathan Fischoff]

+1 for me!

[Antoine Tollenaere]

I'm planning to attend.

--
tel : +1 510-666-7591

[Aaron Culich]

+1 for me.

[Bryce Verdier]

+1 for me! (Maybe +2... I'll know more later)

Bryce

[al...@nodename.com]

Me too!
Hope I can follow the discussion :)

-A

[Benedict Gaster]

I'm hoping to attend.

Regards,

Ben

On Thu, Oct 11, 2012 at 9:40 AM, <al...@nodename.com> wrote:

Me too!
Hope I can follow the discussion :)

-A

Quoting Satnam Singh <s.s...@acm.org>:

Hello,

I am hosting the next Bay Area Haskell meeting at Google's San Francisco
office. Details here: https://sites.google.com/site/bayareahaskell/

Please let me know if you can come! We've laid on some food for the start
of the meeting.

Cheers,

Satnam

--
You received this message because you are subscribed to the Google Groups "Bay Area Haskell Users Group" group.
To post to this group, send email to baha...@googlegroups.com.

To unsubscribe from this group, send email to bahaskell+unsubscribe@googlegroups.com.

For more options, visit https://groups.google.com/groups/opt_out.

--
You received this message because you are subscribed to the Google Groups "Bay Area Haskell Users Group" group.
To post to this group, send email to baha...@googlegroups.com.

To unsubscribe from this group, send email to bahaskell+unsubscribe@googlegroups.com.

[Vlad Patryshev]

Me2.

Thanks,
-Vlad

To unsubscribe from this group, send email to bahaskell+...@googlegroups.com.

[Bob Ippolito]

I plan to attend

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

--

[Adrian Prantl]

I'm planning to attend!

-- 

Adrian

--

[Erdal Tuleu]

+1

[Dan Piponi]

I'll be there.
--
Dan

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

[Daniel]

+2

Thanks,
Daniel

[Steve Severance]

I will be there.

---------------------------------------------

Steve Severance

Alpha Heavy Industries

sseve...@alphaheavy.com

(240) 472 - 9645

---------------------------------------------

[Eugene Kirpichov]

I'll be driving from San Diego in the morning, but I hope to make it...

Eugene Kirpichov
http://www.linkedin.com/in/eugenekirpichov
We're hiring! http://tinyurl.com/mirantis-openstack-engineer

[Luite Stegeman]

I'm really interested in both practice and theory of optics and wave
mechanics, so I'll be coming over from Europe for Edward's lecture on
lenses and transversals.

Luite

[Arthur Chan]

hey Satnam

I will be there. looking forward to meeting you in person!

Arthur :: LittleBrick

--

[Dan Krol]

I plan to be there.

[Satnam Singh]

Please can you give me the full names of the +2 and optionally the affiliations?

Thank you kindly.

Satnam

Satnam Singh

Email: sat...@raintown.org

URL: http://cs.bham.ac.uk/~singhsu

Cell (USA): +1 408 656 4590
Mobile (UK): +44 7979 648412

[Satnam Singh]

Likewise!

S

[Conal Elliott]

I plan to attend. Hoping for a carpool from the south bay with a non-smoker. -- Conal

[Oliver Charles]

I'll be there, can't wait!

[Benedict Gaster]

Hi Conal,

I'm coming up from Santa Cruz/Sunnyvale if you fancy meeting on the way to carpool?

Regards,

Ben

Sent from my iPhone

[Paul Higham]

Thanx x 10**6 for hosting this.  I'm planning to be there and coming from Cupertino if anybody would like a ride.  BTW, for those of you who were on that little adventure the last time I gave anybody a ride, the van is back to new and ready for passengers!

::paul

[Joel Burget]

I'll be there as well, thanks for hosting!

[John Alfred Nathanael Chee]

I'm also planning to come.

> --
> You received this message because you are subscribed to the Google Groups
> "Bay Area Haskell Users Group" group.
> To post to this group, send email to baha...@googlegroups.com.
> To unsubscribe from this group, send email to
> bahaskell+...@googlegroups.com.

> To view this discussion on the web visit
> https://groups.google.com/d/msg/bahaskell/-/2w0sHAEM9HYJ.

>
> For more options, visit https://groups.google.com/groups/opt_out.
>
>

--
Love in Jesus Christ, John Alfred Nathanael Chee
http://www.biblegateway.com/
http://web.cecs.pdx.edu/~chee/

[Satnam Singh]

You're very welcome!

Satnam

[Michael Katelman]

If it's still possible, I'd also like to come!

Thanks for hosting!

[Archontophoenix Quar]

I'll be there. I also replied yes on the meetup.com page, in case
anyone is making a master total.

A

[Rohit Sinha]

I am planning to attend as well. Thanks for hosting, Satnam!

[Dave Fayram]

I am definitely attending. I hope I won't be a fire hazard.

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:
> Hello,
>
> I am hosting the next Bay Area Haskell meeting at Google's San Francisco
> office. Details here: https://sites.google.com/site/bayareahaskell/
>
> Please let me know if you can come! We've laid on some food for the start of
> the meeting.
>
> Cheers,
>
> Satnam
>
> --
> You received this message because you are subscribed to the Google Groups
> "Bay Area Haskell Users Group" group.
> To post to this group, send email to baha...@googlegroups.com.
> To unsubscribe from this group, send email to
> bahaskell+...@googlegroups.com.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>



--

--
Dave Fayram
dfa...@gmail.com

[Joshua Ball]

I'm planning to come.

Borrow my books: http://goo.gl/UBbSH

[Vlad Patryshev]

carpool, anybody?

408 7688721

I'm in MV, Castro x El Camino

[Eugene Kirpichov]

I'd like to carpool. I'll call you on Thu.

15.10.2012, в 16:02, Vlad Patryshev <vpatr...@gmail.com> написал(а):

carpool, anybody?

408 7688721

I'm in MV, Castro x El Camino

--

[Paul Liu]

I plan to attend. -- Paul Liu (Intel)

[Abram]

I would like to attend too.

[Ira Joseph Woodhead]

I am so there. (Shazam)

[Shachaf Ben-Kiki]

I'm going to be leaving Stanford at ~17:05-17:15. I was going to take
the train but it looks like a lot of people are interested in
carpooling, so I might either drive and pick people up along the way,
if there is anyone, or join someone else if they'll be passing through
Palo Alto. Ping me if one of these applies to you!

Shachaf

[Bob Ippolito]

If you're driving, be warned that there's a 49ers game at Candlestick Park on Thursday at 5:30, so 101 is probably going to be really slow. Taking 280 into the city is probably the way to go.

http://www.49ers.com/gameday/season-schedule.html

-bob

[Conal Elliott]

Thanks for the detail, Satnam. I think I'm getting a ride with Ben Gaster. Looking forward to the gathering. -- Conal

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

Hello,

I am hosting the next Bay Area Haskell meeting at Google's San Francisco office. Details here: https://sites.google.com/site/bayareahaskell/

Please let me know if you can come! We've laid on some food for the start of the meeting.

Cheers,

Satnam

--

[Benedict Gaster]

Conal,

Where would be the best place for us to meet? I'm going to be in the AMD office earlier that day and so can drive from there to pick you up.

Regards,

Ben

Sent from my iPad

[n tung]

Hi Satnam,

    I'll try to be there, sorry for the late reply.

Nicholas — https://ntung.com — 443-267-8864

[Conal Elliott]

[Replying off list]

[Satnam Singh]

Please can you tell me your first name and last name and optionally affiliation? Thank you.

Cheers,

Satnam

[Byron Hale]

As I said somewhere, I plan to attend from Sonoma County.

[Joshua Ball]

Although I said that I was planning to come, something has come up
that has made me unable to come. I don't know if there's limited space
for this, but if there is, someone can take my spot.

[Paul Higham]

Eugene and Vlad particularly, I am prepared to drive. I have Vlad's coordinates but not Eugene's.  I'd like to leave Cupertino by 5h30 latest.  Can this come together?  Any other takers?

::paul

[Paul Higham]

BTW:

Home:  408 255 2763

Work:  408 522 6225

Cell:     408 390 6784

::paul

On 2012-10-15, at 16:08 , Eugene Kirpichov wrote:

[Myles C. Maxfield]

Hopefull there will be a hangout this time. Will someone post a link here to it when the meeting starts?

[Satnam Singh]

Sorry: no Hangout.

Cheers,

Satnam

[Myles C. Maxfield]

Nooooo I won't be able to see it, then, since I can't come today! I'm assuming it's not recorded either.... I guess I'm just out of luck :-(

--Myles

[Max Cantor]

I'm in.  Think I RSVPed a long time ago, just confirming.

Max Cantor

[Bryce Verdier]

Sadly, I think I might be out, please put me as a maybe and I'll do my best to show up tonight.

Bryce

[Edward A Kmett]

i'll try to arrange a version of the talk in NYC for recording.

Sent from my iPhone

[Satnam Singh]

My ride home is no longer coming. Can anyone drive me back to Los Altos later this evening (after a few drinks after the talk)?

Thanks.

Cheers,

Satnam

[Byron Hale]

Good, because parts of my videocam are still in storage.

[Edward Kmett]

I have uploaded a copy of my "Lenses, Folds, and Traversals" slides to Google Drive for anyone who is interested or just had a hard time reading my tiny print as I panned and zoomed through the presentation:

My original slides in keynote 

A copy of the slides exported as PDF

I just wanted to thank you folks for inviting me out here to speak -- I had a great time and it was nice to be able to finally associate faces with so many names and IRC handles. =)

If you have any questions, I'm down in Mountain View until Monday to answer questions in person, and please feel free to email me or contact me via IRC on #haskell.

-Edward

On Thu, Oct 11, 2012 at 8:12 AM, Satnam Singh <s.s...@acm.org> wrote:

Hello,

I am hosting the next Bay Area Haskell meeting at Google's San Francisco office. Details here: https://sites.google.com/site/bayareahaskell/

Please let me know if you can come! We've laid on some food for the start of the meeting.

Cheers,

Satnam

--

[Arthur Chan]

Thanks for the slides Edward! And thanks for coming out and giving the talk!

Arthur :: LittleBrick

[Conal Elliott]

Hi Edward,

Thanks for the talk & the slides! I opened the Keynote file (in Keynote) and got a message bout missing fonts: CooperBlackMS and Consolas. The automatically substituted fonts don't work at all well for your slides.

I'm running Mac OS 10.6.8 and Keynote '09 5.1.1. Do I perhaps need a newer Keynote?

-- Conal

[Arthur Chan]

Consolas should be a free font, IIRC. I recall it being a fixed width font, good for... consoles and coding.

Arthur :: LittleBrick

[Evan Laforge]

Inspired by Edward's lens talk (which was indeed inspiring!), I saw
about converting my project's (minimal) use of fclabels to lens.
Here's what I've come up with so far, as first impressions:

The use of 'a' and 'b' type variables makes it initially unclear which
is the "record" and which is the "field".

I flipped the arguments on the 'lens' constructor's setter, since (b
-> a -> a) is the more usual order.

Lens declarations are one of the few places I often don't write
explicit top level type signatures, because they're a bunch of copy
pasted lines like 'namespace = Lens.lens config_namespace (\v r -> r {
config_namespace = v })'. Unfortunately Control.Lens now requires
either explicit signatures or NoMonomorphismRestriction where fclabels
didn't.

There are tons of operators and ways to combine them. The
documentation is indeed good, but maybe it could do with some more
examples? For example, I settled on this style: 'save_name = (^$) $
config.namespace . to Id.un_namespace . to (map sanitize)'. But
first I experimented with several alternate styles:

map sanitize . Id.un_namespace . (config.namespace ^$)
Lens.view $ config.namespace . to Id.un_namespace . to (map sanitize)
(config.namespace . to Id.un_namespace . to (map sanitize) ^$)

I know there are other possibilities involving embedding ^. and ^% but
they all seemed complicated. I guess this is a place where you have
to develop a local style and stick to it. I enforce it by importing a
local Util.Lens module that re-exports only (lens, (^.), (^$), (.~),
(%~), to). There's a sort of tension between having a lens pipeline
vs. plain functions. Fortunately they are easily interconvertible,
but they're still different types and need an operator to go from one
to the other. And there's motivation to stick to one or the other,
since they compose in opposite directions.

Also, I used an operator <#> which is fmap.view, whose usual use is
'a.b.c <#> State.get'. Otherwise you have to write '(a.b $^) <$>
State.get'. I can easily make my own e.g. (<^>) = fmap . Lens.view;
infixl 4 <^>, but it seems like somewhere among the 700-some functions
there should be something that does that already.

_1 and _2 are not especially compelling fst and snd replacements
because they're more typing. But 'first' and 'second' might start
being replaced. I almost never have >=3 tuples but if I did the tuple
lenses would be more useful.

I can't use .= or %= since I often have two StateMonads in the stack.
So I wind up just writing State1.modify (a.b.c ~. 42) and
State2.modify (...). Works fine.

Those are all minor quibbles, the most concerning thing so far is this:

It appears that Control.Lens wants to infer a lens as a getter or a
setter, and needs an explicit type signature when it is both. For
example, this code worked with fclabels:

(... calls to delete with different types for 'mkid' and 'lens'...)
where
delete ns name mkid lens = do
ident <- path_to_id mkid ns name
vals <- delete_key ident (state^.lens)
return ((lens .~ vals) state, updates)

But with lens I get this error:

Couldn't match type `Control.Lens.Internal.Accessor
(Map.Map k0 a0) d0'
with `Control.Lens.Internal.Mutator (Map.Map k0 a0)'
Expected type: Control.Lens.Setter.Setting
t0 t0 (Map.Map k0 a0) (Map.Map k0 a0)
Actual type: Control.Lens.Getter.Getting
(Map.Map k0 a0) t0 b0 (Map.Map k0 a0) d0
In the first argument of `(.~)', namely `lens'
In the expression: lens .~ vals
In the expression: (lens .~ vals) state

Adding NoMonomorphismRestriction didn't help, but explicitly adding a
signature did:

delete :: (Ord id, Show id) => String -> String -> (Id.Id -> id)
-> Lens.SimpleLens State.State (Map.Map id val)
-> Either String (State.State, [Update.CmdUpdate])

I like to avoid explicit signatures for internal where definitions,
especially when they're as long and annoying as this. Is there a way
around it? It's a bit concerning if Control.Lens is going to start
requiring explicit type signatures everywhere a lens is passed around
and is used both as a getter and setter.

I can reduce it a bit by adding ScopedTypeVariables and annotating
only the lens in the arg list, but of course the ideal is nothing.

Another issue which is admittedly aesthetic (but aesthetics are
important at this level!) is that while unspaced (.) definitely looks
nice for unqualified use, it looks ugly when you have M1.x.M2.y.M3.z.
So I wind up with spaces in between, which is ok, and more consistent
when you have 'to' in there. Previously I used (#) and M1.x#M2.y
was... well, not super nice looking either.

So switching from fclabels to the new lenses is not the automatic win
I assumed it would be. It's definitely nice to easily insert normal
functions into the pipeline with 'to' and have everything going the
same way. I guess that's not possible without separate "setter" and
"getter" notions, which is probably also responsible for the increased
type complexity. I don't have enough polymorphic records to make the
polymorphic update that compelling. I guess the common case is pairs,
and 'first' and 'second' take care of that.

I do still believe that lenses are the best way to a nicer record
system, and this is certainly the most powerful lens library yet. It
would be really nice to just be able to, say, add 'deriving (Lens)' to
a record declaration and have it generate lenses instead of functions.
Perhaps the new generalized data deriving thing could do that? I
haven't looked at that feature much.

I have yet to be comfortable enough with Foldable and Traversable that
I would see where to use them. I've used Monoid's Any + Traversable
wrappers once or twice and at the end switched to plain old 'any f .
toList'. There's a kind of threshold to get over to start using
them... or maybe you just need to be working with certain kinds of
data structures.

[Edward Kmett]

On Tuesday, October 23, 2012 8:59:52 PM UTC-4, Evan wrote:

Inspired by Edward's lens talk (which was indeed inspiring!), I saw
about converting my project's (minimal) use of fclabels to lens.
Here's what I've come up with so far, as first impressions:

The use of 'a' and 'b' type variables makes it initially unclear which
is the "record" and which is the "field".

I flipped the arguments on the 'lens' constructor's setter, since (b
-> a -> a) is the more usual order. 

lens :: (a -> c) -> (d -> a -> b) -> Lens a b c d

can be viewed as a more flexible version of:

lens :: (a -> b) -> (b -> a -> a) -> Simple Lens a b 

which does have the order you wanted.

 

A Simple Lens a b knows how to get 'b' out of an 'a'. You can pretend it is a function from a -> b with other stuff it can do to the target.

Lens a b c d  can be viewed as if it were Lens '(a,b) '(c,d) where you can get a 'c' out of 'a', and replace it with a 'd' to get a 'b'.

Lens declarations are one of the few places I often don't write
explicit top level type signatures, because they're a bunch of copy
pasted lines like 'namespace = Lens.lens config_namespace (\v r -> r {
config_namespace = v })'.  Unfortunately Control.Lens now requires
either explicit signatures or NoMonomorphismRestriction where fclabels
didn't.

makeClassy can automatically graft many of these lenses together. I personally rarely if ever use the actual 'lens' combinator for putting together lenses for instance. 

If you want the top level unsigned style, then yes, you'll need NoMonomorphismRestriction.

There are tons of operators and ways to combine them.  The
documentation is indeed good, but maybe it could do with some more
examples?  For example, I settled on this style: 'save_name = (^$) $
config.namespace . to Id.un_namespace . to (map sanitize)'.   But
first I experimented with several alternate styles:

save_name = view $ config.namespace.to ld.un_namespace.to (map sanitize)

avoids the funny (^$) section and tends to be the version I prefer. 

In general I dislike the use of ^$ as it doesn't play well infix with other combinators, unlike ^. and . which can be mixed cleanly with .~ and does the right thing.

In practice. I never write a combinator that bakes in 'view' and just build the composite lens or projection and use .~, ^. or by write or read from it.

map sanitize . Id.un_namespace . (config.namespace ^$)
Lens.view $ config.namespace . to Id.un_namespace . to (map sanitize)
(config.namespace . to Id.un_namespace . to (map sanitize) ^$) 

I know there are other possibilities involving embedding ^. and ^% but
they all seemed complicated.  I guess this is a place where you have
to develop a local style and stick to it.  I enforce it by importing a
local Util.Lens module that re-exports only (lens, (^.), (^$), (.~),
(%~), to).  There's a sort of tension between having a lens pipeline
vs. plain functions.  Fortunately they are easily interconvertible,
but they're still different types and need an operator to go from one
to the other.  And there's motivation to stick to one or the other,
since they compose in opposite directions.

Also, I used an operator <#> which is fmap.view, whose usual use is
'a.b.c <#> State.get'.  Otherwise you have to write '(a.b $^) <$>
State.get'.  I can easily make my own e.g. (<^>) = fmap . Lens.view;
infixl 4 <^>, but it seems like somewhere among the 700-some functions
there should be something that does that already.

 

a.b.c <#> State.get 

can be rephrased as:

use (a.b.c) 

_1 and _2 are not especially compelling fst and snd replacements
because they're more typing.  But 'first' and 'second' might start
being replaced. I almost never have >=3 tuples but if I did the tuple
lenses would be more useful.

_1 and _2 work on higher arity tuples than just pairs. 

foo^._2 and snd foo have the same number of characters, and 

snd (snd foo) is longer than foo^._2._2

 

I can't use .= or %= since I often have two StateMonads in the stack.
So I wind up just writing State1.modify (a.b.c ~. 42) and
State2.modify (...).  Works fine.

The encouraged style with lenses is to make a composite state.

For example, start with:

newtype LocaleInfo = LocaleInfo { _locale :: String }

makeClassy ''LocaleInfo

data ErrorConfig = ErrorConfig { _errorsAsWarnings :: Bool, ... } 

makeClassy ''ErrorConfig

Then you can define:

data MyConfig = MyConfig { _myLocaleInfo :: LocaleInfo, _myErrorConfig :: ErrorConfig }

makeClassy ''MyConfig

instance HasLocaleInfo MyConfig where localInfo = myLocaleInfo

instance HasErrorConfig MyConfig where errorConfig = myErrorConfig

Then you can safely 'use errorsAsWarnings' in your composite state easily without hand composing all your lenses.

I freely acknowledge this as a limitation of the lens library. 

You can work around this by explicitly using 'cloneLens' around each use site, or by passing a ReifiedLens.

        (... calls to delete with different types for 'mkid' and 'lens'...) 
        where 
        delete ns name mkid lens = do 
            ident <- path_to_id mkid ns name 

            vals <- delete_key ident (state^.cloneLens lens) 
            return ((cloneLens lens .~ vals) state, updates) 

I appreciate the feedback.

-Edward 

[Evan Laforge]

>> I flipped the arguments on the 'lens' constructor's setter, since (b
>> -> a -> a) is the more usual order.
>
> lens :: (a -> c) -> (d -> a -> b) -> Lens a b c d
>
> can be viewed as a more flexible version of:
>
> lens :: (a -> b) -> (b -> a -> a) -> Simple Lens a b
>
> which does have the order you wanted.

But this isn't the default 'lens' implementation, yes? I wound up writing

type Lens a b = Lens.SimpleLens a b

lens :: (a -> b) -> (b -> a -> a) -> Lens a b
lens get set = Lens.lens get (flip set)

If I try to give this type to the default 'Lens.lens' then I get a type error.

>> Lens declarations are one of the few places I often don't write
>> explicit top level type signatures, because they're a bunch of copy
>> pasted lines like 'namespace = Lens.lens config_namespace (\v r -> r {
>> config_namespace = v })'. Unfortunately Control.Lens now requires
>> either explicit signatures or NoMonomorphismRestriction where fclabels
>> didn't.
>
> makeClassy can automatically graft many of these lenses together. I
> personally rarely if ever use the actual 'lens' combinator for putting
> together lenses for instance.

I got sort of scared off by TH when I tried to use it to derive
fclabels lenses. If it assumes some naming scheme then it probably
can't be worked into an existing system. The [(String, String)] thing
is nice, but you wind up repeating all the fields again, which is not
terrible, but already kind of midway to writing them yourself. But
then there were other problems where it broke the build because it
needed some other flags I forget now (it was some -osuf ghc bug that's
fixed now I think). But then it made me rearrange everything because
TH imposes a declaration order. And of course it slows down
compilation, and ghci interpretation even more. In the end I decided
a couple lines of copy-paste lens declarations was not so bad compared
to the TH headache. If I were deriving something more fancy like the
HasWhatever classes rather than a single lens line then it might tip
in the TH direction.

> save_name = view $ config.namespace.to ld.un_namespace.to (map sanitize)

Yeah, I tried that too, maybe I should go back to that. But it would
have to be Lens.view because I use the 'view' name quite a bit.

> In practice. I never write a combinator that bakes in 'view' and just build
> the composite lens or projection and use .~, ^. or by write or read from it.

Good point. I guess I'm starting with a project with no lenses and
gradually working them in, so I start off implementing plain
functions, but using lenses internally.

> a.b.c <#> State.get
>
> can be rephrased as:
>
> use (a.b.c)

Aha, I knew there was something :)

>> I can't use .= or %= since I often have two StateMonads in the stack.
>> So I wind up just writing State1.modify (a.b.c ~. 42) and
>> State2.modify (...). Works fine.
>
> The encouraged style with lenses is to make a composite state.

But then, if I'm not mistaken, you then can't reuse functions without
explicit lifting. I.e. I have M1 and a bunch of functions for it,
then I have M2 which adds its own gunk onto M1 and M3 which adds
different gunk onto M1. If M2 and M3 implement a class for M1 then
they have access to all the M1 functions without lifting. Composing
the state rather than the monads is simpler and I think I would prefer
it in general, but wouldn't I then have to insert shims to go through
the extra indirection? Ah, I see that's what the makeClassy can do.
I'll keep this in mind for the future.

>> I like to avoid explicit signatures for internal where definitions,
>> especially when they're as long and annoying as this. Is there a way
>> around it? It's a bit concerning if Control.Lens is going to start
>> requiring explicit type signatures everywhere a lens is passed around
>> and is used both as a getter and setter.
>
> I freely acknowledge this as a limitation of the lens library.
>
> You can work around this by explicitly using 'cloneLens' around each use
> site, or by passing a ReifiedLens.

Aha, that's what cloneLens is for.

> I appreciate the feedback.

And I appreciate the library! I will definitely be looking for ways
to integrate it more. There's a lot to absorb.

[Edward Kmett]

On Wed, Oct 24, 2012 at 12:18 AM, Evan Laforge <qdu...@gmail.com> wrote:

>> I flipped the arguments on the 'lens' constructor's setter, since (b
>> -> a -> a) is the more usual order.
>
> lens :: (a -> c) -> (d -> a -> b) -> Lens a b c d
>
> can be viewed as a more flexible version of:
>
> lens :: (a -> b) -> (b -> a -> a) -> Simple Lens a b
>
> which does have the order you wanted.

But this isn't the default 'lens' implementation, yes?  I wound up writing

type Lens a b = Lens.SimpleLens a b

lens :: (a -> b) -> (b -> a -> a) -> Lens a b
lens get set = Lens.lens get (flip set)

Ah, you're right. It is 

-- | Build a 'Lens' from a getter and a setter.
--
-- @'lens' :: 'Functor' f => (a -> c) -> (a -> d -> b) -> (c -> f d) -> a -> f b@
lens :: (a -> c) -> (a -> d -> b) -> Lens a b c d
lens ac adb cfd a = adb a <$> cfd (ac a)

{-# INLINE lens #-} 

 

I don't currently plan to rebikeshed it though -- mainly because this is the implementation that avoids the annoying flip on adb. I do now remember choosing this direction for that reason.

I apologize for the seemingly arbitrary difference with fclabels and data-lens though.

As I mentioned, in practice I don't use 'lens' to put together most lenses, because

_2 f (a,b) = (,) a <$> f b

is both shorter than the alternative

_2 = lens snd $ \(a,_) b -> (a,b)

and more explicitly shares the context through the environment when handed a long definition and more easily refactors when converted to a traversal.

If I try to give this type to the default 'Lens.lens' then I get a type error.

>> Lens declarations are one of the few places I often don't write
>> explicit top level type signatures, because they're a bunch of copy
>> pasted lines like 'namespace = Lens.lens config_namespace (\v r -> r {
>> config_namespace = v })'.  Unfortunately Control.Lens now requires
>> either explicit signatures or NoMonomorphismRestriction where fclabels
>> didn't.
>
> makeClassy can automatically graft many of these lenses together. I
> personally rarely if ever use the actual 'lens' combinator for putting
> together lenses for instance.

I got sort of scared off by TH when I tried to use it to derive
fclabels lenses.  If it assumes some naming scheme then it probably
can't be worked into an existing system.  

 

The [(String, String)] thing
is nice, but you wind up repeating all the fields again, which is not
terrible, but already kind of midway to writing them yourself.  But
then there were other problems where it broke the build because it
needed some other flags I forget now (it was some -osuf ghc bug that's
fixed now I think).  

You can specify an explicit function if you have your own scheme in mind. 

e.g.

makeMyLenses = makeLensesWith % lensField .~ \s -> Just (s ++ "_")

>> I can't use .= or %= since I often have two StateMonads in the stack.
>> So I wind up just writing State1.modify (a.b.c ~. 42) and
>> State2.modify (...).  Works fine.
>
> The encouraged style with lenses is to make a composite state.

But then, if I'm not mistaken, you then can't reuse functions without
explicit lifting.  I.e. I have M1 and a bunch of functions for it,
then I have M2 which adds its own gunk onto M1 and M3 which adds
different gunk onto M1.  If M2 and M3 implement a class for M1 then
they have access to all the M1 functions without lifting.  

Actually, makeClassy explicitly generats all of that lifting!

data Foo = Foo { _fooBar, _fooBaz :: Int }

makeClassy ''Foo

auto-generates:

class HasFoo t where

   foo :: Simple Lens t Foo

   fooBar :: Simple Lens t Int

   fooBaz :: Simple Lens t Int

instance HasFoo Foo where ...

then when you make

data Quux = Quux { _quuxFoo :: Foo, ... }

makeClassy ''Foo

auto-generates

class HasQuux t where

  quux :: Simple Lens t Quux

  quuxFoo :: Simple Lens t Foo

and

instance HasQuux Quux where

  quux = id

so

instance HasFoo Quux where

  foo = quuxFoo

does all of the plumbing so that you can just work with

fresh :: (HasFoo t, MonadState t m) => m Int 

fresh = bar <+= 1

even though that would normally have been quuxFoo.fooBar if you just used makeLenses rather than makeClassy.

Composing
the state rather than the monads is simpler and I think I would prefer
it in general, but wouldn't I then have to insert shims to go through
the extra indirection?  Ah, I see that's what the makeClassy can do.
I'll keep this in mind for the future.

This is a major difference between the template haskell generator for lens compared to the other lens libraries.

I rather dislike working with multiple states in the mtl. it leads to a lot of boilerplate accessors.

Nothing is forcing you to use these extra tools, though, and you are free to carry on. I just figured I'd point out the low overhead to doing it "right". :)

 

>> I like to avoid explicit signatures for internal where definitions,
>> especially when they're as long and annoying as this.  Is there a way
>> around it?  It's a bit concerning if Control.Lens is going to start
>> requiring explicit type signatures everywhere a lens is passed around
>> and is used both as a getter and setter.
>
> I freely acknowledge this as a limitation of the lens library.
>
> You can work around this by explicitly using 'cloneLens' around each use
> site, or by passing a ReifiedLens.

Aha, that's what cloneLens is for.

> I appreciate the feedback.

And I appreciate the library!  I will definitely be looking for ways
to integrate it more. There's a lot to absorb.

I'm happy to answer questions and respond to feedback.

-Edward