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

[Claus Reinke]

hi titto,

> 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.

the first corporation betting its money on croquet is Qwaq:

    http://croquetconsortium.org/index.php/Current_Projects#Qwaq_Projects
 
    ..proprietary Croquet-based collaborative spaces enabling our customers 
    to integrate their existing 2D media, 3D models and simulations. These 
    spaces enable interlinked virtual conference rooms dedicated to each 
    area of corporated interest..

cooperative software development is just one instance of that (i seem
to recall a reference to ubuntu linux using croquet as a coordination
tool, but my own network connection is highly uncooperative at the 
moment..; sorry, seems i have to send this email with without adding 
the necessary references/urls below; most of the keywords should 
show up on google, but most connections are timing out on me..).

>> 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 
> implementations?

both, though the/some implementations are further ahead than the 
"language proper". but if those implementation branches are not
consolidated into the main implementations and the language that
is used to write the standard libraries, they will bitrot (some have).
 
> Is there any fundamental reasons why Haskell functions/closures 
> cannot be serialised?

no, and that is part of the problem: the language would need to be
extended, but the academically interesting issues have been tackled, 
all that is left is a lot of work (that is why these things would be so
valuable: complex implementation machinery, controlled by very 
small language extensions, sometimes even language simplifications,
such as lifting existing restrictions on i/o), preferably with very good 
planning, so that all the work does not become useless right after it 
is finished. there isn't much hope that this issue is going to be settled 
via the usual academic funding sources.

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

yes, distributed systems have some of the same issues. but note that 
you said "version of ghc", not "ghc", not "haskell". even what is there 
hasn't been folded back into the mainline, nor does it keep up with
other mainline developments.

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

it has to be done with care, or it will invalidate *all* your nice reasoning
about haskell programs. random example
    
    reify (f . g) == [| f . g |] =/= [| \x-> f (g x) |] == reify (\x-> f (g x))

reification is not a referentially transparent program context.

>> persistence [many starts, no finish
> 
> Have you checked the prevayler-inspired approach implemented in HAppS ? 

no, do you have a reference? but i meant "orthogonal persistence", as in
all program parts can persist, including functions, thunks, types,.. once 
you start going down that route, the rigid globally static/dynamic distinction 
quickly becomes meaningless (instead one has locally static/dynamic phases 
of evaluating program parts, ie, one does a dynamic type check in each 
static phase, and if that succeeds, the immediately following dynamic 
phase will be type correct without further "runtime" type checks).

if you can store, retrieve, visualise and edit collections of functions,
you already have first class modules (there was an early thesis on
a persistent algol, with a title roughly like "persistent first-class
procedures are enough"). and the classical distinctions between
language and programming environment begin to blur considerably.

>> , but see Clean's first  class i/o]
> 
> What advantages does it provide?

please see their papers. but in essence, they approach the same problem
from a different direction: if one doesn't limit i/o to fully evaluated non-
functions, as haskell does, one can make anything persist, just by writing
it to a file (which thereby becomes a typed object rather than a string
of bytes), and one can distribute anything, including code, by writing it
accross the network. 

it raises all the same issues as orthogonal persistence: type Dynamic is 
needed when checking that input is of the type it claims to be, types 
need to be stored/validated via some clearing house system (there's 
no guarantee that the program that reads an expression has compatible 
types to the program that wrote it, types and compilers evolve, ..).

>> 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?

there is more, but i thought my list was already long and fundamental 
enough?-)

sorry again about the lack of references in this email,
claus