Re: Another nit

G'day Lex.

Tony Morris
http://tmorris.net/



Lex Spoon wrote:
> Hey, Tony, it is always fun to read posts by people who have
> experimented with their own library support!
> 
> 
> Just a couple of small notes:
> 
> 
> Tony Morris <tmorris@xxxxxxxxxxx> writes:
>> I have written my own cons list - it is lazily evaluated. At first it
>> was an experiment, but after learning more, I decided it actually has
>> merit over the existing Scala APIs so I took it further. Here are some
>> of the implicit conversions I have:
> 
> By existing APIs, do you include scala.Stream, by the way?  The name
> scala.Stream makes it hard to find for people who are looking for
> "Lazy List".

Yes, I have seen scala.Stream, but it took Martin to point it out to me
for the reasons that you mention. I don't like the fact that its type
parameter is invariant, nor the fact that it is a trait.

> 
> 
>> MyList[A] <-> scala.List[A]
>> MyList[A] <-> scala.Stream[A]
>> MyList[A] <-> scala.Iterator[A]
> 
> These are generally cool, but this third one looks weird to me.  Scala
> carefully distinguishes Iterable's from Iterator's.  If you want an
> iterator, you send elements.

I don't understand your point here; an Iterator *is* a lazy list, just
in the imperative model - I had to write imperative code with a
destructive update (cough, choke) in that method. I'm interested in
understanding your point here.

> 
> Anyway, I'd love to hear how your experience goes with it.
> 
> 
>> In Scala:
>>
>> abstract class Equal[A] {
>>   def eq (a1: A)(a2: A): Boolean = {
>>     !(neq(a1)(a2))
>>   }
> 
> You should name this something else, because "eq" is Scala's name for
> Java's "==" !  (Scala's == calls equals().)

Thtat's exactly why I named it 'eq' instead of '=='. For what it's
worth, I have since renamed it to '===' (and !==)

> 
> 
>>     // by the way, can you pattern match both xs1 and xs2 here?
> 
> Try a match on the tuple {xs1,xs2}.  Maybe that will shorten the code
> nicely.

I'll give it a burl :)

> 
>> But then you can get really funky within a mixin. How about the ordering
>> relationship?
>> trait Ord[A] extends Equal[A] {
> 
> This one is in the library, by the way.  Great minds think alike.  :)

Where is it? One of the primary reasons I have these 'type-classes' is
so that I can have the Enum type-class (which inherits from Ord, which
inherits from Equal). That way, I can write what I see as better range
functions (among other things).

There is talk of releasing this library code to the public domain so
maybe it would be best to wait until then to discuss it more. It would
be interesting to get feedback on what could be improved. I'm still
trying to understand whether I should use implicit defs or view notation
- it seems the view notation is a little more restrictive?

> 
> -Lex
> 
>