Send Beginners mailing list submissions to
        [email protected]

To subscribe or unsubscribe via the World Wide Web, visit
        http://www.haskell.org/mailman/listinfo/beginners
or, via email, send a message with subject or body 'help' to
        [email protected]

You can reach the person managing the list at
        [email protected]

When replying, please edit your Subject line so it is more specific
than "Re: Contents of Beginners digest..."


Today's Topics:

   1. Re:  Still confused (James Jones)
   2. Re:  Still confused (Michael Orlitzky)
   3. Re:  Still confused (Marc Gorenstein)
   4. Re:  Still confused (Marc Gorenstein)
   5.  Some guidance (Peter Hall)
   6. Re:  Some guidance (David McBride)
   7. Re:  Some guidance (Frerich Raabe)
   8. Re:  Question about precedence (David Virebayre)


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

Message: 1
Date: Mon, 1 Jul 2013 13:23:45 -0500
From: James Jones <[email protected]>
Subject: Re: [Haskell-beginners] Still confused
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <[email protected]>
Message-ID:
        <CAFY=ada6_2ftmklm9mdxc_rxwzrzke773lewm0q5ti6ttvq...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

I'm a beginner, too, but I look at it this way: (+) is the uncurried,
unsectioned add function. You use (+) when it happens to be convenient or
necessary to use it the way you'd use functions that you give names, e.g.
passing it to another function the way you do with map.

A section, on the other hand, is a partial application of a function, and
the way to remember what happens to the input it takes is to notice which
operand is inside the parentheses of the section.

( / 8) is the function that, given n, returns n / 8.
(8 / ) is the function that, given n, returns 8 / n.

It only really makes a difference when the function in question isn't
commutative.


On Mon, Jul 1, 2013 at 1:03 PM, Marc Gorenstein
<[email protected]>wrote:

> Hi Brandon, Darren, and Michael,
>
> Thanks for you responses, but I'm still confused.
>
> Here are two examples of operator sections. The first takes the infix
> operator
> / and turns it into a prefix operator.
>
> Prelude> let eight_div_by = ((/) 8 )
> Prelude> eight_div_by 4
> 2.0
>
> I get that. But look at the following:  We now have a prefix operator with
> the input on the "wrong" side.
>
> Prelude> let div_by_eight = ( / 8 )
> Prelude> div_by_eight 4
> 0.5
>
> Why should ( / 8) 4 = 0.5?
>
>
> Thanks again,
>
> Marc
>
>
> _______________________________________________
> Beginners mailing list
> [email protected]
> http://www.haskell.org/mailman/listinfo/beginners
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20130701/8c5d2217/attachment-0001.htm>

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

Message: 2
Date: Mon, 01 Jul 2013 14:33:28 -0400
From: Michael Orlitzky <[email protected]>
Subject: Re: [Haskell-beginners] Still confused
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1

On 07/01/2013 02:03 PM, Marc Gorenstein wrote:
> Hi Brandon, Darren, and Michael,
> 
> Thanks for you responses, but I'm still confused. 
> 
> Here are two examples of operator sections. The first takes the infix 
> operator 
> / and turns it into a prefix operator. 
> 
> Prelude> let eight_div_by = ((/) 8 )
> Prelude> eight_div_by 4
> 2.0
> 
> I get that. But look at the following:  We now have a prefix operator with 
> the input on the "wrong" side. 
> 
> Prelude> let div_by_eight = ( / 8 )
> Prelude> div_by_eight 4
> 0.5
> 
> Why should ( / 8) 4 = 0.5?
> 

This isn't a normal Haskell function application, it's a special case
(Brandon pointed at the place in the spec where it's defined.)

It does a trick, transforming (/ 8) into "flip (/) 8" so that the
argument will wind up in the right place. You've got the 8 on the
right-hand side of the division operator, and that's where it stays.

It only works for binary operators, since they have a left-hand argument
and a right-hand argument. (4 /) will return a function, "four divided
by something," and (/ 8) will return a function, "something divided by
8." In both cases, the 4 or the 8 stay on the same side of the division
operator. But there's a hidden transformation happening to get the other
argument in the right spot.





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

Message: 3
Date: Mon, 1 Jul 2013 18:42:05 +0000 (UTC)
From: Marc Gorenstein <[email protected]>
Subject: Re: [Haskell-beginners] Still confused
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=utf-8


> 
> Yes. A section is just this conversion of an infix operator to a prefix 
function, but with one parameter carried along with it. You can supply it on 
either side as appropriate; (/ 8) is the same as (\x -> x / 8) which in turn 
is the same as (\x -> (/) x 8), whereas (8 /) is (\x -> 8 / x) is (\x -> (/) 8 
x). Note that it must be *inside* the parentheses to be a section; if it's 
outside, then it's a normal function (not operator!) parameter.
> 
> -- 
> brandon s allbery kf8nh ? ? ? ? ? ? ? ? ? ? ? ? ? ? ? sine nomine associates
>


Hi Brandon (and others),

Thanks very much. I'm no longer confused. I can see that a Section is a 
special case that turns a binary infix  operator turns into a single-parameter 
prefix function. The equivalence to a lambda abstraction makes it clear.

Thanks,

Marc






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

Message: 4
Date: Mon, 1 Jul 2013 18:53:40 +0000 (UTC)
From: Marc Gorenstein <[email protected]>
Subject: Re: [Haskell-beginners] Still confused
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=us-ascii


> 
> Yes. A section is just this conversion of an infix operator to a prefix 
function, but with one parameter carried along with it. You can supply it on 
either side as appropriate; (/ 8) is the same as (\x -> x / 8) which in turn 
is the same as (\x -> (/) x 8), whereas (8 /) is (\x -> 8 / x) is (\x -> (/) 8 
x). Note that it must be *inside* the parentheses to be a section; if it's 
outside, then it's a normal function (not operator!) parameter.

Thanks again.

Now I also understand why 
Prelude> ( $ 4 ) sqrt
2.0

because it is equivalent to 
Prelude> (\x -> x 4) sqrt
2.0


Marc




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

Message: 5
Date: Mon, 1 Jul 2013 23:52:41 +0100
From: Peter Hall <[email protected]>
Subject: [Haskell-beginners] Some guidance
To: "[email protected]" <[email protected]>
Message-ID:
        <caa6hak4-uj63kyn2be7er_0xnpg+c7rcx4gf4rgn4fl9-hg...@mail.gmail.com>
Content-Type: text/plain; charset="iso-8859-1"

Hi, I'm working on a little library to trade bitcoins via the MtGox API.
https://github.com/peterjoel/auto-trader

I haven't got very far yet, but I feel like I'm already overcomplicating
things, especially the module structure. The reason it has so many modules,
even though there is hardly any code, is partly because I wanted to expose
the properties of the MtGoxTicker record as lenses, without polluting the
namespace with the underlying _accessors. Is this good or is there a more
usual way of dealing with the problem?

The other problem I'm facing is with name collisions for record accessors.
There are two versions of MtGoxTicker from different services - one with a
subset of the properties, which is supposed to be faster (it isn't, but
that isn't the point). The data types are here
https://github.com/peterjoel/auto-trader/blob/6974d66ae51459479c19be291d075bbdeb718b53/AutoTrader/MtGox/Types.hs.
One is commented one out while I decide what to do. What is the best way to
model those records to avoid collisions, while not being confusing to users
of the library? I am very tempted to use type classes, but that feels
naughty. Using unique prefixes seems bad too - it would be nice for some
code to be able to use them interchangeably if they don't need all the
fields.

Is it possible to use unique names for the actual record accessors, but
share the names of their lenses?

Thanks,

Peter
-------------- next part --------------
An HTML attachment was scrubbed...
URL: 
<http://www.haskell.org/pipermail/beginners/attachments/20130701/3658c52b/attachment-0001.htm>

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

Message: 6
Date: Mon, 1 Jul 2013 21:17:52 -0400
From: David McBride <[email protected]>
Subject: Re: [Haskell-beginners] Some guidance
To: [email protected],   The Haskell-Beginners Mailing List -
        Discussion of primarily beginner-level topics related to Haskell
        <[email protected]>
Message-ID:
        <CAN+Tr41QpJ2751R7=C2MUUURH7u80cs6sLsu3XQEvShYudb=5...@mail.gmail.com>
Content-Type: text/plain; charset=ISO-8859-1

You can export specific pieces explicitely, ie:

module AutoTrader.MtGox.Types (MtGoxTicker(MtGoxTicker), tkLast,
tkLastAll, etc...) where

and it will not export the _ field accessors.  It is a hassle, but
that's the price you pay for all that code generation.

As for the two versions of MtGoxTicker, if they have a lot in common,
you might think about using type classes for that.

class BasicInfo a where
  tkHigh :: Lens a a MtGoxPrice MtGoxPrice
  tkLow :: Lens a a MtGoxPrice MtGoxPrice
--  ...

class ComplexInfo a where
  tkAvg :: Lens a a MtGoxPrice MtGoxPrice
--  ...

data MtGoxTickerBrief = MtGoxTickerBrief {
  _briefHigh :: MtGoxPrice,
  _briefLow :: MtGoxPrice
}
data MtGoxTickerFull = MtGoxTickerFull {
  _fullHigh :: MtGoxPrice,
  _fullLow :: MtGoxPrice,
  _fullAvg :: MtGoxPrice
}

makeLenses ''MtGoxTickerBrief
makeLenses ''MtGoxTickerFull

instance BasicInfo MtGoxTickerBrief where
  tkHigh = briefHigh
  tkLow = briefLow

instance BasicInfo MtGoxTickerFull where
  tkHigh = fullHigh
  tkLow = fullLow

instance ComplexInfo MtGoxTickerFull where
  tkAvg = fullAvg

I'm sure there are other ways of dealing with it, but this works.



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

Message: 7
Date: Tue, 02 Jul 2013 09:13:51 +0200
From: Frerich Raabe <[email protected]>
Subject: Re: [Haskell-beginners] Some guidance
To: [email protected]
Message-ID: <[email protected]>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed

Hi Peter,

Am 7/2/2013 12:52 AM, schrieb Peter Hall:
> The other problem I'm facing is with name collisions for record
> accessors. There are two versions of MtGoxTicker from different services
> - one with a subset of the properties, which is supposed to be faster
> (it isn't, but that isn't the point). The data types are here
> https://github.com/peterjoel/auto-trader/blob/6974d66ae51459479c19be291d075bbdeb718b53/AutoTrader/MtGox/Types.hs.
> One is commented one out while I decide what to do. What is the best way
> to model those records to avoid collisions, while not being confusing to
> users of the library? I am very tempted to use type classes, but that
> feels naughty. Using unique prefixes seems bad too - it would be nice
> for some code to be able to use them interchangeably if they don't need
> all the fields.

This sounds like a good case for two separate modules:

AutoTrader.MtGox.Ticker.Full would have a data Ticker = Ticker { .. } 
which is the commented-out MtGoxTickerFull, and 
AutoTrader.MtGox.Ticker.Fast would balso have a 'data Ticker = ...', 
which would be your MtGoxTicker.

This would allow you to use the same field names without getting 
clashes, users of your library could choose hwo to import the types, 
i.e. what prefix to use - and people using no fields from the full 
ticker could switch their code by changing something like

   import qualified AutoTrader.MtGox.Ticker.Full

to

   import qualified AutoTrader.MtGox.Ticker.Fast

As a side note, I think that in the vast majority of cases where you 
think that a type class is be a good solution - it's not. :-}

-- 
Frerich Raabe - [email protected]
www.froglogic.com - Multi-Platform GUI Testing




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

Message: 8
Date: Tue, 2 Jul 2013 09:14:19 +0200
From: David Virebayre <[email protected]>
Subject: Re: [Haskell-beginners] Question about precedence
To: The Haskell-Beginners Mailing List - Discussion of primarily
        beginner-level topics related to Haskell <[email protected]>
Message-ID:
        <cam_wfvuqtdhvqiwkjnmq0fwcrjd86pq7te7cs1baqqgyqbz...@mail.gmail.com>
Content-Type: text/plain; charset=UTF-8

>   ghci> let plus_one = (+) 1
>   ghci> let plus_one = (+ 1)

> Either notation will work, but they do subtly different things: in the
> first case, you get 1 + x, and in the second, you get x + 1. Nevertheless.

Exactly. You can get 1+x with a section, just write it  (1+)

> Division works the same way.

That's where the subtly different things becomes not so subtle,
because if you define

two_divided_by_1 = (/) 2
two_divided_by_2 = (/ 2)

in the first case you indeed define a function that divides two by the
number given,
but in the second case it's a function that divides the number given by two.
You have to define it like this: two_divided_by_3 = (2 /)

Prelude> let two_divided_by_1 = (/) 2
Prelude> let two_divided_by_2 = (/2)
Prelude> two_divided_by_1 4
0.5
Prelude> two_divided_by_2 4
2.0
Prelude> let two_divided_by_3 = (2/)
Prelude> two_divided_by_3 4
0.5
Prelude>



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

_______________________________________________
Beginners mailing list
[email protected]
http://www.haskell.org/mailman/listinfo/beginners


End of Beginners Digest, Vol 61, Issue 3
****************************************

Reply via email to