"Xah" <···@best.com> wrote:
> Some people have expressed that I mixed up interface with inplementation.
I'd rather say it's the other way around, you don't appear to see that
the presence of or knowledge about an implementation doesn't (or at least
shouldn't) stop you from thinking on an abstract level. What's even more
important - no matter how "high-level" your abstractions might be, unless
you're only concerned with problems which are _directly_ expressable on
that abstraction level, without additional "conceptual overhead", you will
always have to (or at least should) design and implement new abstractions
on top of the existing levels. (If you wouldn't need to go beyond those,
you'd probably be better off with one finished application program working
on the input data, which would then be all you'd be left with - i.e. you
would then rather _use_ a program, and not worry about programming any more
than some average user of public transport thinks about the mechanics who're
building/repairing the trains.) Once you've really understood the way one
does (or should) use abstraction techniques, the question isn't whether you
_could_ employ more "low-level" features than you'd like to, but whether the
system does allow/support the flexible construction of new abstractions out
of whatever is already there, no matter whether "what's already there" is
something built into the system or something you (or someone else) happened
to define to the system ("implement") yesterday, last week, or last year.
(Modern variants of Lisp generally have excellent facilities in this area.)
Otherwise, you'll remain tied to the _implementation_ _level_, but not due
to some cruel language designer making "low-level" features available for
those who have good use for them, but because you're binding yourself. Once
you understand the abstraction process, there's no end to it. Erik may not
have used the most polite way to tell it, but what he has been doing is
providing you with a view onto your self-imposed bondage, in the hope that
you'll see how you're binding yourself without need.
> The language consists
> of primitives that directly corresponds to abstract computational concepts.
At least at the level of detail which any human being I know of would like
to deal with, there's no such thing as _the_ primitive level, and likewise,
nothing like _the_ (best) abstraction level. As Kent Pitman likes to point
out, there are trade-offs, and they won't disappear, no matter how much you
may want them to do so. One might imagine the far ends on the scale (for the
moment assuming only a linear, dual choice, which is generally false), but
either end wouldn't be practically useful for non-trivial purposes. E.g. at
the "low end", one could imagine the most detailed physics known at the time,
and at the "high end", the most "simple" [there, another ambiguous and very
ambivalent term!] purely mathematical check for the correctness of a result,
being applied by checking every possible value whether it's a result - surely
implementable if you can specify your problem, but hopelessly inefficient if
your life doesn't last very, very much longer than that of us mere mortals.
> Based on my rambling, which language do you suggest?
Based on what you say you'd like, I second the recommendation of Haskell.
Based on what might help you to see beyond your current viewpoint, some
relatively modern variant of Lisp (Scheme or Common Lisp being the likely
choices, depending on whether you want to use the language only to learn
the principles about which we've been talking, or routinely implement the
kind of programs in which you're interested), as _integrated_ _embedding_
of "languages" (abstractions suited to problem areas) is one of the great
strenghts of Lisp, which has evolved with and used for such an approach to
programming, partially due to its heritage in "artificial intelligence".
You may have to "get your hands dirty" (from your current viewpoint), but
in many cases, Lisp will at least allow you to build and then work at a
level of discourse with which you can relatively comfortably "talk about"
your problem domain, further and further, ignoring the "lower levels" where
that's feasable, but "going down" and tuning them whenever that's needed.
Sure, it's work, it will take time and effort, but it may be rewarding
once you've passed the perceived barriers.
Erik's statement "know yourself. forget yourself" might be based on words
by the ancient Zen teacher Dogen: "To study the Buddha-way is to study the
self. To study the self is to forget the self. To forget the self is to be
actualized by myriad things" (Genjo-Koan). Rephrasing another statement
by Dogen, one might say: Delusion is to see the implementations merely as
implementation, awakening is to see abstractions in all implementations.
(When another of those fellows, Lin-chi, was frustrated that his questions
were answered by a teacher with blows, he wanted to go away. Later he was
asked why he wouldn't go back and thank the teacher for what had in fact
been grandmotherly concern and friendliness [highly valued in those days].)
-- Marc Wachowitz <··@ipx2.rz.uni-mannheim.de>
bowing to both of you
Thanks to Marc Wachowitz, Erik Naggum, Ken Pitman, and many others in the
cons thread. Some of the messages I've scrutinized several times.
I've learned that the Mathematica philosophy is not the only philosophy.
After all, it is probably why it is an application language. Basically, my
view of an Ideal language appears to be more or less a preference towards
abstraction... (being in the lisp community is the right choice!)
Xah, ···@best.com
http://www.best.com/~xah/Wallpaper_dir/c0_WallPaper.html
"do the Right Thing!"
In article <············@trumpet.uni-mannheim.de>,
Marc Wachowitz <··@ipx2.rz.uni-mannheim.de> wrote:
>"Xah" <···@best.com> wrote:
>> The language consists
>> of primitives that directly corresponds to abstract computational concepts.
>
>At least at the level of detail which any human being I know of would like
>to deal with, there's no such thing as _the_ primitive level, and likewise,
>nothing like _the_ (best) abstraction level. As Kent Pitman likes to point
>out, there are trade-offs, and they won't disappear, no matter how much you
>may want them to do so.
I think the issue that Xah may be running into is that Lisp is a bit
schizophrenic in this regard. In many ways it purports to be a very-high
level language: it hides things like memory management (via garbage
collection), pointers (almost everything is a pointer under the hood), and
table lookup (looking up symbols in packages, class names, reader macros);
and arbitrary-precision rational and complex numbers and hash tables are
built-in data types (at least in Common Lisp).
But in the midst of this, there are these little things called conses.
They're not as low level as C structs, but they don't seem to fit in with
the above philosophy of high-level built-in abstractions.
I think the only real excuse for them is historical. Lisp was not always
as feature-rich as Common Lisp. I don't think Lisp 1.5 even had arrays,
and Maclisp's arrays were pretty crude (you accessed them by calling them
as functions, mimicking Fortran and PL/I's syntax). Lisp has often been
referred to as a "big ball of mud", because people have thrown all these
features at it and they just stuck; but the original dirt is still in there
as well.
When new languages are designed, they can learn from Lisp and borrow the
high level features that it accumulated, while hiding the low level
implementation details. Thus, Mathematica, Haskell, and Perl make vectors
and lists the primitive types, and hide the details of whether they're
implemented as arrays or linked lists. On the other hand, if your
application is sensitive to the performance differences between linked
lists and arrays, you may get a nasty surprise; it's no accident that these
languages didn't really get popular until machines got fast enough that
this wasn't a problem for most applications.
--
Barry Margolin, ······@bbnplanet.com
GTE Internetworking, Powered by BBN, Cambridge, MA
Support the anti-spam movement; see <http://www.cauce.org/>
Please don't send technical questions directly to me, post them to newsgroups.
From: Christopher Browne
Subject: Re: a view of comp lang [was: why we have cons]
Date:
Message-ID: <695h6i$sfe2@george.sabre.com>
On Fri, 09 Jan 1998 07:22:42 GMT, Barry Margolin <······@bbnplanet.com>
wrote:
>I think the issue that Xah may be running into is that Lisp is a bit
>schizophrenic in this regard. In many ways it purports to be a very-high
>level language: it hides things like memory management (via garbage
>collection), pointers (almost everything is a pointer under the hood), and
>table lookup (looking up symbols in packages, class names, reader macros);
>and arbitrary-precision rational and complex numbers and hash tables are
>built-in data types (at least in Common Lisp).
>
>But in the midst of this, there are these little things called conses.
>They're not as low level as C structs, but they don't seem to fit in with
>the above philosophy of high-level built-in abstractions.
>
>I think the only real excuse for them is historical.
I look at the LISP and Scheme code that I write; perhaps with more
skill, things would improve, but at this point, a lot of effort goes
into twiddling with list contents. High level though the languages may
be, at some point some "low level" stuff takes place in order to
complete the program.
One can contrast this with FORTH, where well-written programs are fairly
high level and hide details, but at some level, and particularly in
programs by "naive" programmers, there will be lots of "ugly" stack
manipulation code.
C programs have "equivalent" problems with pointers and memory
allocation; that tends to be where C ugliness enters...
I rather think that the "ugliness" is a given. Every language will have
some "interface ugliness" *particularly* when used by naive programmers.
--
"Bother," said Pooh, "Eeyore, ready two photon torpedoes and lock
phasers on the Heffalump, Piglet, meet me in transporter room three"
········@hex.net - "What have you contributed to Linux today?..."
<http://www.hex.net/~cbbrowne/lsf.html>
From: Hartmann Schaffer
Subject: Re: a view of comp lang [was: why we have cons]
Date:
Message-ID: <34B6AF31.27C7A1D6@netcom.ca>
Christopher Browne wrote:
>
> On Fri, 09 Jan 1998 07:22:42 GMT, Barry Margolin <······@bbnplanet.com>
> wrote:
> >I think the issue that Xah may be running into is that Lisp is a bit
> >schizophrenic in this regard. In many ways it purports to be a very-high
> >level language: it hides things like memory management (via garbage
> >collection), pointers (almost everything is a pointer under the hood), and
> >table lookup (looking up symbols in packages, class names, reader macros);
> >and arbitrary-precision rational and complex numbers and hash tables are
> >built-in data types (at least in Common Lisp).
> >
> >But in the midst of this, there are these little things called conses.
> >They're not as low level as C structs, but they don't seem to fit in with
> >the above philosophy of high-level built-in abstractions.
> >
> >I think the only real excuse for them is historical.
>
> I look at the LISP and Scheme code that I write; perhaps with more
> skill, things would improve, but at this point, a lot of effort goes
> into twiddling with list contents. High level though the languages may
> be, at some point some "low level" stuff takes place in order to
> complete the program.
> ..
If you look at (e.g.) SICP or Lisp in small pieces you will notice that
this low level stuff is used in the examples only to build higher level
abstractions. Without it, you would be forced to build your
abstractions only in the high level abstractions built into the
language. While this probably is good enough in most cases, there will
always be cases where the builtin high level structures are not quite
what you want.
-------------------------------------------------------------------------
Hartmann Schaffer
Guelph, Ontario, Canada
········@netcom.ca (hs)
Barry Margolin <······@bbnplanet.com> writes:
> I think the issue that Xah may be running into is that Lisp is a bit
> schizophrenic in this regard. In many ways it purports to be a very-high
> level language: it hides things like memory management (via garbage
> collection), pointers (almost everything is a pointer under the hood), and
> table lookup (looking up symbols in packages, class names, reader macros);
> and arbitrary-precision rational and complex numbers and hash tables are
> built-in data types (at least in Common Lisp).
>
> But in the midst of this, there are these little things called conses.
> They're not as low level as C structs, but they don't seem to fit in with
> the above philosophy of high-level built-in abstractions.
I don't see why lists (e.g.) are high level and binary trees (conses)
are not.
> I think the only real excuse for them is historical.
I don't agree. Indeed, I was just adding lists to a program in some
losing language, and I tried a number of possible ways of doing this
before deciding that something very like Lisp's approach was probably
best.
-- jd
From: Richard Mlynarik
Subject: Re: a view of comp lang [was: why we have cons]
Date:
Message-ID: <34BD18B0.41C67EA6@POBox.COM>
Jeff Dalton wrote:
> Barry Margolin <······@bbnplanet.com> writes:
[...]
>
> > I think the only real excuse for them is historical.
>
> I don't agree. Indeed, I was just adding lists to a program in some
> losing language, and I tried a number of possible ways of doing this
> before deciding that something very like Lisp's approach was probably
> best.
There's nothing wrong with lists implemented with pairs.
What's historical (and dubious) is both the use of a distinguished
"pair" data type (rather than a vector of length 2) to implement
lists and the privileged position (read syntax, length, rest args)
held by lists in the language.
It's perfectly possible -- and demonstrated by implementation -- to
create a comfortable Scheme-like language which does not have
a pair data type and in which lists are implemented entirely
as a library.
"(define cons (lambda (a b) (vector a b))",
Richard.
From: Rob Warnock
Subject: Re: a view of comp lang [was: why we have cons]
Date:
Message-ID: <69kjeh$f26vl@fido.asd.sgi.com>
Richard Mlynarik <···@ADOC.Xerox.COM> wrote:
+---------------
| It's perfectly possible -- and demonstrated by implementation -- to
| create a comfortable Scheme-like language which does not have
| a pair data type and in which lists are implemented entirely
| as a library.
|
| (define cons (lambda (a b) (vector a b))
+---------------
Or even, as is sometimes shown in Scheme primers, pairs as closures:
(define cons
(lambda (a b)
(lambda (fcn)
(cond
((eq? fcn 'car) a)
((eq? fcn 'cdr) b)
(else (error "Bad selector to cons object"))))))
(define car (lambda (x) (x 'car)))
(define cdr (lambda (x) (x 'cdr)))
"Hey, it could happen..." ;-}
-Rob
-----
Rob Warnock, 7L-551 ····@sgi.com http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673 [New area code!]
2011 N. Shoreline Blvd. FAX: 650-933-4392
Mountain View, CA 94043 PP-ASEL-IA