a view of comp lang [was: why we have cons]
Xah
(This message has no technical value. Skip now at will.)
I think in "Why we have cons" thread, I've progressively desperately made
very clear now what I intented to ask. From the heated but overall cool
thread, I've learned the answer more than I wanted to know. (^_^)
In the thread I mentioned *an* ideal language as a conceivable goal of
abstraction. Erik Naggum humbly denied such conceivability on the spot. In
this message I'll try to elaborate on it.
Some people have expressed that I mixed up interface with inplementation.
This prompted me to think: How exactly do you define a _programing
language_? *I* view programing language as an implementable formal
mathematical language. In other words, the ideal language in my mind is more
or less a perfect interface (as some would call it). In this ideal language,
implementation or hardware has nothing to do with it. The language consists
of primitives that directly corresponds to abstract computational concepts.
In this language, it is conceivable that we still needs "data" such as tree,
and we need to represent it (as characters, symbols, or glyphs...etc.) in
some way. One way to write it is List[...], and trees are than List[expr1,
expr2,...] where exprs are Lists or nested lists. In this ideal language, it
is conceivable we still needs to retrieve data in some way. One way is to
have a function, say, Extract. Extract[expr,{n}] will then return the nth
part of an expr. Extract[expr,{a,b,c,...}] will return the index of a tree
at {a,b,c} etc. (i.e. the ath branch of bth branch of cth branch etc.) So
you see, the two example primitives List and Extract has a concrete meaning
in the language. In this ideology, it is a kludge if one needs to figure
what caadadadadar to use to get the {i,j,k..} th index of a tree. It is a
kludge if one needs to think about cons, "cells", pointers, datatypes,
heterogenousness, vectors, constructors, efficiency,...etc. in order to
create a tree. Exactly how such a language will be like on paper, and what
primitives related to computer engineering concepts are necessary, is not
clear to me or anyone. (I think)
Remember this ideal language is defined to be implementable, but the
implemention details one couldn't possibly imagine: multitude of processor
types, myriads OSs technologies, unforseeable computing hardwares
(biological, optical, magical...), ...etc. All these should be the jobs of
computer *engineers* with the task currently known as compiler/intepreter
optimizing technology. On the other hand, computer *scientists* are busily
figuring out what such auto-optimization is possible and what is not and
what is the theoretical limit of such. These are irrevelant to the users of
this programing language. This language is permanent. It is just like a
piece of mathematics (e.g. lambda calculus), except it is actually *usable*
for computing. If there be improvements made to the language, it is the
implementations, which is totally independent to language.
It may be that such language is impossible even in theory, but it is in the
least extremely desirable and rewarding in its research. I think many of the
modern research languages are one way or another running closer to such
ideology, whether or not its their goal.
In my bias, I view computer science as a branch of math. It studies of
"what's possible", but not "what is better". The whole cons business is too
much an engineer's issue. The qestion of whether cons should be visible in a
language is, in my ideology, obvious.
Star Trek scenario:
Xah: "Computer, give me a list x".
Computer: (done)
Erik: "Computer, cons cons cons cons cons."
Computer: "Incomplete request. Please state what type? How you gonna use it?
do you want to mix datatypes? Do you care about efficiency? And how you want
your cons nested?"
2001 scenario:
Xah: "Hal, summarize the state of philosophy for me".
Hal: (answer spoken)
Erik: "Damn you Hal. Do you know what's cons? Do you know what is Lisp? Do
you know what is REAL LISP? You damn next generation fsssck!"
PS I'm like many programers, always on the lookout for the ultimate
language. Mathematica is my love. Scheme I'm learning. (I like Scheme too,
if you are looking for this line.) Perl is crap. Based on my rambling, which
language do you suggest?
Xah, x...@best.com
http://www.best.com/~xah/Wallpaper_dir/c0_WallPaper.html
"Flaming is social. It releases tension, heal wounds, expands brain size,
and promotes love. Oh, hug me."
Will Hartung
"Xah" <x...@best.com> writes:
*snip*
>PS I'm like many programers, always on the lookout for the ultimate
>language. Mathematica is my love. Scheme I'm learning. (I like Scheme too,
>if you are looking for this line.) Perl is crap. Based on my rambling, which
>language do you suggest?
Esperanto.
--
Will Hartung - Rancho Santa Margarita. It's a dry heat. vfr...@netcom.com
1990 VFR750 - VFR=Very Red "Ho, HaHa, Dodge, Parry, Spin, HA! THRUST!"
1993 Explorer - Cage? Hell, it's a prison. -D. Duck
Xah
>>PS I'm ... always on the lookout for the ultimate language....
>>which language do you suggest?
>
>Esperanto.
With respect to artificial *human* languages, how about loglan:
<http://www.halcyon.com/loglan/what-is-loglan.html>
Loglan is based on predicate logic, and indeed seems to be possbible to be used as the ideal *programing* language I'm looking for. If you knew loglan, I'd be very interested to hear what you have to say, especially in regards of its use as a programing language.
Xah, x...@best.com
http://www.best.com/~xah/Wallpaper_dir/c0_WallPaper.html
"Your nonsense is no better than mine." --Mathematician of metaland.
Excerpt:
>Loglan is a speakable, human language originally designed to serve as a
>test of the Sapir-Whorf hypothesis that the structure of local human
>languages places limits on the development of local human thought, and
>hence, on human cultures. If this hypothesis is correct, a language that
>"lifted" those constraints--that is to say, that reduced them to some
>functional minimum--should in a certain sense "release" the human mind
>from these ancient linguistic bonds and so have notable effects on both
>individual thinking and the future development of human culture.
>
>
>Since its original development in the late 1950s and the 1960s Loglan
>has acquired certain properties that also make it interesting to
>computer science, principally its total freedom from syntactic
>ambiguity. This feature of the language, together with its audio-visual
>"isomorphism" (which means that the Loglan speechstream breaks up
>automatically into fully punctuated strings of words) and its borrowing
>algorithm (by which the International Scientific Vocabulary goes into
>Loglan virtually ad libitum), may make it ideal for three uses:
>1.for international information storage and retrieval,
>2.for machine-aided translation between natural languages, and
>3.for facilitating interaction between computer-users and their
>machines.
Erik Naggum
* "Xah" <x...@best.com>
| Erik: "Computer, cons cons cons cons cons."
I wish you would at least pay enough attention to make funny jokes.
you seem to have this psychological need to ignore about half of what I
write in favor of making me appear to you as you have decided I am,
despite masses of evidence to the contrary. such is not just stupid
behavior, it's downright moronic.
go play with Mathematica or something, will you?
#:Erik
--
The year "98" was new 1900 years ago. | Help fight MULE in GNU Emacs 20!
Be year 2000 compliant, write "1998"! | http://sourcery.naggum.no/emacs/
John Atwood
Xah <x...@best.com> wrote:
>PS I'm like many programers, always on the lookout for the ultimate
>language. Mathematica is my love. Scheme I'm learning. (I like Scheme too,
>language do you suggest?
Sound to me like you might like Haskell. See www.haskell.org
Start with "A Gentle Intro to Haskell..."
Some other papers are at:
http://www.md.chalmers.se/~rjmh/tutorials.html
And some heavier stuff at:
http://www.lpac.ac.uk/SEL-HPC/Articles/GeneratedHtml/functional.pearls.html
I recommend two of Paul Hudak's papers to get the flavor of the langauge:
"Haskell vs. Ada vs. C++ vs. Awk..." - An Experiment in Software
Prototyping Pruductivity."
"Haskore Music Notation, An Algebra of Music"
both at:
http://www.cs.yale.edu/users/hudak-paul.html
The easiest implementation to install and get around in (in my
experience) is hugs, at www.haskell.org.
John
--
--Office phone: 541-737-4145 (Dearborn 311) home: 757-8772
Office mail: 303 Dearborn Hall, OSU, Corvallis, OR 97331
Marc Wachowitz
"Xah" <x...@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 <m...@ipx2.rz.uni-mannheim.de>
bowing to both of you
Xah
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, x...@best.com
http://www.best.com/~xah/Wallpaper_dir/c0_WallPaper.html
"do the Right Thing!"
Barry Margolin
In article <690vof$rqi$1...@trumpet.uni-mannheim.de>,
Marc Wachowitz <m...@ipx2.rz.uni-mannheim.de> wrote:
>"Xah" <x...@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, bar...@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.
Christopher Browne
On Fri, 09 Jan 1998 07:22:42 GMT, Barry Margolin <bar...@bbnplanet.com>
wrote:
>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"
cbbr...@hex.net - "What have you contributed to Linux today?..."
<http://www.hex.net/~cbbrowne/lsf.html>
Hartmann Schaffer
Christopher Browne wrote:
>
> On Fri, 09 Jan 1998 07:22:42 GMT, Barry Margolin <bar...@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
scha...@netcom.ca (hs)
Jeff Dalton
Barry Margolin <bar...@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
Richard Mlynarik
Jeff Dalton wrote:
> Barry Margolin <bar...@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.
Rob Warnock
Richard Mlynarik <M...@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 rp...@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