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
_______________________________________________
Haskell-Cafe mailing list
Haskell-Cafe@haskell.org
http://www.haskell.org/mailman/listinfo/haskell-cafe
