Some guidance

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
6 messages Options
Reply | Threaded
Open this post in threaded view
|

Some guidance

Peter Hall
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.htm>

Reply | Threaded
Open this post in threaded view
|

Some guidance

David McBride
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.


Reply | Threaded
Open this post in threaded view
|

Some guidance

Frerich Raabe
In reply to this post by Peter Hall
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 - raabe at froglogic.com
www.froglogic.com - Multi-Platform GUI Testing



Reply | Threaded
Open this post in threaded view
|

Some guidance

Peter Hall
> 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. :-}

This has been said a lot, which is why I was looking for suggestions. I
didn't think about separating them into different modules. It might work.

I think, for now, I'm going to keep it simple and just use the "fast" case
and worry about how to refactor to use both, when it comes to it.


Peter


On 2 July 2013 08:13, Frerich Raabe <raabe at froglogic.com> wrote:

> 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/**
>> 6974d66ae51459479c19be291d075b**bdeb718b53/AutoTrader/MtGox/**Types.hs<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 - raabe at froglogic.com
> www.froglogic.com - Multi-Platform GUI Testing
>
>
> ______________________________**_________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/**mailman/listinfo/beginners<http://www.haskell.org/mailman/listinfo/beginners>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20130702/d4e3a049/attachment.htm>

Reply | Threaded
Open this post in threaded view
|

Some guidance

Will Ness-2
In reply to this post by Peter Hall
Peter Hall <peter.hall <at> memorphic.com> writes:

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

Are you aware of Adi Shamir's et.al. paper and its implications? Basically,
they discovered it's a shell game fraud. (search terms: "bitcoin shamir").





Reply | Threaded
Open this post in threaded view
|

Some guidance

Michael Peternell
How did you come to this conclusion?

You mean this paper, right?
http://eprint.iacr.org/2012/584.pdf

I read that paper, and I had some computer science classes in university, but I didn't see anything that hints at shell game fraud, nor did I find anything related to shell games, nor anything related to fraud. A search for "bitcoin shell game fraud" didn't provide any useful information...

-Michael

Am 06.07.2013 um 23:35 schrieb Will Ness <will_n48 at yahoo.com>:

> Peter Hall <peter.hall <at> memorphic.com> writes:
>
>>
>> Hi, I'm working on a little library to trade bitcoins via the MtGox
> API.https://github.com/peterjoel/auto-trader
>
> Are you aware of Adi Shamir's et.al. paper and its implications? Basically,
> they discovered it's a shell game fraud. (search terms: "bitcoin shamir").
>
>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners