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

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

Simon, 

This gets into hair-splitting, because both of use understand the
strengths and weaknesses of both worlds. 

I just wanted to clear out some common misinterpretations, esp. with
GOOD and BAD representations in the "machine" and on the contrary in the
"program". Your term "memory" was meant by you as "program memory" and
by me as "machine memory". Same with "core" below.

To make my point: 
lisp as well as a program needs "bounding" markers and "linking"
delimiters.
  (a b c)

raw machine memory needs just pointers and offsets. with lists that is 
a starting pointer, linking pointers and an ending sentinel.
  a => b => c
with programs the same, only linking can be omitted, only when needed
explicitly by jump instructions. in core you won't need boundaries and
delimiters as in lisp. their point.

In some possible interpretation you could argue that the latter syntax
is easier, in another the former. easier is the latter ("you need no
markers around"), but better the former, because it allows nesting
without structs.

Simon Brooke wrote:
>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. 

s/machine/program 
then it would be okay for me.

>> 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?

misinterpretation. when I associate machine with raw memory it's a
contradiction but when associated with "program" I accept your words.

daniel got it also. you may mean also compiled/interpreted code with the
"structures" as in the next chapter, so it's perfectly okay then.

I only want to fall back into the C/C++ minds from time to time, our
terms used here mean almost nothing to them.

>> >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.

done. and I do it even with dynamic foreign data. horrible to do it in C
or C++, but wonderful in python, perl or lisp.
just the same misinterpretation and again hair-splitting because we are
talking about two different things.

I wouldn't use "core" as the internal program representation. With core
I think of hex dumps in a debugger which has no direct and easy mapping
in lisp, in contrast to unaligned C (just as example).
  #pragma pack(1) /* MSVC syntax for byte alignment */
would fit fine to the term "direct" then.
for lisp I would need something like (ffi:malloc ...) for a "direct"
representation. :)

>> 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.

both of us admire lisp's abstraction. we wouldn't do that. 
but other folks are also proud of their language abstraction
possibilities (C++ folks excluded probably).
The point is that the "simple" and "fast" argument for mere pointer
traversal (same as CDR, I know) will not die. also the simple and fast
(to write) syntax arguments. 
we cannot simply say that our language is "better", "consistent", "more
consistent" and "perspecious" in this regard, because it is relative.

>> 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.

worse with parens only. that's a contra lisp argument here.
you have to remember function names and their actions, with C you only
have to remember that "struct" is a struct, () is for arguments, {} is
for blocks. more precise. and more consistent.
different context, different meaning.

>> 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?

yes, but non-lispers wouldn't understand it the way you said it.
--                                         
Reini
Follow-Ups: References: