[Haskell-beginners] Ambiguous type variables

[David McBride]

You might try Data.Sequence.  Its update/take/drop/index etc all have nice
performance and you can use Foldable.toList to convert it to a list
whenever you feel a pressing need to use list pattern matching without
sacrificing much performance.


On Tue, Mar 18, 2014 at 9:47 PM, Dennis Raddle <dennis.raddle at gmail.com>wrote:

> I have another question, speaking of optimizing too soon. My data
> structures will be things like rows of musical notes, implementable easily
> as lists of lists. But I will often need to do things like replace one
> element in a list. Should I use Array's? As I see it, lists get me certain
> simplicity, and many operations using the natural syntax will be concise.
> But then I'll have to do searches or random access and replacement.
>
> What criteria does one use to make decisions like this? Do the easiest one
> first and optimize later? I'm not even sure which is easiest as I don't
> think there is a list element replacement function in the libraries.
>
>
> On Mon, Mar 17, 2014 at 3:56 PM, Dennis Raddle <dennis.raddle at gmail.com>wrote:
>
>>
>>
>>
>> On Mon, Mar 17, 2014 at 1:28 PM, Kim-Ee Yeoh <ky3 at atamo.com> wrote:
>>
>>>
>>> On Tue, Mar 18, 2014 at 2:14 AM, Dennis Raddle <dennis.raddle at gmail.com>wrote:
>>>
>>>> class Bt d c memo | d -> c, d -> memo where
>>>
>>>
>>> Could you also say something about the instances you intend to implement
>>> for this typeclass?
>>>
>>> If there's only 1, which the statement of the problem suggests as much,
>>> you can dispense of the typeclass entirely and just work with plain
>>> functions!
>>>
>>> Could be that you want something working first and generalize /
>>> polymorphize later.
>>>
>>
>>
>> I don't know yet how I want to represent the solution being searched for;
>> i.e. I don't know how I want to represent musical structures, and I need
>> the freedom to try different ones without rewriting my code. I also wanted
>> to implement a few toy problems to do testing on my algorithm.
>>
>> But, you are absolutely right that I am generalizing too quickly. I
>> worked on a toy problem today and had several insights. I noticed that some
>> problems have specifics that don't fit the same mold.
>>  -Dennis
>>
>
>
> _______________________________________________
> Beginners mailing list
> Beginners at haskell.org
> http://www.haskell.org/mailman/listinfo/beginners
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.haskell.org/pipermail/beginners/attachments/20140319/470d3010/attachment.html>