Alex Jacobson:
> > > > (./) :: (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.
Is this likely to be a problem, if the types are always either
a String, or an instance of Show/Stringable?
> 2. I don't want to use show because I may render types differently (even
> if they are strings)
Don't know how to get around this, then, without running into the
"non-Standard class" problem, below. (To wit, because "Stringable"
isn't a Prelude or standard library class, numeric defaults aren't
applied.)
> > > > 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.
The short answer is no, AFAIK, but in the case of numeric types I'm
not clear what the underlying reason why it's "no". And now that I
stop to think about it, that's far and away the most likely "problem"
case.
> 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.
If it's of any comfort, (...) works...
Slainte,
Alex.
