--- [EMAIL PROTECTED] wrote:

> Steve,
> 
> In order to move from MacLisp to VMLisp and then to pre-common lisp
> and then to common lisp (and now to ansi) one of two possible 
> approaches can be taken. The first approach is to emulate the
> semantics of the original system in the new system. The second 
> approach is to prove that the new system does not require all of
> the old semantics.

Or, third, use the literate re-write and re-design of the system to
ensure that everything fits in common lisp.

> Because it is less error-prone to take the first approach the
> decision was to emulate the prior system semantics where possible.

Less error prone initially, but more difficult to understand and
maintain.

Either way, we need to have sufficient understanding of the system that
we can make intelligent statements about what is and is not required. 
The effort needed for that is sufficiently large that refactoring to
work on common lisp without emulating old behaviors that can be cleanly
expressed in the new ANSI conventions seems (to me) like a logical step
to take.

> In this particular case the concat and strconc functions have vmlisp
> and/or maclisp semantics.
> 
> An example occurs in metalex.lisp where it reads:
> ; Coding note: yes, I know, use string-trim -- but it is broken
> ; in Symbolics Common Lisp for short strings.
> 
> or in parsing.lisp
> "A string contining the remaining chars from readline; needed because
> Symbolics read-line returns embedded newlines in a c-m-Y" or many
> other places such as DEFIOSTREAM, which is non-common lisp.

Eventually, I hope we will reach a point where we won't have the legacy
of all the various non-ANSI lisps cluttering up the code - it doesn't
add anything I can see and increases the overhead for understanding.
 
> I still have the MacLisp and VMLisp documentation but most people do
> not.  The fact that I did not document the semantics of strconc, for
> instance, is a flaw I hope we can all overcome in the present port.

MacLisp and VMLisp are no longer active targets - shouldn't we be
looking first at what "higher level" components of Axiom are supposed
to be doing and then re-think how to do those jobs in light of modern
Lisp environments?

Cheers,
CY


       
____________________________________________________________________________________
Moody friends. Drama queens. Your life? Nope! - their life, your story. Play 
Sims Stories at Yahoo! Games.
http://sims.yahoo.com/  


_______________________________________________
Axiom-developer mailing list
Axiom-developer@nongnu.org
http://lists.nongnu.org/mailman/listinfo/axiom-developer

Reply via email to