From: ········@bayou.uh.edu
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5minp7$8g5$1@Masala.CC.UH.EDU>
Peter da Silva (·····@nmti.com) wrote:
: In article <············@masala.cc.uh.edu>,
: ········@bayou.uh.edu <········@Bayou.UH.EDU> wrote:
: > A language without hash tables isn't necessarily a lisp. C doesn't
: > have hash tables, yet by your logic it is a lisp.
: Where did I say that? C doesn't have... and can't have... lisp lists as
: part of the language. You'd have to implement lisp in C to change that,
: and the result of that would definitely be lisp. But it wouldn't be C.
That's it, you were sent by Paul Prescod to send my blood pressure
through the roof in the hope that I'd get a heart attack and
finally pull out of the C++ flamewar. Well Paul it's not going to
work!
There is no way in Hell, Heaven, or Purgatory that you could
NOT HAVE NOTICED MY EXPLICIT SARCASM LABELS!
For the love of everything you hold dear, just _Read_ my post
before responding ok? Please?
: > Semantics has nothing to do with it. My arguments were not with
: > respect to semantics, and if you had bothered to pay attention
: > you would know this.
: I know your arguments aren't concerned with semantics. That's the problem.
: Because, you see, the message you were following up to *was* concerned with
: semantics.
My *sob* stance on this issue has been made clear quite a while ago.
In *whimper* public d-d-discussions with Erik (damn, Erik is an
angel compared to you, you bastard!), my s-stance was made clear.
: Never mind. I've pointed that out enough times. Just call me a language
: nazi or something and kill the thread.
No, calling you a Nazi is too good. You've went beyond Nazism,
you've went beyond satanism -- you've even went beyond Limbaughism.
You're the living embodiement of frustration. I swear, if frustration
could sprout 2 legs and a mouth and follow me around, it would
be you -- damnit it is you!
: > Pointers as defined in a previous thread which you obviously didn't
: > read.
: Since you missed the point of the original message that asked "what if C
: pointers didn't do arithmetic", and you said you still didn't want them,
: and that scheme doesn't have pointers... who is it that missed what point?
Again this has been discussed here before, and I made it clear
that I was speaking of syntax. My view of "pointer" was a generalized
mechanism that was used as a low level construct to allow low level
access, and implicit in this definition was a barrier between
dynamic and static values. Pay attention, now:
In C:
static allocation: x = 100;
dynamic allocation: x = (int *)malloc(sizeof(int)); *x = 100;
Then you have to de-allocate your dynamic allocation:
free(x);
For the nitpicky, I'm assuming that malloc doesn't return NULL, so
no whining about checking errors please.
Notice the use of the pointer, and notice the syntax involved. Notice
how this is different from static allocation. Notice the extra
headache automatically imposed upon us (deallocation).
In Scheme:
Dynamic allocation, etc... is inherent in the language itself, hence
there is no barrier, and therefore no "pointers" -- there are no
special constructs to allocate or deallocate memory. Instead we
have a uniform way of doing things.
Think of it this way, a pointer in C is special, since it differs
from the static way of doing things. In Scheme, pointers are
implicit, hence they are the standard way of doing things, hence
there really is no pointer -- at least not as far as the programmer
is concerned.
: Take away the pointer arithmetic and associated backdoors, and the only
: difference left is memory allocation policy.
There's also the syntax, the fact that you've got a dividing line
between static and dynamic allocation, a whole slew of nightmarish
errors waiting to bite you in the arse, etc...
Anyway, to conclude this horrible nightmare of a discussion I do in
fact appreciate the semantic issues you are bringing up, but again
we are talking past each other.
I can appreciate that we could think of car, cdr, cons, and nil in
terms of pointer operations, this is apparent from the "box" notation
used in many Lisp textbooks, and the similarity of the term "nil"
with Nil in Pascall and NULL in C. There is no problem there.
The point is we are not forced too -- indeed we are encouraged
to think otherwise (in terms of high level objects).
: --
: The Reverend Peter da Silva, ULC, COQO, BOFH, 3D0G, KIBO, POPE Ziggy Wotzit II.
: Har du kramat din varg, idag? `-_-' Kulanu Kibo.
: Hail Eris! All Hail Discordia! Vi er alle Kibo.
: HEIL KIBO! HEIL KIBO! HEIL KIBO! Wir sind alle Kibo.
--
Cya,
Ahmed
From: Fergus Henderson
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5mkaob$29e@mulga.cs.mu.OZ.AU>
········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
>In C:
>
>static allocation: x = 100;
>dynamic allocation: x = (int *)malloc(sizeof(int)); *x = 100;
>
>Then you have to de-allocate your dynamic allocation:
> free(x);
>
>For the nitpicky, I'm assuming that malloc doesn't return NULL, so
>no whining about checking errors please.
>
>Notice the use of the pointer, and notice the syntax involved. Notice
>how this is different from static allocation. Notice the extra
>headache automatically imposed upon us (deallocation).
In C++ with GC (e.g. by linking in the Boehm collector):
x = new node(head, tail);
In Lisp:
(setq x (cons (head tail)))
Either way, allocation is explicit (`new' in C++, `cons' in Lisp).
The major difference seems to be the number of parentheses.
--
Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
In article <··········@mulga.cs.mu.OZ.AU> ···@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 29 May 1997 16:26:51 GMT
Organization: Comp Sci, University of Melbourne
Lines: 32
References: <············@Masala.CC.UH.EDU>
········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
>In C:
>
>static allocation: x = 100;
>dynamic allocation: x = (int *)malloc(sizeof(int)); *x = 100;
>
>Then you have to de-allocate your dynamic allocation:
> free(x);
>
>For the nitpicky, I'm assuming that malloc doesn't return NULL, so
>no whining about checking errors please.
>
>Notice the use of the pointer, and notice the syntax involved. Notice
>how this is different from static allocation. Notice the extra
>headache automatically imposed upon us (deallocation).
In C++ with GC (e.g. by linking in the Boehm collector):
x = new node(head, tail);
In Lisp:
(setq x (cons (head tail)))
Either way, allocation is explicit (`new' in C++, `cons' in Lisp).
The major difference seems to be the number of parentheses.
Or of useless '=', ',' and ';' characters :)
Sorry. I couldn't resist :)
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
In article <··········@mulga.cs.mu.OZ.AU> ···@mundook.cs.mu.OZ.AU (Fergus Henderson) writes:
From: ···@mundook.cs.mu.OZ.AU (Fergus Henderson)
Date: 29 May 1997 16:26:51 GMT
Organization: Comp Sci, University of Melbourne
Lines: 32
References: <············@Masala.CC.UH.EDU>
········@Bayou.UH.EDU (········@bayou.uh.edu) writes:
>In C:
>
>static allocation: x = 100;
>dynamic allocation: x = (int *)malloc(sizeof(int)); *x = 100;
>
>Then you have to de-allocate your dynamic allocation:
> free(x);
>
>For the nitpicky, I'm assuming that malloc doesn't return NULL, so
>no whining about checking errors please.
>
>Notice the use of the pointer, and notice the syntax involved. Notice
>how this is different from static allocation. Notice the extra
>headache automatically imposed upon us (deallocation).
In C++ with GC (e.g. by linking in the Boehm collector):
x = new node(head, tail);
In Lisp:
(setq x (cons (head tail)))
Either way, allocation is explicit (`new' in C++, `cons' in Lisp).
The major difference seems to be the number of parentheses.
Or of useless '=', ',' and ';' characters :) BTW. You inserted, with
a very unethical purpose an extra level of parentesis in the LISP
program. :)
The code fragment should read
(setq x (cons head tail))
Which happens to require 24 keystrokes agains the 25 required by the
C++ fragment with the Boehm's GC (which is a truly marvelous piece of
software).
Sorry everybody. I couldn't resist :)
--
Marco Antoniotti
==============================================================================
California Path Program - UCB
Richmond Field Station
tel. +1 - 510 - 231 9472
From: ········@bayou.uh.edu
Subject: Re: C++ briar patch (Was: Object IDs are bad)
Date:
Message-ID: <5ml6ps$2ol$1@Masala.CC.UH.EDU>
Fergus Henderson (···@mundook.cs.mu.OZ.AU) wrote:
[Snip]
: In C++ with GC (e.g. by linking in the Boehm collector):
: x = new node(head, tail);
: In Lisp:
: (setq x (cons (head tail)))
: Either way, allocation is explicit (`new' in C++, `cons' in Lisp).
: The major difference seems to be the number of parentheses.
Wrong. It seems my examples went above your head. Damn shame.
Study them again and you will see the difference.
: --
: Fergus Henderson <···@cs.mu.oz.au> | "I have always known that the pursuit
: WWW: <http://www.cs.mu.oz.au/~fjh> | of excellence is a lethal habit"
: PGP: finger ···@128.250.37.3 | -- the last words of T. S. Garp.
--
Cya,
Ahmed
In order to satisfy their mania for conquest, lives are squandered
Discharge
In article <··········@mulga.cs.mu.OZ.AU>, Fergus Henderson wrote:
>In C++ with GC (e.g. by linking in the Boehm collector):
>
> x = new node(head, tail);
>
>In Lisp:
>
> (setq x (cons (head tail)))
>
>Either way, allocation is explicit (`new' in C++, `cons' in Lisp).
>The major difference seems to be the number of parentheses.
Er, what about:
(setq x '(a b c d e f g ....))
Much easier to type than the "new node()" variety. Cons tends
to rarely be used explicitly.
--
Darin Johnson
·····@usa.net.delete_me
Darin Johnson (·····@usa.net.delete_me) wrote:
> Er, what about:
> (setq x '(a b c d e f g ....))
> Much easier to type than the "new node()" variety. Cons tends
> to rarely be used explicitly.
No problem in C++. Just overload ::operator,() so it does the allocation,
and you can write
foo = a, b, c; // ::operator,(a, ::operator,(b, c))
Greetings,
Jens.
PS: I haven't actually tried this, and I don't intend to :-)
--
··········@acm.org phone:+49-7031-14-7698 (HP TELNET 778-7698)
fax:+49-7031-14-7351
PGP: 06 04 1C 35 7B DC 1F 26 As the air to a bird, or the sea to a fish,
0x555DA8B5 BB A2 F0 66 77 75 E1 08 so is contempt to the contemptible. [Blake]
·····@bbn.hp.com (Jens Kilian) writes:
> Darin Johnson (·····@usa.net.delete_me) wrote:
> > Er, what about:
>
> > (setq x '(a b c d e f g ....))
>
> > Much easier to type than the "new node()" variety. Cons tends
> > to rarely be used explicitly.
>
> No problem in C++. Just overload ::operator,() so it does the allocation,
> and you can write
>
> foo = a, b, c; // ::operator,(a, ::operator,(b, c))
Except it would only work for the types you overloaded it for, which
kind of defeats the purpose.