help-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: why are there [v e c t o r s] in Lisp?


From: Random832
Subject: Re: why are there [v e c t o r s] in Lisp?
Date: Sat, 17 Oct 2015 00:40:08 -0400
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.3 (gnu/linux)

"Pascal J. Bourguignon" <pjb@informatimago.com> writes:

> Emanuel Berg <embe8573@student.uu.se> writes:
>> Why the syntax is there at all is to provide fast
>> (faster) access to the vector data type which has
>> other time and space properties than do lists.
>
> ABSOLUTELY NOT.
>
> For example, in C++ you have vectors and lists, 
> but you don't have any literal syntax for them.
>
> You can have fast and slow data structures without having any literal
> syntax for it.
>
>
> Why do you keep confusing the two concepts?

There are certainly situations where having a literal syntax can make
the language fast*er*. For example, in Python, the lack of a literal
syntax for the frozendict and frozenset type means it has to do a
runtime lookup on the name to make sure it hasn't been overridden, and
it means they, despite being immutable objects, can't participate in a
constants pool.

C++ doesn't have any such mechanism to have uncertainty about what type
a class name refers to, but a compiler would have to be very clever
indeed to do the kind of optimized construction for arbitrary classes
that it can do for types such as arrays and POD-structs for which
literals do exist.

Basically, a literal syntax doesn't make a type faster in general, but
for many languages and many real-world implementations it can certainly
make the specific action of constructing an object faster. Having a
literal syntax means that the object can be completely pre-built at
compile time, and for an immutable object it simply copies a pointer,
and for a mutable object (in some cases) it can simply copy a block of
memory. Whereas suppose make-vector were reassigned or advised.




reply via email to

[Prev in Thread] Current Thread [Next in Thread]