Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
Most languages, even Java, have a reflection capability to dynamically inspect an object. _Even_ Java? That's a strange point of view considering how much money went into this technology. they didn't take reflection seriously at first, initially providing only a half-baked feature set; that state, and the transition period when they finally noticed that they actually needed better reflection support for their own tools was somewhat painful (was it around/before jdk 1.2? partially coevolving with jni, debuggers, beans, etc.?). I also find it hard to believe that most languages have reflection, especially those which are traditionally focused on efficiency and compilation to native code, like C, C++, Fortran, Pascal, etc. c did have something like '&thing', providing you with the address of 'thing's representation, and in more innocent times, with the ability to read and rewrite that representation:-) c++ had templates, overloading if you doubt the expressive power of even such restricted reflection support, think of buffer overflow exploits or, in the scripting world, of string injection attacks. these are negative examples, but they demonstrate the potential of reflection support: to enable the unexpected, to support evolution of uses not originally planned for. How many languages with reflection can you list? you're kidding, right? lisp, prolog, smalltalk, clos' mop, java, javascript, sh, perl, .. well, most shells&scripting languages, and to a (sometimes very) limited extent, most languages however, that's a bit vague, and i always mix up the directions, so let me try to pin down some terms, so that we're at least mixed up the same way:-) - reification: from program/data to representation (reify, quote) - reflection: from representation to program/data (eval, splice) - meta-programming: programs operating on program representations - reflective programming: programs operating on their own representations unless i'm talking about specific operations/instances of the scheme, i tend to refer to the last item, encompassing all others, when i talk about reflection in programming languages. now, if you consider the old game of quines (programs printing their own representation), most turing-complete languages provide some reflection, the only question is, is it well supported or so awkward that its only uses are limited to theory papers and obfuscated code competitions? I think the reasons are mostly insufficient resources and not enough interest to justify the effort. the former, yes. the latter, no. the lisp/smalltalk folks have known all along, the java folks have found out the hard way, and some of us haskellers are still trying to pretend we do not know, even though we've been bitten often enough: - good reflection support makes it easy to develop tools and to experiment with language extensions - lack of good reflection support causes mutually inconsistent complex workarounds trying to reinvent reflection support the hard way while seriously hampering tool development anyone who tried to develop tools for haskell before the haskell implementations started to provide haskell apis to their inner workings can attest to the difficulties. whereas, the better these apis get, the less current developers are even aware that there used to be problems of that kind. and at the language level, we still use preprocessors, including the c one:-( btw, languages with adequate reflection support tend not to have separate preprocessors), we do have partial efforts like template haskell, data/typeable (and the generic techniques based on them, including scrap your boilerplate), in fact the whole type-class-level programming area could be said to be about type-based meta-programming generating functional programs from type-level proofs, then there are pragmas and implicit insertion of program markers for profiling/coverage analysis/debugging, complete program transformations for profiling/tracing/debugging, multiple separate frontends and ast types, language.haskell, hsx, programatica, poor man's versions of type dynamic, dynamic loading and runtime code generation, data.dynamic, hs-plugins, ghc api, yhc api, hugs server api, .. ah, well, you get the idea?-) perhaps the most important aspect of reflection support is to notice that there is a common theme in all these separate efforts, and a common support base that could help to make all of those efforts and similar tools/extensions/applications easier to develop, with the base designed to be consistent and maintained continuosly, in a single place, instead of developed and forgotten again and again. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
RE: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
> [mailto:[EMAIL PROTECTED] On Behalf Of Tomasz Zielonka > > > On Mon, Jun 18, 2007 at 10:05:40PM +0100, Pasqualino > 'Titto' Assini wrote: > > > Most languages, even Java, have a reflection capability > to dynamically > > > inspect an object. > > > > > It is surprising that Haskell doesn't offer it. > > I'll just add that I've never consciously used reflection, so > I probably > overlook some features of Haskell that give a part of reflection > functionality. On the surface, Haskell would appear to not offer reflection. However, you can get quite a long way with Data.Generics and Data.Dynamic, and deriving (Typeable, Data), which will give you introspection of data types. Here's a nice little article on using deriving Data: http://www.defmacro.org/ramblings/haskell-web.html And the hs-plugins library will give you dynamic loading, but I don't think there's any introspection capability (yet?) Alistair * Confidentiality Note: The information contained in this message, and any attachments, may contain confidential and/or privileged material. It is intended solely for the person(s) or entity to which it is addressed. Any review, retransmission, dissemination, or taking of any action in reliance upon this information by persons or entities other than the intended recipient(s) is prohibited. If you received this in error, please contact the sender and delete the material from any computer. * ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Thu, Jun 21, 2007 at 10:27:58AM +0200, Tomasz Zielonka wrote: > On Mon, Jun 18, 2007 at 10:05:40PM +0100, Pasqualino 'Titto' Assini wrote: > > Most languages, even Java, have a reflection capability to dynamically > > inspect an object. > > > It is surprising that Haskell doesn't offer it. I'll just add that I've never consciously used reflection, so I probably overlook some features of Haskell that give a part of reflection functionality. Best regards Tomek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Mon, Jun 18, 2007 at 10:05:40PM +0100, Pasqualino 'Titto' Assini wrote: > Most languages, even Java, have a reflection capability to dynamically > inspect an object. _Even_ Java? That's a strange point of view considering how much money went into this technology. I also find it hard to believe that most languages have reflection, especially those which are traditionally focused on efficiency and compilation to native code, like C, C++, Fortran, Pascal, etc. How many languages with reflection can you list? > It is surprising that Haskell doesn't offer it. It is surprising that it is surprising to you :-) I think the reasons are mostly insufficient resources and not enough interest to justify the effort. I think an interesting lesson about this comes from the effort that went into Template Haskell (which, BTW, offers some kind of compile time reflection) - this was probably very hard to design and implement, but my impression is that it's not widely used, despite being "cool" and useful. Best regards Tomek ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
Thomas Schilling wrote: * Structural (optionally Type-Directed) Editing Structural editing means that your code is always (mostly) syntactically correct, and in case of haskell maybe also type-checked. This also implies that edit operations have syntactic awareness. paredit[1] emulates this quite nicely for lisp, Proxima does something like this in Haskell for Haskell and XML-based languages. This also needs some way of incremental parsing, for which good techniques already exist[3]. Paredit doesn't just work for lisp. It works for almost all emacs modes, including e.g., haskell and perl (incidentally, I believe it works well for XML/SGML type stuff too). I use it regularly for various programming languages. Of course, it isn't perfect in a few respects, but it's pretty customisable and the author is responsive to ideas and questions. It's not type-directed, of course. Merely structural. But that alone is very handy. (Incidentally I agree with most of Thomas' points which I snipped, too) Jules ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Orthogonal Persistence in Haskell, was: Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Monday 18 June 2007 23:45:23 Claus Reinke wrote: > > 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). Prevayler: http://www.prevayler.org/wiki/ HAppS: http://happs.org (look for the MACID monad) Prevayler is an efficient and very simple way of providing application state persistency. Essentially: - all the state is kept in memory, in native language data structures - whenever a write transaction is performed the system automatically serialises a description of the transaction so that it can be replayed later. - occasionally the whole state can be serialised to produce a snapshot - when the system restarts it reads in the last snapshot and replays all transaction since the last snapshot. Is this orthogonal persistence? I guess it would be, if you never took any snapshot. Snapshots are limited by what can be serialised in the language. But transactions might be serialisable even if the state they produce isn't (because, say, includes arbitrary functions). Best, titto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On 18 jun 2007, at 16.01, Pasqualino 'Titto' Assini 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. I agree, that just duplicating Emacs in Haskell is a rather useless endeavor. If you want any chance of building up sufficient momentum to be superseded by a good-enough emacs module you have to provide killer-features that are hard to do in emacs. Here are some ideas I've been collecting over the years. * Structural (optionally Type-Directed) Editing Structural editing means that your code is always (mostly) syntactically correct, and in case of haskell maybe also type- checked. This also implies that edit operations have syntactic awareness. paredit[1] emulates this quite nicely for lisp, Proxima does something like this in Haskell for Haskell and XML-based languages. This also needs some way of incremental parsing, for which good techniques already exist[3]. * Choose a more flexible editor model Emacs (and probably Vi too) has a really old-fashioned editor model. It represents the complete file as a flat array (gap-buffer) of characters. The Dylan-editor Deuce[2] wisely chose to use polymorphic lines, which requires greater storage overhead but is far more flexible. It allows for easy embedding of different fonts, graphical and interactive objects, folding, and automatically generated objects (like callers, callees, etc.) * Micro-versioned documents With a little care, you can support lightweight, because incremental, tools and you get undo for free. (You don't need redo, since that's just undoing an undo.) This also should be pretty functional. Coupling this with an easy-to-use version-control goes without saying. * No hardcoded editing model Support Emacs-, Vim- or Mac/Windows-style usage. This is important for adoption. * Don't optimize for a console-based interface And there so many more things to do, but I think if you have these much just falls off naturally. Yi is still young, so it's not too late to get on the right track :) I intend to help, as soon as I can find some time for this. [1] .. http://www.emacswiki.org/cgi-bin/wiki/ParEdit [2] .. http://wiki.opendylan.org/wiki/view.dsp? title=AppleDylanScreenshots The Deuce source code is available online as part of the functional developer source code: http://www.opendylan.org/cgi-bin/viewcvs.cgi/trunk/fundev/sources/ deuce/ [3] .. http://harmonia.cs.berkeley.edu/papers/twagner-parsing.pdf ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Mon, 2007-18-06 at 15:01 +0100, Pasqualino 'Titto' Assini wrote: > LambdaBot, hpaste and hoogle as well as the Haskell Wiki and indeed even this > mailing list can all be thought as elements of a cooperative, ubiquitous, > customisable, zero-installation, distributed and integrated (that should be > enough buzzwords for anybody) development system. > > What we need is to connect the dots and [...] Oh, good Lord! Are we going to write all of this in points-free style? :O -- Michael T. Richter <[EMAIL PROTECTED]> (GoogleTalk: [EMAIL PROTECTED]) I'm not schooled in the science of human factors, but I suspect surprise is not an element of a robust user interface. (Chip Rosenthal) <> signature.asc Description: This is a digitally signed message part ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
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
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Mon, 2007-06-18 at 22:05 +0100, Pasqualino 'Titto' Assini wrote: > 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. You might find this cute: https://www.youos.com/ ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On Monday 18 June 2007 16:13:02 you wrote: > I just did a quick read through of your dream and I'm not going to say > either way with it. But I would like to point out, just to make sure > you've considered it, that my dream--or maybe my reality--involves > being able to code without the requirement of a network connection. > > Bryan That's a very fair point. An "ubiquitous" IDE should also work when disconnected. Luckily, Web applications can be designed to work offline. In effect, modern AJAX based web apps already execute most of their code on the client side, going back to the server only when absolutely necessary and there are now technologies like Google Gear to efficiently store/access information locally so further reducing dependency on remote services. Best, titto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
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 implementations? Is there any fundamental reasons why Haskell functions/closures cannot be serialised? I believe that this is precisely what the distributed version of GHC used to do. 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? best, titto ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
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 outline, you're almost certain to find this interesting: Croquet is a powerful open source software development environment for the creation and large-scale distributed deployment of multi-user virtual 3D applications and metaverses that are (1) persistent (2) deeply collaborative, (3) interconnected and (4) interoperable. The Croquet architecture supports synchronous communication, collaboration, resource sharing and computation among large numbers of users on multiple platforms and multiple devices. http://croquetconsortium.org the screenshots can be misleading in their simplicity, so be sure to browse some of the papers referenced on the 'about' page in the technology section http://croquetconsortium.org/index.php/About_the_Technology Up to you now, what is your dream? 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? type Dynamic and dynamic loading are still outside the language definition [hs-plugins], as are distribution [gdh], persistence [many starts, no finish, but see Clean's first class i/o], 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''. claus ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
Re: [Haskell-cafe] To yi or not to yi, is this really the question? A plea for a cooperative, ubiquitous, distributed integrated development system.
On 6/18/07, Pasqualino 'Titto' Assini <[EMAIL PROTECTED]> 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. [...] Up to you now, what is your dream? I just did a quick read through of your dream and I'm not going to say either way with it. But I would like to point out, just to make sure you've considered it, that my dream--or maybe my reality--involves being able to code without the requirement of a network connection. Bryan ___ Haskell-Cafe mailing list Haskell-Cafe@haskell.org http://www.haskell.org/mailman/listinfo/haskell-cafe
