[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Dylan rather than CL -- why?
- To: email@example.com
- Subject: Dylan rather than CL -- why?
- From: firstname.lastname@example.org (Rob Farrow)
- Date: Fri, 4 Dec 92 16:40:13 CST
- Cc: email@example.com, firstname.lastname@example.org
- In-reply-to: Stavros Macrakis's message of Fri, 4 Dec 1992 16:25:35 -0500 <9212042125.AA20296@lakatos.osf.org>
>Also, to reply to another point, if you want a standard development
>environment, you can certainly define one without building it into the
>language, just as you can define a standard linear-programming package
>or a standard graphic-interface package (although of course its
>implementation is much more closely linked to the language
>implementation than these examples).
I don't believe that development environment facilities are less
closely related to the language implementation than are
graphic-interface packages. The basic capabilities/hooks for keeping
functions, evaluation stacks, documentation, etc. have to be well
considered by the implementation. This kind of access is essential to
modular design of separable development environments.
The only way to ensure the power is available, is for the developers
of Dylan set forth a standard for implementations which includes the
protocols and conventions necessary for separation of development
environments from the execution module. By placing these consistency
requirements in the hands of language and environment developers, they
will allow the users to use a different environment by simply plugging
in a the new one.