Christopher Smith wrote:
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.

Right. But it still makes you a child of "Object", doesn't it?

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

If everything is an object, and everything depends from Object, what would be the boundary? When you say "bind the invocation on an instance of a base class", which base class are you talking about, and how does this differ from (say) Smalltalk?

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.

I can't think of anything else it would be. If you know exactly what line of code to which you will dispatch on a particular call, the only "polymorphism" would be in the name, not in the meaning. If the same line dispatches to the same destination whenever it's called, you could disambiguate simply by giving every function a unique name.

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

Sorry. If you still have to bind *what* to a type?

If every method can be overridden in a child class, and all objects depend from the same superclass, I'm not sure what boundary you'd wind up with.

What would be the "specific base type" that the "new" operator is "bound" to in Smalltalk?

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.

Actually, it's dynamic in part. Not too unlike C++'s mechanisms.

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.

Right. But it's not backing up the tree of inheritance. I was disputing "a lot of work at runtime" more than "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,

Right. Actually, you probably could, as long as you have data in your data space, and code in your code space. You just couldn't cast function pointers to data pointers and back.

I've also worked on machines where each object got its own segment (which thus couldn't run C unless the programmer was really, really careful about obeying the exact rules of C), and on machines where pointers to different size data had different size pointers (which meant you couldn't cast a char* to an int* and back and expect it to work).

> I don't get why you were hung up on dlsym() specifically.

I wasn't. That was your example. :-) There's a whole bunch of OS-type things you can't easily do in C without going outside the language definition. (True of most languages, but most people don't claim their language is especially good for writing OSes.)

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

Lots of what a turing machine does lands in the interpretation when it's finished.

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.

Only if you can invoke that binary. Remember, once the turing machine is done, all you have is the turing machine's tape. After that, you have to apply some interpretation to the symbols to see what was computer.

Or a better example I thought of on the drive home: SQL is turing complete. That doesn't mean you could implement Firefox in it. Sure, you could take a table that represents a web server and its contents, and leave behind a table that is indexed by X and Y and the third, fourth, and fifth columns are the RGB values at that position. But that isn't Firefox.

Mind, most of these complaints are just peeves that aren't really worth arguing too much about. :-)

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

Reply via email to