[Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.

Pasqualino 'Titto' Assini tittoassini at gmail.com
Mon Jun 18 17:05:40 EDT 2007

Hi Claus,

On Monday 18 June 2007 18:14:58 Claus Reinke wrote:
> >Having just presented a case for the possible rationality of the
> >irrational decision of creating an Emacs-like IDE in Haskell, I
> >wonder if we should not be even more irrational and contemplate the
> >possibility of using Haskell to create a radically different kind of
> >IDE..  New technologies are often used to imitate and reimplement the
> >artefacts of previous technologies.
> don't underestimate those "previous" technologies, though. given your
>  you're almost certain to find this interesting:
>  Croquet is a powerful open source software development environment

Thanks for the reference.

I actually knew about Croquet but I thought of it mostly as an "open-source 
second life" because of its emphasys on shared 3D worlds but you are quite 
right, it might also be useful for cooperative software development.

I must admit that my dream doesn't go so far, I was more thinking about 
Web/Web services kind of technology to integrate distributed traditional 
development text-based tools (editors, compilers, etc.) plus a configurable 
Web based UI. 

> if you look closely, you'll see that croquet is implemented in squeak,
> which in turn is a re-implementation of one of the ancient smalltalks.
> squeak is by no means the ideal implementation language for this
> kind of project, nor am i completely convinced by the synchronous
> approach used for croquet. but while implementation of croquet
> in squeak is obviously doable, i see various difficulties for doing
> the same in haskell.
> where squeak is too dynamic/imperative/flexible, haskell is too
> static/unreflective/limited (ever tried to pass functions through
> haskell's i/o interface?

Is this really a limitation of the language proper or just of its 

Is there any fundamental reasons why Haskell functions/closures cannot be 

I believe that this is precisely what the distributed version of GHC used to 

Most languages, even Java, have a reflection capability to dynamically inspect 
an object. It is surprising that Haskell doesn't offer it.

> persistence [many starts, no finish

Have you checked the prevayler-inspired approach implemented in HAppS ? 

> , but see Clean's first  
> class i/o]

What advantages does it provide?

> reflection/meta-programming [Data/Typeable, template 
> haskell..; meta ml?]). 
> one dream would be successors to haskell and 
> croquet so that croquet' could be implemented in haskell''.

Is just the lack of reflection in Haskell that you miss? 

Or there are other things as well?



More information about the Haskell-Cafe mailing list