a proposal: an embedded language library 
Author Message
 a proposal: an embedded language library

An illustrious victim of the increased efficiency of Dylan (with respect
to Lisp) is the missing eval. So a nice amount of work is required to
add an embedded [user] language to one's applications.

In many cases an interpreter would be more than enough, but designing
a good interpreter is neither easy not fast (at least for me :-)).

Since many of us are not language designers, it would be great to have
(sooner or later) a library containing a simple general-purpose
interpreter, to be tailored to the application's need.

It would be greater still (and elegant too) if the interpreted language
were a subset of Dylan itself. Something like Mindy, for example, without
most of the libraries.
(with the ability to interface with the underlying "true Dylan" layer, of
course, at least through custom extension/specialization).

It would allow the design of two-tiered applications, with an efficient
Dylan core and, payed for only if needed, a less efficient but more
dynamic "mini-Dylan" interpreted user language.

  Enrico

(to reply, please delete "nospam." from my address)



Wed, 30 Jun 1999 03:00:00 GMT  
 a proposal: an embedded language library

Quote:

> An illustrious victim of the increased efficiency of Dylan (with respect
> to Lisp) is the missing eval. So a nice amount of work is required to
> add an embedded [user] language to one's applications.

> In many cases an interpreter would be more than enough, but designing
> a good interpreter is neither easy not fast (at least for me :-)).

> Since many of us are not language designers, it would be great to have
> (sooner or later) a library containing a simple general-purpose
> interpreter, to be tailored to the application's need.

Yes, this kind of library has always been planned -- maybe a couple of
them, providing various levels of completeness and cost. However, it
is not anyone's highest priority right now.

-- Scott



Thu, 01 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library


    Date: Mon, 13 Jan 97 16:45:53 GMT

    In-Reply-To: Enrico Colombini's message of Sat, 11 Jan 1997 11:45:23 +0200

    > An illustrious victim of the increased efficiency of Dylan (with respect
    > to Lisp) is the missing eval.

    How do you know Dylan is more efficient than Lisp?  And which Lisp
    anyway?  Franz Lisp?  Common Lisp?  Scheme?

    Let me put it more concretely: what, if anything, stops the Common
    Lisp implementors at Harlequin from making Harlequin's Common Lisp
    as efficient as Harlequin's Dylan, and which of these problems could
    not be overcome in _any_ Common Lisp implementation?

Common Lisp lacks the ability to declare generic functions to have
sealed domains.  This makes doing reliable compile-time dispatch
analysis very hard, if not impossible.  Note that compile-time
dispatch enables better inlining analysis, which can have a profound
impact on both code performance and size.

Also, Common Lisp requires its entire runtime library, which is much
bigger than Dylan's.  This means you have to analyze what to throw
out.  In Dylan, you get what you explicitly ask for, which means that
Dylan implementors can spend their time on other sorts of optimizations.



Fri, 02 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library

In-Reply-To: Enrico Colombini's message of Sat, 11 Jan 1997 11:45:23 +0200

Quote:
> An illustrious victim of the increased efficiency of Dylan (with respect
> to Lisp) is the missing eval.

How do you know Dylan is more efficient than Lisp?  And which Lisp
anyway?  Franz Lisp?  Common Lisp?  Scheme?

Let me put it more concretely: what, if anything, stops the Common
Lisp implementors at Harlequin from making Harlequin's Common Lisp
as efficient as Harlequin's Dylan, and which of these problems could
not be overcome in _any_ Common Lisp implementation?

-- jd



Fri, 02 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library

Quote:

>From:       Scott McKay
>Sent:       Monday, January 13, 1997 8:55 AM
>To:         Jeff Dalton

>Subject:    Re: a proposal: an embedded language library

>Also, Common Lisp requires its entire runtime library, which is much
>bigger than Dylan's.  This means you have to analyze what to throw
>out.  In Dylan, you get what you explicitly ask for, which means that
>Dylan implementors can spend their time on other sorts of optimizations.

However, there's no insurmountable implementation barrier to doing so in
Common Lisp - witness the various tree-shakers and "application
generators" for various Lisps. Adding the capability to NOT require the
entire runtime library may not be ANSI-approved CL, but it's technically
feasible, and I wish that more Lisp implementors would think about it
seriously. It would mean a great deal more commercial development with
Lisp would be possible.

Adam



Fri, 02 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library


Quote:

>    Let me put it more concretely: what, if anything, stops the Common
>    Lisp implementors at Harlequin from making Harlequin's Common Lisp
>    as efficient as Harlequin's Dylan, and which of these problems could
>    not be overcome in _any_ Common Lisp implementation?

>Common Lisp lacks the ability to declare generic functions to have
>sealed domains.  This makes doing reliable compile-time dispatch
>analysis very hard, if not impossible.  Note that compile-time
>dispatch enables better inlining analysis, which can have a profound
>impact on both code performance and size.

>Also, Common Lisp requires its entire runtime library, which is much
>bigger than Dylan's.  This means you have to analyze what to throw
>out.  In Dylan, you get what you explicitly ask for, which means that
>Dylan implementors can spend their time on other sorts of optimizations.

Common Lisp also lacks primary classes, which which makes it likely that
every slot access has to pay the cost of multiple inheritance, even when
it's not used.  That, or you can give up some safety.

And, it's not just that Common Lisp has a bigger set of libraries which
aren't segregated, but the nature of the libraries: they allow things
like interning, compiling, symbol-funcalling, read-time-evaling, etc.
To get around this you either need the mythical SSC (which, as far as I
know, no one has ever written), or you need to give up safety, or you
need to you ad hoc, non-portable subsets of Common Lisp defined by
individual vendors.

But Jeff, you must have heard this all before.  I'm curious what the
real issue is here.  Do you not believe that these features enable
additional optimizations?

--
Andrew Shalit                              Time is a meadow, not a highway.
http://www.shore.net/~alms                                    -Tom Robbins



Sat, 03 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library

In article <comp.lang.dylan.c=US%a=_%p=Brightware

Quote:
> However, there's no insurmountable implementation barrier to doing so in
> Common Lisp - witness the various tree-shakers and "application
> generators" for various Lisps. Adding the capability to NOT require the
> entire runtime library may not be ANSI-approved CL, but it's technically
> feasible, and I wish that more Lisp implementors would think about it
> seriously. It would mean a great deal more commercial development with
> Lisp would be possible.

Alternately, move the runtime into a shared library (for Unix)
or DLL (for Windows). I agree about a smaller runtime overhead
making more commercial development in Lisp possible, but with
so much code being used in components like DLLs, a shared runtime
might enough. It would certainly beat static linking.

Imagine a situation where more than one program is written in
Lisp, and they all share the same runtime code. Static linking
needlessly duplicated the same code, wasting space. This may
be a trivial issue for some of us, but disk space is finite,
and there are people who worry about this.

Both Dylan and Java make it easy to address this issue. C++ has
done it for years. If you used the p-system, then Pascal could
do it, perhaps even fortran and Basic (I can't remember). PL/I
could use it, if you had the right OS. Even VB can do it.

I find it hard to believe that it can't be done with Lisp. Perhaps
it's just something that Lisp people haven't demanded, so the vendors
and implementors haven't given it a high priority? I dunno.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
  Martin Rodgers Y Developer for Enrapture Limited Y London, UK
       Please remove the "nospam" if you want to email me.



Sat, 03 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library


Quote:

> Alternately, move the runtime into a shared library (for Unix)
> or DLL (for Windows). I agree about a smaller runtime overhead
> making more commercial development in Lisp possible, but with
> so much code being used in components like DLLs, a shared runtime
> might enough. It would certainly beat static linking.

WCL does it. ACL does it. MCL does it.

Quote:
> I find it hard to believe that it can't be done with Lisp. Perhaps
> it's just something that Lisp people haven't demanded, so the vendors
> and implementors haven't given it a high priority? I dunno.

Some already use it.

Rainer Joswig



Sun, 04 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library

Quote:

> Alternately, move the runtime into a shared library (for Unix)
> or DLL (for Windows).

> I find it hard to believe that it can't be done with Lisp. Perhaps
> it's just something that Lisp people haven't demanded, so the vendors
> and implementors haven't given it a high priority? I dunno.

Well, speaking for CMU CL, we were developing on the Mach version of
Unix, and it gives you the effect of shared libraries (actually
something better than shared libraries) for free.  If you run N
versions of a program, each new page starts out in copy-on-write
status, so any pages that you don't write into are automatically
shared.  We did some work to pack the pure stuff together so that we
wouldn't have zillions of pages copies because one word in each got
written.

Naturally we assumed that this was such a good idea that all Unices
soon would have it.  Naturally we were wrong (as we were about virtual
memory being ubiquitous by 1985 at the latest).

We never got around to porting CMU CL to windows, so we never faced
the question of DLLs.  We were thinking seriously about a windows port
and a better GC when DAPRA pulled the plug on CMU CL.

On the question of why CL was designed in such a monolithic way,
instead of as N shared libraries, here is my view of that: A lot of
the CL designers were veterans of Maclisp.  Maclisp, in its later
days, had many small "autoload" libraries that implemented essential
things.  If you ran a Maclisp environmnet of any complexity, it was
broken half the time.  The elves would come in the night and "fix"
some small item in one of the autoload libraries, and when you fired
up the next morning you would discover that you were autoloading
incompatible versions of things that had never been tested together.
So in designing CL we over-reacted and said, "Let's just pack it all
into one big released system that we have some hope of keeping in a
self-consistent state."  In a world where proper virtual memory can be
counted on to exist everywhere, I still think this was a pretty good
move: the parts of the CL runtime that you are not using sit
harmlessly on disk, and do no more harm than a library that you have
around but haven't loaded for this application.  Of course, you also
need a tree-shaker of some kind for delivery of applications to very
small machines that want the minimal amount of stuff on their disk.

Dylan has taken a different approach: aggressively chop things up into
small libraries, and assume that a sophisticated environment will
ensure that you have consistent versions of everything.  The biggest
problem with this approach so far is that there has a tendency to
focus on standardizing the core languagng vendors but not the
essential libraries.  CMU and Harlequin are now working together on
standardizing the most important libraries, but for various reasons
progress has been slow.

-- Scott



Sun, 04 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library

In-Reply-To: Andrew LM Shalit's message of Mon, 13 Jan 1997 21:08:15 -0500

Quote:

> >    Let me put it more concretely: what, if anything, stops the Common
> >    Lisp implementors at Harlequin from making Harlequin's Common Lisp
> >    as efficient as Harlequin's Dylan, and which of these problems could
> >    not be overcome in _any_ Common Lisp implementation?

> >Common Lisp lacks the ability to declare generic functions to have
> >sealed domains.

But my question was about Common Lisp _implementations_, not about
Common Lisp the language.  What, if anything, stops a CL implementation
from providing "the ability to declare generic functions to have
sealed domains" or from getting similar benefits in some other way?

For instance, in AKCL I can "freeze" a defstruct, which says that I
will not define subclasses of it.  (Something like that.)  This isn't
the same as declaring that a generic function has a sealed domain,
of course.  But it's an example of how an implementation can provide
a declarative efficiency feature that is not provided by the language.
Imagine other stuff like that.  Imagine a compiler that analyses
entire programs.  There's a great deal that implementations might
do, and there are some pretty clever Lisp implementations out there,
e.g. Stalin for Scheme.

This implementation-specific stuff can sound like it will be an
incredible mess -- but it needn't be.  I think a fairly small number
of well-chosen declarations, plus various compilation and other
implementation techniques that have already been explored for Common
Lisp or other languages, would do the trick, or at least come pretty
close.

Sure, Common Lisp is a tough case.  I'm not saying it would be easy.
But neither is writing a highly optimizing compiler for Dylan, and
in some ways Dylan is a larger language than Common Lisp.  For
instance, it needs a more complex parser, macros are much more
complex, and it has modules.

And of course it would be better if the CL declarations, etc, were
part of the language (or were standardized in some other way) so
they would be available in the same form in all implementations.
But Dylan has problems like that too, or at least did, since
there was no agreement on the names of the efficient integer
types.

Quote:
> >This makes doing reliable compile-time dispatch
> >analysis very hard, if not impossible.  Note that compile-time
> >dispatch enables better inlining analysis, which can have a profound
> >impact on both code performance and size.

A compiler can compile some code that assumes certain things are true,
plus a way of avoiding that code when the assumptions turn out to be
false, which is just one possibility.

Quote:
> >Also, Common Lisp requires its entire runtime library, which is much
> >bigger than Dylan's.

I'm not sure what you have in mind here.  A CL (application) executable
needn't contain parts of the library it can never use.  Even "dumb"
techniques, such as autoloading, can accomplish a fair amount.

Quote:
> >This means you have to analyze what to throw out.  

Well, this is kind of picky, but no, not if you start with nothing
being "in".  Then the analysis is one of what to include.  Now imagine
an implementation-specific declaration that says "I won't call
anything that (via eval, apply, etc) that isn't explicitly called
or declared to be callable."

Quote:
> >In Dylan, you get what you explicitly ask for, which means that
> >Dylan implementors can spend their time on other sorts of optimizations.

You're right that it may well be _easier_ to make Dylan efficient, and
ok, maybe Harelquin's CL implementors don't have time, though, really,
since they had an earlier start, ...

Quote:
> Common Lisp also lacks primary classes, which which makes it likely that
> every slot access has to pay the cost of multiple inheritance, even when
> it's not used.  That, or you can give up some safety.

There's plenty that implementations can do about that.  For instance,
imagine that the implementation regards some classes as "mixins" and
others has being in the main line of (single) inheritance.  (I think an
implementation can figure this out in a fairly reasonable way, in many
cases, but if not, imagine some declarations.)  Slots from the "main line"
classes would be treated in the single-inheritance way.

Quote:
> And, it's not just that Common Lisp has a bigger set of libraries which
> aren't segregated, but the nature of the libraries: they allow things
> like interning, compiling, symbol-funcalling, read-time-evaling, etc.
> To get around this you either need the mythical SSC (which, as far as I
> know, no one has ever written), or you need to give up safety, or you
> need to you ad hoc, non-portable subsets of Common Lisp defined by
> individual vendors.

What you need is implementation-specific extensions, and implementations
have a bunch of them anyway.  And surprisingly smart compilers have
been written, for a variety of languages.

Quote:
> But Jeff, you must have heard this all before.  I'm curious what the
> real issue is here.  Do you not believe that these features enable
> additional optimizations?

Yes, I have heard it all before.  But, while it's true that various
features of Dylan help the implementation to optimize, I don't think
this has some of the consequences that it's often thought to have,
and I don't like to see prejudices about Lisp (and dynamic languages
generally) being reinforced.  I think it hurts Dylan too.  The lower
the perception of Lisp, the less value being better than Lisp has.

BTW, I find it interesting that some now say Java's great because it
provides small, fast applications (e.g. in a recent edition of PCW in
the UK).  It's almost as if the success of a language makes it be seen
as having the virtues that are thought to be important.  That is,
rather than the virtues leading to success, success leads people
to see the language as having the virtues.  

-- jeff



Sun, 04 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library


Quote:
>In-Reply-To: Andrew LM Shalit's message of Mon, 13 Jan 1997 21:08:15 -0500


>> >    Let me put it more concretely: what, if anything, stops the Common
>> >    Lisp implementors at Harlequin from making Harlequin's Common Lisp
>> >    as efficient as Harlequin's Dylan, and which of these problems could
>> >    not be overcome in _any_ Common Lisp implementation?

>> >Common Lisp lacks the ability to declare generic functions to have
>> >sealed domains.

>But my question was about Common Lisp _implementations_, not about
>Common Lisp the language.

OK, if you're talking about Common Lisp implementations rather than
about the standard, than I don't have much argument.  For example,
Bill St. Clair just added primary classes to Macintosh Common Lisp.

On the other hand, I do think (and I hope you'd agree) that there are
real benefits to having this stuff defined in the language.  It makes
the constructs portable; it increases the chances that the behavior is
well-defined rather than ad hoc; in theory it would allow implementors
to share optimization techniques.

As far as Dylan vs. CL arguments, I think that's pretty much a red
herring.  On the one hand, I think Common Lisp is a great language
for a huge variety of uses, so there's no technical reason to denigrate
it.  On the other hand, the mass market has pretty much written it off,
so there's no marketing reason to compare against it.  On the third hand,
I do think that Dylan has made some advances for its intended audience, and
I see no reason to ignore those.

--
Andrew Shalit                              Time is a meadow, not a highway.
http://www.shore.net/~alms                                    -Tom Robbins



Sun, 04 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library


Quote:
>This implementation-specific stuff can sound like it will be an
>incredible mess -- but it needn't be.  I think a fairly small number
>of well-chosen declarations, plus various compilation and other
>implementation techniques that have already been explored for Common
>Lisp or other languages, would do the trick, or at least come pretty
>close.

To make this work you need some mechanism for describing the scope of the
declarations.  If you make a closed world assumption, the sealing
declarations Dylan contains for optimization are unnecessary.  All those
declarations do is enable restricted sets of closed world assumptions, and
libraries are the mechanism for indicating the scope of those declarations.

An example of this is that in Chestnut CL, because runtime class creation
was not permitted, the slot layout for every class was computed at
compile-time using a coloring algorithm so that all slots of a given name
were placed at the same offset.  This made for pretty darn fast inlined
slot-value calls in the common case where the slot name is a constant.

Such a scoping mechanism could be defined for CL.  I haven't spent any time
thinking about what it might look like, but it doesn't seem like it should
be any more difficult than, say, defsystem (sigh!).

A related problem is that the program construction methodology commonly
used in CL is incremental loading of program code and data, with forward
references being common and permitted.  The incremental buildup of generic
functions and class hierarchies is related.  Putting in the sorts of
declarations you are talking about, along with some scoping mechanism as
discussed above, is quite a departure from that model of program building,
being instead a block compilation approach.  While there have been some
efforts along those lines by some CL implementations, from what I've seen,
it not infrequently requires modifications (sometimes significant) to an
existing CL program to make it work under such a system.

A much more serious problem with CL is that it is commonly impossible to
perform compile-time method selection, even with some cognate to Dylan's
sealing declarations.  This is because the CL class precedence list
algorithm is not monotonic.  That problem was the primary rationale for
changing the Dylan class precedence list algorithm.  That one is a bit
tougher to fix as an implementation-specific extension, though an
implementation-specific metaclass with a monotonic cpl algorithm might be
sufficient.

So I would agree that many, perhaps most (or even all, though I wouldn't
want to say that definitively without a good catalog), of the mechanisms
included in Dylan for efficient compilation could be retrofitted onto CL,
at least as implementation-specific extensions.  And given the proclivity
for CL and its ancestors for incorporating good ideas developed in other
languages, I won't be surprised if that happens in this case too.  I'm not
sure that the language that results from applying all these ideas is really
all that close to CL; on the other hand, pre-CLOS CL is quite different
from post-CLOS CL; on the third hand, in some circles it seems to be usual
to refer to the latter language as just "CLOS".



Mon, 05 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library



Quote:
>rather than the virtues leading to success, success leads people
>to see the language as having the virtues.  

Many people have this intuitive assumption that success is due to technical
superiority.  So when they see something is successful, they rationalize
that its qualities must be virtues.

In reality, marketing, timing (being in the right place at the right time),
and pricing seem to have a much more profound influence.  Consider the
success of Wintel versus Macintosh.
--
Barry Margolin
BBN Planet, Cambridge, MA

(BBN customers, please call (800) 632-7638 option 1 for support)



Tue, 06 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library

Quote:


> >rather than the virtues leading to success, success leads people
> >to see the language as having the virtues.  

> Many people have this intuitive assumption that success is due to technical
> superiority.  So when they see something is successful, they rationalize
> that its qualities must be virtues.

But in this case they think it (Java) has certain qualities (Q1) it
does not, rather than thinking the qualities it does have (Q2) are
virtues.

It's true that the Q1 qualities (delivering small, efficient applications)
are seen as virtues.  And that seems to lead some people to think Java
has those (Q1) qualities.

But of course the effect Barmar brough up does happen rather a lot
with Java and the Q2 qualities (which, unlike the Q1 qualities,
are qualities Java does have).

(Of course, Java has the Q1 qualities to some extent.  But so does
everything; and Java has other properties (e.g. garbage collection)
that often function as supposedly fatal flaws when the efficiency is
seen as key.

-- jeff



Tue, 06 Jul 1999 03:00:00 GMT  
 a proposal: an embedded language library



Quote:
> Well, speaking for CMU CL, we were developing on the Mach version of
> Unix, and it gives you the effect of shared libraries (actually
> something better than shared libraries) for free.  If you run N
> versions of a program, each new page starts out in copy-on-write
> status, so any pages that you don't write into are automatically
> shared.  We did some work to pack the pure stuff together so that we
> wouldn't have zillions of pages copies because one word in each got
> written.

Neat. How much heap space does CMU CL require? I'm wondering
about the size of the working set. Would it be possible for
multiple running copies of CMU CL to share parts of the heap?
Is that what you're describing?

Quote:
> Naturally we assumed that this was such a good idea that all Unices
> soon would have it.  Naturally we were wrong (as we were about virtual
> memory being ubiquitous by 1985 at the latest).

It seems like a reasonable assumption, to me. It's just
unfortunate that it was wrong. Does Linux have this feature?

Quote:
> We never got around to porting CMU CL to windows, so we never faced
> the question of DLLs.  We were thinking seriously about a windows port
> and a better GC when DAPRA pulled the plug on CMU CL.

Wow! That would've been _very tasty_! I've been tempted to
get a 2nd machine, running Linux, so that I can use CMU CL
(and a few other things, too). Pehaps someday I will.

Quote:
> On the question of why CL was designed in such a monolithic way,
> instead of as N shared libraries, here is my view of that: A lot of
> the CL designers were veterans of Maclisp.  Maclisp, in its later
> days, had many small "autoload" libraries that implemented essential
> things.  If you ran a Maclisp environmnet of any complexity, it was
> broken half the time.  The elves would come in the night and "fix"
> some small item in one of the autoload libraries, and when you fired
> up the next morning you would discover that you were autoloading
> incompatible versions of things that had never been tested together.

This can happen today, with C++ and DLLs. ;-) I used and
liked Cambridge Lisp, which could load and unload code modules,
at any time whilst running. Very nice, but the elves could've
played havoc with that system, too.

Quote:
> So in designing CL we over-reacted and said, "Let's just pack it all
> into one big released system that we have some hope of keeping in a
> self-consistent state."  In a world where proper virtual memory can be
> counted on to exist everywhere, I still think this was a pretty good
> move: the parts of the CL runtime that you are not using sit
> harmlessly on disk, and do no more harm than a library that you have
> around but haven't loaded for this application.  Of course, you also
> need a tree-shaker of some kind for delivery of applications to very
> small machines that want the minimal amount of stuff on their disk.

Here's a big part of the problem: I doubt that many people
who've never used a tree-shaker understand the concept very
well. The development time overheads could perhaps be seen
as also being runtime overheads. I know that sounds stupid,
but let's fact, there's a lot of stupidity about (see Frank
Zappa's comments on the subject).

Also, most operating systems seem to be designed for running
C/C++ programs very well, without much concern for issues for
other languages. This creates a kind of "tunnel vision", so
that anything unlike C/C++ will suffer, in all kinds of ways.
Some of them are perhaps more social than technical.

The key question seems to me to be, "To what extent are we
prepared to compromise?" Whether we program in C++, Lisp,
Dylan, Java, or whatever, that question should be asked IMHO.
You can define compromise any way you like, of course, but
a stubborn "C++ or death" attitude will survive for an
indefinite period of time.

Dylan seems to me to be a way of making a few reasonable
compromises. Perhaps Dylan ditches a few features that some
Lisp programmers would prefer to keep, in which case they
can stick with Lisp, e.g. CL.

In fact, R4RS often looks to me like a Lisp that has made
that kind of departure. Whatever an implementation adds to
it is just an option for that implementation. Could Dylan
also be such a "basic" core language, on which implementors
can add whatever they like? CL also does this, but the core
is _much_ larger.

Quote:
> Dylan has taken a different approach: aggressively chop things up into
> small libraries, and assume that a sophisticated environment will
> ensure that you have consistent versions of everything.  The biggest
> problem with this approach so far is that there has a tendency to
> focus on standardizing the core languagng vendors but not the
> essential libraries.  CMU and Harlequin are now working together on
> standardizing the most important libraries, but for various reasons
> progress has been slow.

I'm glad that CMU and Harlequin have been working together
on this, even if progress has been slow. I'd expect that!
It can be easy, esp if you want to do it _well_. I'm confident
that it _will_ be done well.

Thanks.
--
<URL:http://www.enrapture.com/cybes/> You can never browse enough
  Martin Rodgers Y Developer for Enrapture Limited Y London, UK
       Please remove the "nospam" if you want to email me.
              "Blow out the candles, HAL." -- Dave



Tue, 06 Jul 1999 03:00:00 GMT  
 
 [ 19 post ]  Go to page: [1] [2]

 Relevant Pages 

1. Unofficial list of Oberon language and library proposals

2. Unofficial list of Oberon language and library extension proposals

3. PD OOP library proposal

4. pep proposal : A date object for the standard library

5. PROPOSAL: fix tabs & spaces in default library

6. PROPOSAL: add isreadable, iswriteable, and isexecutable to library

7. Be Honest about LC_NUMERIC (PEP proposal), was Re: [Python-Dev] LC_NUMERIC and C libraries

8. Language change proposal: make assertions "reusable"

9. Experiment Proposal re Languages

10. Another new language proposal

11. A proposal for #f and '() in the GNU extension language

12. Experiment Proposal re Languages

 

 
Powered by phpBB® Forum Software