pointers

[Pascal J. Bourguignon]

On 2 oct, 12:02, (e-mail address removed) (Pascal J. Bourguignon) wrote:
[snip]

We can implement iterators in lisp or scheme more easily than in C++,
thanks to closures.   Closures are a high level construct that allows
to implement in an abstract way a lot of concepts for which you would
use low level constructs such as  pointers or iterators in C++.
Perhaps that's the reason why a C++ programmer such as Alexander
Stepanov cannot see them in lisp, he's looking too low.

I suspect that it is not a matter of level of point of view. IMHO
Stephanov aims at abstracting algorithms while closures is a
functional/OOP artifact unifying algorithms behind a type.

AFAIK closures are unable to adapt with the semantic of the underlying
data while generic programs can.

Well, actually closures and objects are equivalent (you can implement
closures with objects and you can implement objects with closures).

Iterators are just one kind of objects, they can be implemented
equally well with objects or with closures.

For simple objects (no inheritance or "duck typing", one or few
methods), closures are lighter than classes (syntactically as well as
functionnaly). For more details on how iterators can easily be
implemented as closures, ask on comp.lang.lisp

 

[Keith H Duggar]

That's where we differ. I agree that pointer/address is a useful
concept in Von Neumann processors, but I consider it a low level
device. And neither Von Neumann considered that stored program
machine the ultimate hardware architecture. Too bad he died before he
could finish his Von Neumann "mark 2" machine...

I don't see them as "low level" I see them as "abstract". It
just so happens that fortunately they are both a convenient
bare metal device and a simple and elegant mental device as
an abstraction of sequences. Dismissing them as "low level"
is as distracting as dismissing a cons cell as "low level".

Note one possible miscommunication we are having is that when
you here "pointer" you may be fixated on the C++ built-in raw
pointer solely whereas I'm also thinking of abstract pointers
including both built-in pointers and other implementations of
those properties such as STL iterators.

Doubly-linked lists pose no implementation problem in Lisp. They're
implement as as serious a ADT as you want them to be. The point is
rather that they're not often useful. But when they're needed,
there's no more difficulty to implement then in lisp than in C or C++.

Of course. And Stepanov knows that intimately. Hence his very
next sentence. So your response is indicating that you might have
entirely missed his point and also did not read his other posts.

(Actually, thanks to the garbage collector, it's a lot more easier to
implement circular data structures such as doubly-linked lists in lisp
than in C or C++).

The issue is not implementing them. It is how convenient are they
to use once implemented. Keep in the mind the *forrest* of generic
programming that Stepanov is trying to point out and don't get
distracted by the *trees* of sequences (containers) he brings up
for examples. (In case you didn't notice there was a proverbial
"don't miss the forrest for the trees" point above

We can implement iterators in lisp or scheme more easily than in C++,
thanks to closures. Closures are a high level construct that allows
to implement in an abstract way a lot of concepts for which you would
use low level constructs such as pointers or iterators in C++.
Perhaps that's the reason why a C++ programmer such as Alexander
Stepanov cannot see them in lisp, he's looking too low.

It seems to me you did not bother to read the rest of the Stepanov
posts in that thread as I suggested? If you had you would have known
that 1) he is definitely not a "C++ programmer" 2) he wrote years
worth
of advanced Lisp code trying to implement his ideas 3) he gave his all
to Lisp in its earliest days and since 4) the iterator concepts he is
trying to implement are, contrary to your claim, not easily done in
Lisp nor any other language he tried (he found something like the C
memory model was essential) 5) he did and does consult with world
experts in other languages to try and implement his ideas.

You are intelligent enough to comprehend and think deeply about the
points he makes if you only open your mind (and heart it seems) long
enough to absorb what he is trying to say. If you are still open to
learning things I think you will find it enjoyable. And the rest of
us might benefit from you having something more intelligent to say
on the topic than (paraphrasing) "Stepanov sucks Lisp can do it
easier than C++" and "closures can do anything" and "Stepanov is
just a blind old C++ programmer".

From your recent posts in c.l.c++ I don't know if your mind can
overcome your emotional bias like I truly hope it can. Here are a
couple of posts you should start with. The second has code you can
analyze and improve on:

http://groups.google.com/group/comp.lang.functional/msg/d7394ad977b3a396
http://groups.google.com/group/comp.lang.functional/msg/b02f11bb1e3485d6

But before you bother you have to at least open your mind to even
the *possibility* that beloved Lisp cannot achieve what he is trying
to achieve. Can you emotionally and intellectually do that as any
good scientist must?

KHD

 

[Pascal J. Bourguignon]

It seems to me you did not bother to read the rest of the Stepanov
posts in that thread as I suggested?

You're correct, I postponed it for this evening.

If you had you would have known
that 1) he is definitely not a "C++ programmer" 2) he wrote years
worth
of advanced Lisp code trying to implement his ideas 3) he gave his all
to Lisp in its earliest days and since 4) the iterator concepts he is
trying to implement are, contrary to your claim, not easily done in
Lisp nor any other language he tried (he found something like the C
memory model was essential) 5) he did and does consult with world
experts in other languages to try and implement his ideas.

You are intelligent enough to comprehend and think deeply about the
points he makes if you only open your mind (and heart it seems) long
enough to absorb what he is trying to say. If you are still open to
learning things I think you will find it enjoyable. And the rest of
us might benefit from you having something more intelligent to say
on the topic than (paraphrasing) "Stepanov sucks Lisp can do it
easier than C++" and "closures can do anything" and "Stepanov is
just a blind old C++ programmer".

From your recent posts in c.l.c++ I don't know if your mind can
overcome your emotional bias like I truly hope it can. Here are a
couple of posts you should start with. The second has code you can
analyze and improve on:

http://groups.google.com/group/comp.lang.functional/msg/d7394ad977b3a396
http://groups.google.com/group/comp.lang.functional/msg/b02f11bb1e3485d6

But before you bother you have to at least open your mind to even
the *possibility* that beloved Lisp cannot achieve what he is trying
to achieve. Can you emotionally and intellectually do that as any
good scientist must?

At least I'll read these threads. Thanks.

 

[Keith H Duggar]

Above I wrote that in C or C++ it would require a fat pointer.
In a well designed language, this wouldn't necessarily be the
case; the fat pointer is required because C and C++ don't
distinguish between a pointer to a single object, and a pointer
to the first element of an array.

A fat pointer may not "necessarily be the case" which is to say
there are other possible implementations. However, the range check
is also not going to come for free in the general case (arbitrarily
sized blocks of memory etc) either no matter how "well designed"
the language is. In addition, correctness is often not tied to the
actual physical memory size but to a logical size for example the
..size() of a vector as opposed to .capacity(). And you are not
going to get core language support for this range check anyhow.

Furthermore, C++ allows one to build IMO superior alternatives such
as the STL containers, iterators, etc on top of this "poorly designed"
substrate. And by superior I mean superior to any core language range
checking which I do not want. That's right, I would prefer any range
checking to be optional so that I can design the most efficient
solution without interference. For example, what is faster than simply
iterating an std::vector iterator from .begin() to .end()? Do you want
to muddy that up by having say a new ranged checked []* type that the
std::vector implementation would have to use for the allocated blocks?

No thanks. I don't see the problem with treating pointers to a
sequence
of 1 element the same as pointers to a sequence of N elements. And we
can
certainly add range checking capabilities if desired at the library
level
(at least in C++). Witness STL containers and iterator based designs.

KHD

 

[Keith H Duggar]

You're correct, I postponed it for this evening.




At least I'll read these threads. Thanks.

Great. So now that you've had a chance to read his posts and
perhaps other parts of the thread and importantly his Scheme
code, what do you have to say now?

Do you still dismiss Stepanov as "a C++ programmer" or do you
see from his Scheme code that he groks Lisp as well as you? Do
you still think that "closures can do it"? If so how would you
improve on his iterator implementation (which as you see makes
use of closures) to achieve the goals he expressed? Do you now
see anything of value in the C++ pointer/iterator abstraction?
Do you consider cons cells to be "low level"?

KHD