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

Re: C# is not Dylan (was: Re: C# : The new language from M$)

rurban@sbox.tu-graz.ac.at (Reini Urban) writes:

> Compliments only to features which deserve them. Here I found a couple
> of misinterpretations, so I list some "problems" which might be anchors
> for people from outside:
> 
> Simon Brooke wrote:
> >Well, then, look again. LISP syntax results from the fact that LISP as
> >printed is a very nearly direct representation of the structures that
> >are created in the machine as it is read. 
> 
> are you mixing assembler with lisp here? 

Yes and no. LISP *is*, after all, at bottom, an assembler - for an
abstract machine with a small number of instructions, and the ability
to compose new instructions from existing ones in a seamless manner.

After all, all of

    CAR
    CDR
    EQ
    SET

(and others, but exactly which others we could argue about) are
effectively primitive instructions for the LISP virtual machine (and,
indeed, are generally compiled to single instructions for the machine
machine LISP runs on); but it's worth bearing in mind that in LISP
machines (in the broader sense) the distinction between a function and
a primitive instruction can get blurred in the strangest places. For
example, in the mid-eighties, Xerox had an experimental processor
which did selector-method resolution for LOOPS (Xerox' object-oriented
extension for InterLISP, and one of the precursors for CLOS) as a
*single* machine instruction. Given that LOOPS was multiple
inheritance, that is an exceedingly non-trivial function (and yes, it
was implemented in microcode, and I'm sure it didn't execute in one
clock tick).

Furthermore, assembler, in its commonly accepted sense, is a very poor
representation of what actually happens in the machine. It can
represent clearly only continuous vectors of instructions. Very little
of what happens in a machine is continuous vectors of instructions.

> a lisp (READ) is a much more complicated then a C read().
> a lisp (PRINT) is much more complicated then a C write().

Did I say they weren't? Wherein is the contradiction?

> >The representation of LISP structures which you conventionally edit in
> >a file has a uniquely direct and simple mapping onto the
> >representation which is held in core - a representation much more
> >direct, much more consistent and much more perspicuous than in any
> >other high-level language in common use. 
> 
> doubt the first. exactly the opposite,

If you believe this, you have never written a structure editor. Write
one; you will find it very instructive.

> thanksfully so.
> C or pascal pointer orgies would resemble high-level internal
> representation of lists in contrast to the list abstraction.
> compare a => b => c => nil to (a b c). 
> simple? hmm. powerful, yes. consistent and perspicuous? 

So you would be happy to write your C programs by stitching together
strings representing code vectors with pointers? I could not do that,
although I've written a lot of C.

> well... that's getting esoteric. every language has its own consistent
> and perspicuous representation.

not so. The representation

    int plus( int a, int b)
    {
	return a + b;
    }

looks superficially very like the representation

    typedef struct treeVal
    {    
	struct treeVal * next;
	struct dTNode  * node;
	int              depth;
    }treeVal;
    
but the structures they build in C are entirely different. The
representation is inconsistent, because it re-uses syntactic forms in
different contexts to mean things

> and with tagged data it is completely the opposite of direct
> representations. ever wrote lisp<-><other memory> converters?
> only typed structures and typed vector would deserve that name.

Indeed I have, for Portable Standard LISP with mark-and-sweep garbage
collection, in multi-tasking environments where GC could happen during
the copy. Yes, it can get interesting - but that's because the way
LISP and C organise structures in memory are very different.

> The points with lisp are other's, that you can easily abstract lists,
> nested lists and more. And having a language which is defined in exactly
> the same simple way. blabla...

Isn't that *exactly* what I said?

-- 
simon@jasmine.org.uk (Simon Brooke) http://www.jasmine.org.uk/~simon/
	; ... of course nothing said here will be taken notice of by
	; the W3C. The official place to be ignored is on www-style or
	; www-html.					-- George Lund
Follow-Ups: References: