Christopher Smith wrote:
Note, however, that if your decorator is a descendent of nil, and nil
is a descendent of Object, you're still a type of object. :-)
As I tried to be really, really clear about: 'nil' isn't a class, so it
can't be a descendant of Object or any other class.
'nil' isn't a class, nor is '23'. But as far as I remember, they're both
descended from Object?
Right. So wouldn't that make smalltalk "unbounded"?
Yes, glad to see you are coming around on this.
OK. Take C# as an example then, where every object *is* descednded from
Object (AFAIR). That would be ... which, bounded or unbounded?
1) static vs. dynamic polymorphism is about whether the polymorphism is
resolved at runtime or not. A statically polymorphic system would select
which method to invoke at compile time, while a dynamic one wouldn't
decide until the method was actually being invoked.
So this is the difference between "dynamic dispatch" vs "static
overloading"? C++ has both, right?
2) bounded vs. unbounded is about whether the programmer has to "bind"
the polymorphism to a specific base type.
What if every type descends from Object, tho? Is that bounded or unbounded?
I can't think of one off the top of my head that is static and
bounded, but someone probably has a generics mechanism that works that way.
Ada's tagged types, I'd think?
One way to think of it is how much work is being left to do at runtime.
A dynamic unbounded system has no idea what type it is working with or
what method it is invoking, so it has a lot of work to do at runtime.
I would think Eiffel is dynamic unbounded with O(1) dispatch, yes?
Woa... hold on there. dlsym() can easily be imported in whatever
language you want.
Not my point. I'm talking about the implementation of dlsym(), not the
invocation of it. I don't think you can implement dlsym() in C without
using compiler-specific tricks to make it work.
Which may be better or worse than other languages, where (say) there
might be a facility to do something, and the hardware/OS provides a
different way to do that which is incompatible but would be sufficient
for your purposes, and you find the language doesn't allow you to use
that other facility because it's incompatible with the language. :)
You'd have to admit, it'd be a weird implementation choice that would
actually cause the platform and the compiler for said platform to be
incompatible with each other.... You'd think the compiler, in
particular, would prove unpopular.
I'm saying, for example, that you cannot in C (as an example) have
memory with different bit-widths in different places. You can't have
12-bit ROM memory and 8-bit RAM memory and expect your C compiler to
work well. Hence, you probably just wouldn't have a C compiler on that
platform.
You can't implement C on a B5000 series machine, because the machine
language actually knows what data is in what address. union {int i;
float f;} just isn't possible to express in the machine code of a B5000.
Guess what: there's no C compiler for a B5000. :-)
Turing Complete systems are physically impossible, so when people call a
"system" Turing Complete, the notion is that given infinite resources it
would be. However, a Turing Complete language... well, it is somewhat
hard for a language NOT to be Turing Complete (certainly doable if you
try, but C++ templates are a great example of a language that
accidentally ended up being Turing Complete).
Sure. But that the language is Turing Complete doesn't mean "it's just
as powerful as any other language that's Turing Complete".
Being "Turing Complete" doesn't really help a bunch. For example, if you
can write to the cassette tape in assembler, but your BASIC interpreter
doesn't support that, it doesn't matter that BASIC is Turing Complete -
it isn't as powerful as the assembly language on that machine. :-)
--
Darren New / San Diego, CA, USA (PST)
It's not feature creep if you put it
at the end and adjust the release date.
--
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg
