Re: is LISP the ultimate prgram language?
On Oct 23, 12:38 am, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Oct 22, 1:44 pm, James Kanze <james.ka...@gmail.com> wrote:
On Oct 22, 6:13 pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Oct 21, 11:47 am, James Kanze <james.ka...@gmail.com> wrote:
On Oct 21, 3:51 pm, Keith H Duggar <dug...@alum.mit.edu> wrote:
On Oct 21, 4:22 am, James Kanze <james.ka...@gmail.com> wrote:
On Oct 20, 8:19 pm, Juha Nieminen <nos...@thanks.invalid> wrote:
If you have, for example, a vector of ints, where each int
is a full-fledged object (in other words, some of the ints
could actually be objects derived from an int), then I
don't think the compiler has any way of optimizing dynamic
binding checks away. It cannot prove that none of the ints
in the array are objects derived from int.
It can, and some do. Obviously, it's harder for the
compiler than optimizing around std::vector, but then,
optimizing around std::vector is harder for the compiler
than optimizing around Fortran style arrays. (C-style
arrays are a problem for the compiler, because they end up
being pointers.)
And what would you replace this C-style array "problem" with?
Make arrays first class types, behaving as any other type.
As in make them std::vector? Why isn't that better done at the
library level as has already been done (in multiple different
ways to meet different needs)?
That's what was decided, but there are still repercusions.
There's no way you can create an std::vector with static
initialization, for example, and the initialization syntax isn't
the same. (The committee is working on the latter.)
Right. However those limitations of course apply to any UDT.
So given that you are arguing for making the built-in array
behave the same as other types I guess that is the price to
pay (at least for now).
Yes. More generally, it's the price we pay for evolution,
rather than revolution (i.e. compatibility with historical
situations). On the other hand, evolution means benefiting from
previous experience, which is a definite advantage; every really
new language I've seen has introduced its own set of problems,
not foreseen from the start for lack of experience with the
idiom.
[...]
The point is that objects in C++ have a specific behavior:
this holds for the basic types, for pointers, for structs,
and in fact, for every object type except arrays. (By
default, anyway. In C++, you can replace that behavior, at
least in part, by overloading operators and defining a copy
and a default constructor.) That default behavior includes
things like copy and assignment.
Would you have any problem if built-in arrays were simply
removed entirely from the core language? Replaced instead by
some equivalent of a raw block new/malloc.
If built-in arrays were simply removed, then they'd have to be
replaced with something with a similar syntax, to avoid breaking
code. What I'd have liked, way back when, would have been that
something like "int a[N];" have semantics similar to "struct
{int a[N];}", i.e. it acted like a real object, which could be
assigned and passed and returned by value, there was no implicit
conversion to int*, and &a had the type int (*)[N]. Or even
int (*)[]; i.e. the size is lost when you take the address. The
point is that you only loose the type information explicitly.
But I think I would prefer int (*)[N] with an implicit
convertion to int (*)[]---functions that want to treat arrays of
variable size can; those that require a specific size can also
insist on that. Ideally, there would be some means of
recovering the initial size from the array, but if we consider
the date when all of this was being specified, I suspect that
that would be asking too much.
Of course, all of this neglects the fact that Kernighan and
Richie were coming from B, where everything is just a machine
word (and "arrays" are a machine word initialized to point to
the first element), where it is all coherent and makes sense.
And that arrays were present from the first; structs (and other
elaborated types which behave as first class objects) came
later.
Do you have a link to a proposal for C++ or examples of
languages that "do it right" and support Stepanov iterator
concepts as C++ does?
The STL has been implemented in Ada. The problems doing so
had nothing to do with arrays; the problems had to do with
the fact that Ada's generics work somewhat differently than
those in C++.
Ok so you would happy if built-in arrays were instead
std::vector? Ie a class with some interface to the size in
this case .size(), .begin(), etc just like the standard
interface that Ada offers to array types (First, Last, etc)?
That would be one solution. There are many. All I really
What other solutions besides something that is effectively
equivalent?
I don't know. To tell the truth, I've not thought about it
much, since practically speaking, nothing's going to change
(except the initialization syntax for class types like vector).
Is removing them entirely a solution?
Only if we consider breaking all existing code a solution:-).
I'm really only complaining about "what should have been", 30 or
more years ago. I don't think there's much we can do about it
today.
insist on is that arrays work like any other type---a struct
doesn't implicitly convert to a pointer to its first element in
just about any context; nor should an array. And of course, as
a side effect, indexation would be indexation, and not pointer
arithmetic.
Doing this does allow carrying the size around, so you could
then add all of the advantages that allows (like efficient
bounds checking). But that's really a second point---important,
but not as primordial as the first.
So then what would the type of "new T[]" and the return type
of malloc(sizeof(T)*N) be? std::vector<T>?
The return type of new T should be T*, for *all* T. Not just
for the cases where T is not an array. That's really part of
what I'm complaining about: it's totally abherant that the
return type of new int and new int[n] be the same. And that you
have to use a different form of delete on them, because the
original type has been lost.
And what about malloc?
Allocating an array using malloc should work exactly like
allocating an int using malloc. E.g.:
typedef int array[10];
int* pi = (int*)malloc( sizeof(int) );
array* pa = (array*)malloc( sizeof(array) );
(Note that the above is actually legal today. It does mean that
to access the array, you need to write (*pa)[i]. I wonder if
this awkwardness didn't also play a role in the early rules,
although it seems natural to me, and it fully parallels what I
do with a dynamically allocated int.)
Should such raw allocation capability be defined in the core
library?
Yes. At least, I think so; I'm not 100% sure. C++ should
continue to be a language that can be used at the lowest level
as well, for e.g. things like kernel code. On the other hand,
if you're defining memory allocation at this level, then you
probably should define other things, like IO, at this level as
well. C (and C++) doesn't, leaving that up to the system (Posix
or Windows I/O, etc.)
--
James Kanze