[hoc-users] Re: Haskell-on-Cocoa & ghc-6.4

[Wolfgang T. <wol...@gm...>]

On 9-Sep-05, at 6:58 PM, David Christensen wrote:

> Wolfgang,
>
> Thanks for the info -- got it all built and playing with it now.  A  
> few quick questions, as it seems like the mailing lists are fairly  
> sparse at this point, and google did not turn up anything useful:

So lets start making the mailing lists more interesting, shall we?  
I'm Cc-ing the hoc-users list now.

> 1) I'm trying to write a Show instance for NSString, NSArray and  
> some other core types in order to be able to use the string  
> representation of the Cocoa datatype in my Haskell program.   
> Currently, I'm using toNSString and fromNSString to try and convert  
> the types to something which can be used in Haskell's IO system,  
> but I keep running into errors ... but I'm still not enough of a  
> Haskell guru to be able to debug them.
>
> What I've got now is:
>
> instance Show (NSString ()) where
>     show = fromNSString

The error is due to a limitation in Haskell 98 (which, I think, was  
put there to prevent the type class system from becoming to complex).  
If you use -fglasgow-exts, the above should be legal.

A note on the () and why instance Show (NSString a) is a Bad Thing:  
The () means exacly NSString, no subclasses, and the a means,  
subclasses allowed. NSMutableString is a subclass of NSString, and  
using pure functions on mutable objects is evil; therefore,  
fromNSString has type NSString () -> String rather than NSString a ->  
String.

> 2) CamelBones, a Perl-Cocoa bridge, supports "toll-free bridging"  
> between Perl types and Obj-C types NSArray, NSDictionary, NSString,  
> etc.  Is this an option with hoc for future development?

It's not that easy; for Perl, they probably get to do it based on  
some runtime type of the object (NSString or Perl String). That won't  
work for Haskell, of course.
To do it the statically typed way, we might introduce some type  
class, say "StringClass", and make both NSString () and String  
instances of that class. This would mean a lot of ambiguity, though;  
whenever you get a NSString object from one method and pass it to  
another, you'd have to specify a type annotation (:: NSString ()  
or :: String) to specify whether it should be converted to a Haskell  
String and back, or not. I don't think it's worth it, I'd rather  
stick with explicit to/fromNSString.

However, if, one day in the future, there is a standard library type  
class for strings (to support things like packed strings more  
natively), we could take advantage of that by making NSString () an  
instance of that class.
Don't hold your breath though, this is being discussed about once a  
year on various Haskell mailing lists, with no results so far.


Cheers,

Wolfgang