[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: dylan scientific/multimedia
- To: John Lewis <zilla@CCRL.NJ.NEC.COM>, Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU
- Subject: Re: dylan scientific/multimedia
- From: email@example.com (Andrew LM Shalit)
- Date: Thu, 8 Oct 1992 18:49:22 -0500
- Cc: info-dylan@CAMBRIDGE.APPLE.COM
- Full-name: Andrew L. M. Shalit
At 4:14 PM 10/7/92 -0400, Rob_MacLachlan@LISP-PMAX1.SLISP.CS.CMU.EDU wrote:
>What would be necessary in Dylan to get as good numeric performance as is
>available in some Common Lisp implementations?
> -- Specialized array element types are definitely necessary.
> -- Type declarations for module (global) variables would be very useful.
> This is really only necessary for mutable variables.
> -- There also needs to be either a predefined class variable for each
> specialized array element type, or a general class generator which
> produces the specialized class when presented with an element type.
> These classes would be used in slot and variable type declarations.
We're considering all of these, as well as a system for declaring the
types of return values.
> -- As long as SET! is basically never used on local variables, it will
> *not* be necessary to allow the type of local variable contents to be
> declared. This implies that iterations will always be written using
> BIND-METHODS or equivalent forms of recursion. (Note that the types in
> BIND and method specializers only specify the type of the initial value.)
I think the types specified in BIND and METHOD specializers should also
restrict the subsequent values that can be stored in the variables. This
would simplify the language and improve efficiency.
> -- Efficient small-integer (i.e. array index) arithmetic must be possible.
> The difficulty of proving that small-integer arithmetic doesn't result
> in overlow is one of the major causes of inefficency in Common Lisp
> programs (even non-numeric ones.)
There are other messages on this, so I won't answer here.
>Overall, it seems that Dylan is fundamentally any worse than Common Lisp
>for numeric efficiency...
[Assuming the word 'not' is missing]
Dylan encourages programmers to include lots of type information. It's
a very natural thing to do when writing Dylan programs. In Common Lisp,
declarations have to be tacked on. Many programmers just don't bother
with them. To me, this places Dylan at a great advantage over Common Lisp.