Darren New wrote:
> 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?
Yes, but being an instance of "23" is very different from being an
instance of "Number", yes? For starters, since "23" isn't a class, you
won't have an instance methods.

Yes, metaobject protocol can get confusing (Object is an instance of
Class, Class is an instance of Metaclass, Metaclass is an instance of
Metaclass class, and Metaclass class is an instance of..... Metaclass of
course ;-).
>>> 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?
It would still be bounded, as when you invoke a polymorphic function,
you still have to bind the invocation on an instance of a base class
(even if all objects must be of that type).
>> 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?
I hadn't thought of it, but technically you could consider overloading
as satitc polymorphism.
>> 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?
If you still have to bind it to a type, even if that type could be
Object, they define that is "bounded".
>> 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?
I was thinking about that, but I can't remember exactly how it works.
Certainly it was the most plausible scenario I could come up with.
>> 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?
Most Eiffel implementations use vtables like C++, so yes. Note that O(1)
!= no overhead.
> 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.
Ah, *that* is what you meant by different "address spaces". I thought
you meant something else. Umm yeah... in that case you just can't
implement C, let alone dlsym(). I don't get why you were hung up on
dlsym() specifically.
>> 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".
Well, it depends on what you mean by "powerful".
> 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. :-)
Being Turing Complete means you can (at great pain) generate the
necessary binary that the assembler would otherwise generate, and at
that point you can indeed write to the tape.

--Chris

-- 
[email protected]
http://www.kernel-panic.org/cgi-bin/mailman/listinfo/kplug-lpsg

Reply via email to