I read an interesting paper on designing a version management system
for XML documents
http://www.goshaky.com/publications/master-thesis/XML-Version-Management.pdf
I also found another one but haven't had a chance to read it
http://citeseer.ist.psu.edu/chien00version.html
Anyways, I've always thought it would be cool to extend darcs' Theory
of Patches (http://www.darcs.net/manual/node8.html) to work with trees
of data. Ideally it would enable node-sensitive diffs.
Since lisp code is naturally in the form of a tree, it would enable
you almost immediately to generate reports from a repo of code like
"user X has modified the definition of class NAME and function FOO"
and with some work things like "user X has added a :INITARG option to
the slot BAR in the definition of class NAME and changed the
definition of the function FOO", etc.
As swell as they are, however, CL's extendible syntax and read macros
are, thoroughly prevent the system described above to work with
arbitrary portable code, since sexps have to be READ from a file, and
in doing so lose data from the #+, #-, #. forms in the file (I wonder
if this is one of the things Gregor Kiczales was thinking about when
he talked about the inverse relation between the strength of a
language and the ease of making development environments for it:
http://bc.tech.coop/blog/060709.html).
It would be great to have an orthogonal, extendible "meta common lisp"
language/package that could describe CL code solely for the purpose of
tool/IDE integration (think CSS to XML, but for metadata). So if you
called READ-META you'd get some abstract sexp object tagged with info
about when it's supposed to be EVALed, and under what conditions,
etc., and info about the sexp's "semantic" meaning (is it a part of
the body of an anonymous function or a quoted list that may or may not
be returned by a macro). It would also be a formal way to extend CL's
documentation facilities with out screwing with the standards and make
it easier to extend IDEs to support embedded languages.
For now
Nick
········@gmail.com wrote:
> I read an interesting paper on designing a version management system
> for XML documents
>
> http://www.goshaky.com/publications/master-thesis/XML-Version-Management.pdf
>
> I also found another one but haven't had a chance to read it
>
> http://citeseer.ist.psu.edu/chien00version.html
>
> Anyways, I've always thought it would be cool to extend darcs' Theory
> of Patches (http://www.darcs.net/manual/node8.html) to work with trees
> of data. Ideally it would enable node-sensitive diffs.
>
> Since lisp code is naturally in the form of a tree, it would enable
> you almost immediately to generate reports from a repo of code like
> "user X has modified the definition of class NAME and function FOO"
> and with some work things like "user X has added a :INITARG option to
> the slot BAR in the definition of class NAME and changed the
> definition of the function FOO", etc.
>
> As swell as they are, however, CL's extendible syntax and read macros
> are, thoroughly prevent the system described above to work with
> arbitrary portable code, since sexps have to be READ from a file, and
> in doing so lose data from the #+, #-, #. forms in the file (I wonder
> if this is one of the things Gregor Kiczales was thinking about when
> he talked about the inverse relation between the strength of a
> language and the ease of making development environments for it:
> http://bc.tech.coop/blog/060709.html).
>
> It would be great to have an orthogonal, extendible "meta common lisp"
> language/package that could describe CL code solely for the purpose of
> tool/IDE integration (think CSS to XML, but for metadata). So if you
> called READ-META you'd get some abstract sexp object tagged with info
> about when it's supposed to be EVALed, and under what conditions,
> etc., and info about the sexp's "semantic" meaning (is it a part of
> the body of an anonymous function or a quoted list that may or may not
> be returned by a macro). It would also be a formal way to extend CL's
> documentation facilities with out screwing with the standards and make
> it easier to extend IDEs to support embedded languages.
>
> For now
>
> Nick
Glancing over this last post, I see that I am clearly losing my
control of the English language... My apologies for the (lack of)
grammar and repeated words, I was interrupted several times while
writing it...
<········@gmail.com> wrote:
+---------------
| As swell as they are, however, CL's extendible syntax and read macros
| are, thoroughly prevent the system described above to work with
| arbitrary portable code, since sexps have to be READ from a file,
| and in doing so lose data from the #+, #-, #. forms in the file...
+---------------
Not to mention losing all the comments! :-(
+---------------
| It would be great to have an orthogonal, extendible "meta common lisp"
| language/package that could describe CL code solely for the purpose of
| tool/IDE integration (think CSS to XML, but for metadata). So if you
| called READ-META you'd get some abstract sexp object tagged with info
| about when it's supposed to be EVALed, and under what conditions,
| etc., and info about the sexp's "semantic" meaning (is it a part of
| the body of an anonymous function or a quoted list that may or may not
| be returned by a macro). ...
+---------------
I don't know off-hand of corresponding work on CL, but pretty much
exactly this was done as part of PLT Scheme. Shriram Krishnamurthi
wrote a source-correlating macro-expander called "Zodiac" which was
used in the "MrSpidey" debugger. I don't think Zodiac is maintained
any more [<http://ja.soegaard.net/planet/html/collects/syntax/doc.txt>
suggests not], at least not as a separate package, though some remnants
survive in such routines as "drscheme:load-handler:process-text/zodiac".
<http://download.plt-scheme.org/doc/103p1/html/tools/node107.htm>
contains the "Zodiac Reference" documentation for the (ancient)
version 103p1 MzScheme that may be helpful, especially the
"Motivation" section.
The formal writeups were:
Krishnamurthi, S. "Zodiac: A framework for
building interactive programming tools",
Technical Report TR96-262,
Rice University, 1996.
Krishnamurthi, S. "Zodiac: A programming environment builder",
Technical Report TR96-259,
Rice University, 1996.
but I can't seem to find an on-line copy. [There is some mention in
<http://cs.brown.edu/people/sk/Publications/Papers/Published/ffkwf-mrspidey/>,
but reference #18 there just points back to Rice TR96-259.]
-Rob
-----
Rob Warnock <····@rpw3.org>
627 26th Avenue <URL:http://rpw3.org/>
San Mateo, CA 94403 (650)572-2607
Rob Warnock wrote:
> <········@gmail.com> wrote:
> +---------------
> | As swell as they are, however, CL's extendible syntax and read macros
> | are, thoroughly prevent the system described above to work with
> | arbitrary portable code, since sexps have to be READ from a file,
> | and in doing so lose data from the #+, #-, #. forms in the file...
> +---------------
>
> Not to mention losing all the comments! :-(
>
> +---------------
> | It would be great to have an orthogonal, extendible "meta common lisp"
> | language/package that could describe CL code solely for the purpose of
> | tool/IDE integration (think CSS to XML, but for metadata). So if you
> | called READ-META you'd get some abstract sexp object tagged with info
> | about when it's supposed to be EVALed, and under what conditions,
> | etc., and info about the sexp's "semantic" meaning (is it a part of
> | the body of an anonymous function or a quoted list that may or may not
> | be returned by a macro). ...
> +---------------
>
> I don't know off-hand of corresponding work on CL, but pretty much
> exactly this was done as part of PLT Scheme. Shriram Krishnamurthi
> wrote a source-correlating macro-expander called "Zodiac" which was
> used in the "MrSpidey" debugger. I don't think Zodiac is maintained
> any more [<http://ja.soegaard.net/planet/html/collects/syntax/doc.txt>
> suggests not], at least not as a separate package, though some remnants
> survive in such routines as "drscheme:load-handler:process-text/zodiac".
>
> <http://download.plt-scheme.org/doc/103p1/html/tools/node107.htm>
> contains the "Zodiac Reference" documentation for the (ancient)
> version 103p1 MzScheme that may be helpful, especially the
> "Motivation" section.
>
> The formal writeups were:
>
> Krishnamurthi, S. "Zodiac: A framework for
> building interactive programming tools",
> Technical Report TR96-262,
> Rice University, 1996.
>
> Krishnamurthi, S. "Zodiac: A programming environment builder",
> Technical Report TR96-259,
> Rice University, 1996.
>
> but I can't seem to find an on-line copy. [There is some mention in
> <http://cs.brown.edu/people/sk/Publications/Papers/Published/ffkwf-mrspidey/>,
> but reference #18 there just points back to Rice TR96-259.]
>
I knew I should have used PLT when I was giving Scheme a run... I
tried MIT scheme w/ xscheme.el because of SICP, which might have been
a mistake... I've heard great things about MzScheme...
Thanks for the links
Nick
>
> -Rob
>
> -----
> Rob Warnock <····@rpw3.org>
> 627 26th Avenue <URL:http://rpw3.org/>
> San Mateo, CA 94403 (650)572-2607
In article <························@z35g2000cwz.googlegroups.com>,
········@gmail.com wrote:
> I read an interesting paper on designing a version management system
> for XML documents
>
> http://www.goshaky.com/publications/master-thesis/XML-Version-Management.p
> df
>
> I also found another one but haven't had a chance to read it
>
> http://citeseer.ist.psu.edu/chien00version.html
>
> Anyways, I've always thought it would be cool to extend darcs' Theory
> of Patches (http://www.darcs.net/manual/node8.html) to work with trees
> of data. Ideally it would enable node-sensitive diffs.
>
> Since lisp code is naturally in the form of a tree, it would enable
> you almost immediately to generate reports from a repo of code like
> "user X has modified the definition of class NAME and function FOO"
> and with some work things like "user X has added a :INITARG option to
> the slot BAR in the definition of class NAME and changed the
> definition of the function FOO", etc.
Also check out the patch facility on the Lisp Machine. Instead
trying to reconstruct the patches from the source repository,
the developer makes a patch and describes the purpose.
Various information about the patch will be recorded.
In this (older) movie is a small example of the UI (at the end)
http://cl-http.org:8002/mov/lispm-4.mov .
> As swell as they are, however, CL's extendible syntax and read macros
> are, thoroughly prevent the system described above to work with
> arbitrary portable code, since sexps have to be READ from a file, and
> in doing so lose data from the #+, #-, #. forms in the file (I wonder
> if this is one of the things Gregor Kiczales was thinking about when
> he talked about the inverse relation between the strength of a
> language and the ease of making development environments for it:
> http://bc.tech.coop/blog/060709.html).
>
> It would be great to have an orthogonal, extendible "meta common lisp"
> language/package that could describe CL code solely for the purpose of
> tool/IDE integration (think CSS to XML, but for metadata). So if you
> called READ-META you'd get some abstract sexp object tagged with info
> about when it's supposed to be EVALed, and under what conditions,
> etc., and info about the sexp's "semantic" meaning (is it a part of
> the body of an anonymous function or a quoted list that may or may not
> be returned by a macro). It would also be a formal way to extend CL's
> documentation facilities with out screwing with the standards and make
> it easier to extend IDEs to support embedded languages.
>
> For now
>
> Nick
>
> Also check out the patch facility on the Lisp Machine. Instead
> trying to reconstruct the patches from the source repository,
> the developer makes a patch and describes the purpose.
> Various information about the patch will be recorded.
>
> In this (older) movie is a small example of the UI (at the end)
> http://cl-http.org:8002/mov/lispm-4.mov .
>
Cool, thanks for the link.
Nick
On Feb 28, 1:02 am, ········@gmail.com wrote:
> I read an interesting paper on designing a version management system
> for XML documents
> [...]
> It would be great to have an orthogonal, extendible "meta common lisp"
> language/package that could describe CL code solely for the purpose of
> tool/IDE integration (think CSS to XML, but for metadata). So if you
> called READ-META you'd get some abstract sexp object tagged with info
> about when it's supposed to be EVALed, and under what conditions,
> etc., and info about the sexp's "semantic" meaning (is it a part of
> the body of an anonymous function or a quoted list that may or may not
> be returned by a macro). It would also be a formal way to extend CL's
> documentation facilities with out screwing with the standards and make
> it easier to extend IDEs to support embedded languages.
I once spent some time thinking about this, having wasted some of my
youth using Xerox Lisp machines which had a largely resident
development environment.
I think it's important to realise just how hard it is. XML has gone
out of its way to restrict the sort of syntactic construct that can
occur, and to make it possible to build a parse tree from a document
(even if you don't know whether that tree would be licensed by the
grammar, in the form of the DTD). It did this because SGML didn't,
and allowed all sorts of things which the parser needed to be told
what they meant before it could build the parse tree (omissable tags
are the most well-known, but there are other, far worse, horrors
lurking in SGML).
Now look at CL. It's trivially obvious that the CL reader is Turing
equivalent. That might be just some stupid academic point (`these
cases never occur') but I think it's not: a significant fraction of CL
programs actually do make use of the reader in interesting ways. A
good example would be infix maths, but there are plenty of other
things. Even within the standard syntax there are #+ and #- which
have quite exciting implications (SEdit, the InterLisp structure
editor, used to make a real mess of them, I remember).
I'm not saying that this is all doomed. Well, actually, I am saying
that. However just because it's all doomed doesn't mean that an
interesting subset isn't soluble. Personally I think that it probably
is not worth the candle: it would be better to spend time on a support
environment that, based on conventional diffs, could heuristicate
language-level changes. I personally have found that using emacs /
ediff together with a SCM's line-based diffs (p4 in my case, but I
also have had success with CVS and I'm sure others are the same) is
more than adequate.
--tim
In article <························@v33g2000cwv.googlegroups.com>,
"Tim Bradshaw" <··········@tfeb.org> wrote:
> On Feb 28, 1:02 am, ········@gmail.com wrote:
> > I read an interesting paper on designing a version management system
> > for XML documents
> > [...]
> > It would be great to have an orthogonal, extendible "meta common lisp"
> > language/package that could describe CL code solely for the purpose of
> > tool/IDE integration (think CSS to XML, but for metadata). So if you
> > called READ-META you'd get some abstract sexp object tagged with info
> > about when it's supposed to be EVALed, and under what conditions,
> > etc., and info about the sexp's "semantic" meaning (is it a part of
> > the body of an anonymous function or a quoted list that may or may not
> > be returned by a macro). It would also be a formal way to extend CL's
> > documentation facilities with out screwing with the standards and make
> > it easier to extend IDEs to support embedded languages.
>
> I once spent some time thinking about this, having wasted some of my
> youth using Xerox Lisp machines which had a largely resident
> development environment.
>
> I think it's important to realise just how hard it is. XML has gone
> out of its way to restrict the sort of syntactic construct that can
> occur, and to make it possible to build a parse tree from a document
> (even if you don't know whether that tree would be licensed by the
> grammar, in the form of the DTD). It did this because SGML didn't,
> and allowed all sorts of things which the parser needed to be told
> what they meant before it could build the parse tree (omissable tags
> are the most well-known, but there are other, far worse, horrors
> lurking in SGML).
>
> Now look at CL. It's trivially obvious that the CL reader is Turing
> equivalent. That might be just some stupid academic point (`these
> cases never occur') but I think it's not: a significant fraction of CL
> programs actually do make use of the reader in interesting ways. A
> good example would be infix maths, but there are plenty of other
> things. Even within the standard syntax there are #+ and #- which
> have quite exciting implications (SEdit, the InterLisp structure
> editor, used to make a real mess of them, I remember).
>
> I'm not saying that this is all doomed. Well, actually, I am saying
> that. However just because it's all doomed doesn't mean that an
> interesting subset isn't soluble. Personally I think that it probably
> is not worth the candle: it would be better to spend time on a support
> environment that, based on conventional diffs, could heuristicate
> language-level changes. I personally have found that using emacs /
> ediff together with a SCM's line-based diffs (p4 in my case, but I
> also have had success with CVS and I'm sure others are the same) is
> more than adequate.
>
> --tim
A typical application is the text editor which one uses
to edit Common Lisp code. For a better Lisp editor one
already needs lots of special support and Common Lisp
can easily confuse the editor.
If one edits a Lisp file with an (text) editor, you have
several choices:
a) apply no special knowledge about Lisp (Notepad)
b) let the user always specify what he wants to do
with some text (like interpret in as a Lisp form
and indent it) without having the editor guessing things
c) let the editor try to guess things based on lots of
domain knowledge and user customization (Emacs)
d) let the editor try to guess things based on lots of
domain knowledge and user customization and
connection to a Lisp system which has the
source that you edit loaded/compiled
If you want the latter, you need to do some clever things
to reconstruct the various Lisp elements from the source.
One may want for example:
* Identify the toplevel constructs in the file and their type.
* Identify comments.
* Identify macros and their arglists for indenting.
(if a Lisp system has the macros loaded, you can
also query the Lisp system for the arglists).
* Identify the package(s) that are used in certain code sections.
* Indent the Lisp constructs as good as possible.
* Color code the various Lisp elements in the source.
* Provide buffer overviews and cross references.
* Mouse sensitive Lisp elements in the text.
* Reconstruct the text as virtual Lisp structure (for
navigation, ...).
* Locate code for the user.
* Apply code transformations.
For all that the text editor already needs to have a good
amount of Lisp knowledge. And this knowledge needs to
be extensible by the programmer.
I think it is also good style for usual Lisp programming
not to use these features to change the reader or
to use too many special reader functionality. If necessary
they should be restricted to certain files in a larger
system. Especially ugly is the maintenance of code
that should be usable in several uncompatible
Common Lisp dialects (Franz' 'modern' mode or say CLtL1).
A programming language that does not have the customization
features of Common Lisp can have easier support
from the development environment. A typical example
is InterLisp-D (which you mentioned). Another example
was Apple's Dylan with its database and browser based
IDE. Smalltalk 80.
From: John Thingstad
Subject: Re: sexp-aware theory of patches and "meta common lisp"
Date:
Message-ID: <op.toi3mvk4pqzri1@pandora.upc.no>
On Thu, 01 Mar 2007 18:11:16 +0100, Rainer Joswig <······@lisp.de> wrote:
>
> For all that the text editor already needs to have a good
> amount of Lisp knowledge. And this knowledge needs to
> be extensible by the programmer.
>
Well I can mention that LispWorks provides some of this particularly with
Edi's LispWorks extensions.
example:
to load cl-ppcre using asdf you type
, l <Enter>cl-p<Tab><Enter>
To get help on a lisp function type <F5> over the symbol.
When finishing a name the arguments of that functions appear in the
mini-buffer. (SLIME also provide some of this..)
What I would want to extend it with is:
<F5> (or perhaps F1) works for all lisp functions
including the ones you define.
For each package generate a HTML document.
You could extend Edi's document-generator to perform this.
It scans a package and extracts global symbols.
If it also extracts arguments and the doc text we would be getting
somewhere.
A more customizable output format would be preferable.
I suggest Huchentoot and a ActionScript like layer on top.
Now store all the information centrally and let the server serve it.
Also provide a top node, hierarchical tree structure and search facilities.
(sort of like info nodes in HTML)
This would go some way as to make custom libraries as accessible as
public ones.
Well just one of those thought in the late night yesterday.
--
Using Opera's revolutionary e-mail client: http://www.opera.com/mail/
From: Lars Brinkhoff
Subject: Re: sexp-aware theory of patches and "meta common lisp"
Date:
Message-ID: <85k5y09ite.fsf@junk.nocrew.org>
········@gmail.com writes:
> CL's extendible syntax and read macros are, thoroughly prevent the
> system described above to work with arbitrary portable code, since
> sexps have to be READ from a file, and in doing so lose data from
> the #+, #-, #. forms in the file
I have made a prototype of a CL reader that will read sexps and also
return information about the exact string that was used to read every
sexp.
Lars Brinkhoff wrote:
> ········@gmail.com writes:
> > CL's extendible syntax and read macros are, thoroughly prevent the
> > system described above to work with arbitrary portable code, since
> > sexps have to be READ from a file, and in doing so lose data from
> > the #+, #-, #. forms in the file
>
> I have made a prototype of a CL reader that will read sexps and also
> return information about the exact string that was used to read every
> sexp.
Am I a communist because I think the Next Big Lisp should move away
from source as text in files? At the least in a form that no data is
lost between file and sexp if not all the way to towards something
like Squeak (check out http://wiki.squeak.org/squeak/1287 for an
example of a Squeak vcs)...
Originally Lisp had a "human readable" syntax (http://en.wikipedia.org/
wiki/M-expression) but this was abandoned in favor of the simple,
machine interoperable sexps... Yet we're still at the mercy of syntax
as is standardized to hide info (comments, #., #-, etc) in arrays of
characters (files)...
Nick
From: Ken Tilton
Subject: Re: sexp-aware theory of patches and "meta common lisp"
Date:
Message-ID: <604Gh.2334$rM2.491@newsfe12.lga>
········@gmail.com wrote:
> Lars Brinkhoff wrote:
>
>>········@gmail.com writes:
>>
>>>CL's extendible syntax and read macros are, thoroughly prevent the
>>>system described above to work with arbitrary portable code, since
>>>sexps have to be READ from a file, and in doing so lose data from
>>>the #+, #-, #. forms in the file
>>
>>I have made a prototype of a CL reader that will read sexps and also
>>return information about the exact string that was used to read every
>>sexp.
>
>
> Am I a communist because I think the Next Big Lisp should move away
> from source as text in files?
Jeez, try to keep up, will you? You are now an "al Qaeda terrorist".
And text rocks. It is not a bug, it is a feature. Smalltalk IDEs are
unworkable. Get out of my way! I am coding here!
> At the least in a form that no data is
> lost between file and sexp if not all the way to towards something
> like Squeak (check out http://wiki.squeak.org/squeak/1287 for an
> example of a Squeak vcs)...
>
> Originally Lisp had a "human readable" syntax (http://en.wikipedia.org/
> wiki/M-expression) but this was abandoned in favor of the simple,
> machine interoperable sexps...
<cough> Checking your text source for "abandoned" we find:
"The project of defining M-expressions precisely and compiling them or
at least translating them into S-expressions was neither finalized nor
explicitly abandoned. It just receded into the indefinite future,..."
Gosh, what happened?:
"....and a new generation of programmers appeared who preferred internal
notation to any FORTRAN-like or ALGOL-like notation that could be devised."
McCarthy's mistake was thinking some gene had flipped and a bizarre new
breed of programmer had spontaneously evolved at the exact moment they
rushed out the door that whacky s-exp syntax.
> Yet we're still at the mercy of syntax
> as is standardized to hide info (comments, #., #-, etc) in arrays of
> characters (files)...
Welcome back ProGraph! I just hope another gene has flipped.
:)
kt
--
Well, I've wrestled with reality for 35 years, Doctor, and
I'm happy to state I finally won out over it.
-- Elwood P. Dowd
In this world, you must be oh so smart or oh so pleasant.
-- Elwood's Mom
From: Vassil Nikolov
Subject: Re: sexp-aware theory of patches and "meta common lisp"
Date:
Message-ID: <yy8vtzx2y84p.fsf@eskimo.com>
On 2 Mar 2007 15:36:50 -0800, ········@gmail.com said:
| ...
| Originally Lisp had a "human readable" syntax (http://en.wikipedia.org/
| wiki/M-expression) but this was abandoned in favor of the simple,
| machine interoperable sexps...
In my opinion, the difference between M-expressions and S-expressions
is not between human-readable and machine-interoperable, since both
the language of M-expressions and that of S-expressions are formal
languages---the difference is that between an algorithmic language and
a programming language.
By the way, Allen's _Anatomy of Lisp_ (an excellent book!) offers a
rich perspective on (among other things) the relationship and
interplay between M-expressions and S-expressions. It is interesting
to compare that book to _Structure and Interpretation of Computer
Programs_: both cover similar ground (not the same, though), but in
the latter S-expressions have completely taken the field.
---Vassil.
--
mind mate, n.
One of two persons mentally compatible with each other (cf. soul mate).
In article <·······················@p10g2000cwp.googlegroups.com>,
········@gmail.com wrote:
> Lars Brinkhoff wrote:
> > ········@gmail.com writes:
> > > CL's extendible syntax and read macros are, thoroughly prevent the
> > > system described above to work with arbitrary portable code, since
> > > sexps have to be READ from a file, and in doing so lose data from
> > > the #+, #-, #. forms in the file
> >
> > I have made a prototype of a CL reader that will read sexps and also
> > return information about the exact string that was used to read every
> > sexp.
>
> Am I a communist because I think the Next Big Lisp should move away
> from source as text in files? At the least in a form that no data is
> lost between file and sexp if not all the way to towards something
> like Squeak (check out http://wiki.squeak.org/squeak/1287 for an
> example of a Squeak vcs)...
InterLisp-D did all that. The docs are online to read
about that. See bitsavers.
>
> Originally Lisp had a "human readable" syntax (http://en.wikipedia.org/
> wiki/M-expression) but this was abandoned in favor of the simple,
> machine interoperable sexps... Yet we're still at the mercy of syntax
> as is standardized to hide info (comments, #., #-, etc) in arrays of
> characters (files)...
>
> Nick
On 2007-03-02 23:36:50 +0000, ········@gmail.com said:
> Am I a communist because I think the Next Big Lisp should move away
> from source as text in files? At the least in a form that no data is
> lost between file and sexp if not all the way to towards something
> like Squeak (check out http://wiki.squeak.org/squeak/1287 for an
> example of a Squeak vcs)...
This was tried a long time ago with InterLisp D. Though that system
was enormously exciting to use, it sucked in all sorts of ways, some of
which were related to the keeping-everything-as-structure-in-memory
thing (more of them were related to the grossly deficient hardware
which was all you could get unless you were at PARC, and the general
flakiness of the system).
And that was in the 70s and 80s. To support such a thing now you'd
have to recreate all the tools that you can now just use for text-based
formats (or alternatively go back and live in a cave without any of
these tools). And those tools would work only for you, not for anyone
else.
I'm aware that various Smalltalks do some of this, but I think
Smalltalk has *always* been a resident environment, so they've
presumably had a long time to develop these tools (and I bet they still
only work for Smalltalk, and often only for a single implementation of
it).
Finally, if you want the no-data-is-lost thing you have to deal with
situations like:
#+(and MY-OBSCURE-LISP MY-PROPRIETARY-OTHER-THING)
(define-thing-which-only-exists-here ...)
--tim
From: Holger Schauer
Subject: Re: sexp-aware theory of patches and "meta common lisp"
Date:
Message-ID: <yxzk5xwtyxj.fsf@gmx.de>
On 4931 September 1993, Tim Bradshaw wrote:
> I'm aware that various Smalltalks do some of this, but I think
> Smalltalk has *always* been a resident environment, so they've
> presumably had a long time to develop these tools (and I bet they
> still only work for Smalltalk, and often only for a single
> implementation of it).
I've never done any serious Smalltalk development, but judging from
the mess some of my former colleagues did, I'm quite sure that's not
really the issue. Far worse is the problem that once you start living
in image based development, there's usually no reason to ensure you
can actually build what you currently have -- you just deploy the
image and everything's fine. Of course, it's not if you ever to have
to abandon your image because you need to build your system on a new
virtual machine or for some other reason (by pure coincidence, our
images were working although the virtual machine had gone from v3 to
v7, but there was no way to move the system from Sun/Sparc to
Linux/x86 without rebuilding and that wasn't possible without a lot of
time/work from one of our Smalltalk gurus). No really, I'm really
happy with files, thanks a lot.
Holger
--
--- http://hillview.bugwriter.net/ ---
Fachbegriffe der Informatik - Einfach erkl�rt
753: Nur der Inhalt z�hlt!
Ich war zu bl�d, meinen HTML-Editor richtig zu bedienen.