On Tue, 21 Jul 1998, Alex Ferguson wrote:
> > So I tried creating my own Stringable class:
> > > class Stringable a where
> > > toString::a -> String
>
> > > (./) :: (Stringable a,Stringable b)=> a->b->String
> > > x./y = (toString x)++(toString y)
>
> Wouldn't it be a great deal less tortuous to define:
>
> > x .++ y = show x ++ y
>
> > x ++. y = x ++ show y
>
> and then to use (++), (.++), or (++.), as appropriate?
No, because
1. I will be changing my output all the time and don't want to keep having
to remember the types on either side of my append
2. I don't want to use show because I may render types differently (even
if they are strings)
> > > res = (2+2) ./ " hello"
>
> > Is there any way to convince Haskell to just resolve these numbers to
> > SOMETHING by default? Then I can just declare that type an instance of
> > Stringable.
>
> It took me a little head-scratching to work out why this _isn't_ handled
> by numeric defaults (and I'm still not 100% clear what the reason for
> the requirement that defaults only resolve "standard" context
> ambiguities), but clearly, that wouldn't work for non-numeric types,
> which doesn't seem to be as general as you'd like.
I am not sure what you are saying here, but I think your answer is no.
> > Ideally, I would prefer to be able to use a more natural string
> > concatenation operator for this like (.) (..) or, ideally, (+), but I
> > guess that is not possible.
>
> I'm not sure why you'd want (.) or (..) anyway, but from my (admittedly
> limited) experience of Java, I'm truly glad one can't use (+) in this
> way...
I want (.) or (..) because they are more convenient to enter via keyboard
and because they are most similar to the perl syntax which does the same
thing. I agree with you that (+) is probably the wrong way to go (bad
habits from Java).
-Alex-
___________________________________________________________________
S. Alexander Jacobson i2x Media
1-212-697-0184 voice 1-212-697-1427 fax
