In article <1994Apr10.044450.20037@cdf.toronto.edu> g2devi@cdf.toronto.edu
(Robert N. Deviasse) writes:
> Yes. Some of the features you propose, can be added fairly easily. For
> instance, you can add the pseudo-templated class "covariant<aType>" and
> "covariant<aType>.someDependentType" to have the properties that allow
>     virtual void f(convariant<Animal>,covariant<Animal>.Food);
> to be overriden only by
>     virtual void f(convariant<T>,covariant<T>.Food);
> where T is a subclass of Animal, and covariant<T>.Food is a subclass of
> covariant<T>.Food. Such dynamic checking, as you've said, can be done
> without breaking the type system by giving the compiler the responsibility
> of throwing a type_constraint_exception rather than asking the programmer
> to do so. It would definitely complicate the current overload-resolution
> algorithm, but IMO, it can *yet* be added to C++. I doubt, though, many
> C++ programmers are willing to pay for the added complexity to the language.
>
This feature is not so easy that you can add simply by adding some sytax sugar.
The C++ sytax is already too complex. It plays too many sytax games. What I
need is to have a uniform and clear concept with a very simple syntax. I really
hate to see any syntatical extension of the language.

In theory, covariant<Animal>.Food is possible only if covariant<Animal> is the
same as a real class and the same as a first-class object.

> Other features, like being able to dynamically create types, and dynamic
> polymorphism aren't nearly as trivial to implement. Please show me *how*
> you would implement these in C++, while still preserving it's nature. The
> burden of proof is on you. I'd love to be shown that it's trivial to do
> and won't cause other problems. Better yet, I'd love for the standization
> committee to be shown this.
>
This is not a simple subject that I can talk here. The short answer is, I
cannot implement these in C++ while preserving it's non-uniform nature. To do
this, first, every type should be class. It requires a different implementation
technique (you seems very interested in implementation) to ensure the C++
principle: no overhead on C if C++ features are not used. This principle can be
reserved, and can even be reserved better than C++: no overhead on C even if
there are some classes with virtual functions or virtual classes (class
parameters for dynamic genericity) presented. Therefore, if we have abstract
number class, and we do not use it to specify a polymorphic interface, overhead
on the number class is not necessarily introduced to your object code (This is
a pure implementation issue, anyhow). As a result, run-time info is not
necessarily for only those classes with virtual function. And you can get more
info like "IsSubclass?" and "HasFeature?" if your do not care more overhead in
your executable, but you do not have the overhead if you do not use them.

> If your language uses a "safe" but "useful" subset of C++ as a core, and it
> genuinely better, I see no reason why it can't build off C++'s success. Since
> your language would use a "safe" subset of C++ then code written in this
> common subset should be "safe" and compilable under both languages. If it is
> good enough, then it may even replace C++ -- no language lasts forever.
>
> I, for one, would support such an effort and I'm sure many others here would
> also.
>
That is what I'm thinking about: ((C++) - 0.2)++. This is definitely an
interesting work.

>
> Templates are a fairly safe language feature. If you want to pick on problem
> language features, I can think of at least half a dozen. Fortunately many of
> these have been documented, and some of them are being dealt with by the
> ANSI/ISO committee.
>
I don't like nit-picking. However, C++ template is not a thoughtful feature
from the very beginning. It is not type-safe at the time you design it. It is
not type-safe at the time you deliver it to your customers. A template user
must know the implementation detail. These are fundamental faults.

I don't like to pick up some holes with <> or <<>> because of some ambiguity in
syntax.

David Shang

In article <1994Apr1.150848.18340@cdf.toronto.edu> g2devi@cdf.toronto.edu
(Robert N. Deviasse) writes:
>
> Yes, but all these this only show one thing, Cluster and C++ address
> different problem domains. I don't use C++ to do intensive A.I.
> (at least not willingly or real-time animation in CLOS (at least
> on a P.C.:-]).

Cluster is not that different from C++. They should address the same problem
domains, but Cluster can offer something more. Cluster is not a dynamic
language like CLOS or some language used for A.I.

> C++ is, from your
> description, a far lower level language and I honestly don't see a way
> Cluster-like features can be added to it.
Did you have any serious thought before you came out this conclusion?

> And if you could, can you imagine
> the complexity of such a language?!?! Would you use or even be able to
> understand all that was going on?
>
However, I will not try to add Cluster-like features into C++, because C++ is
much complicated by many unpleasant patches. I have to remove those patches,
which will make a language incompatible with C++. For example, to use Cluster
generic class, I have to knock off template. It is not the Cluster's feature
that makes things complex. It is the C++ feature. For example, template is much
more difficult to understand and to use than Cluster's generic class. There are
many restrictions you have to learn with template. There are many things you
have to worry about when you use it. And there are many different concepts
associated with templates. And the worse, the standard keeps changing, and the
implementation varies from one compiler to another, varies from one version to
another!

> How on earth would you debug the beast???
On the contrary, C++ is already a beast for debugging bacuse of some bad
features. Template is an example. Replacing some bad features with good ones
will be helpful in debugging.

> There will always be languages that are better expressing certain
> problems than others. We haven't done any better with natural languages
> and all their jargon so what makes you believe we can do any better with
> artificial languages?
>
> It all comes down to one principle:
>    "Know your problem. Then choose your tools."
>
This is always the excuse when somebody tries to defend C++. It is true when
you compare SmallTalk or CLOS with C++. However, C++ is not perfect in the
problem domains where it is used.

David Shang

In article <1994Apr8.210217.8000@schbbs.mot.com> shang@corp.mot.com writes:
>In article <1994Apr1.150848.18340@cdf.toronto.edu> g2devi@cdf.toronto.edu
>(Robert N. Deviasse) writes:
>> C++ is, from your
>> description, a far lower level language and I honestly don't see a way
>> Cluster-like features can be added to it.
>Did you have any serious thought before you came out this conclusion?
>

Yes. Some of the features you propose, can be added fairly easily. For
instance, you can add the pseudo-templated class "covariant<aType>" and
"covariant<aType>.someDependentType" to have the properties that allow
    virtual void f(convariant<Animal>,covariant<Animal>.Food);
to be overriden only by
    virtual void f(convariant<T>,covariant<T>.Food);
where T is a subclass of Animal, and covariant<T>.Food is a subclass of
covariant<T>.Food. Such dynamic checking, as you've said, can be done
without breaking the type system by giving the compiler the responsibility
of throwing a type_constraint_exception rather than asking the programmer
to do so. It would definitely complicate the current overload-resolution
algorithm, but IMO, it can *yet* be added to C++. I doubt, though, many
C++ programmers are willing to pay for the added complexity to the language.

Other features, like being able to dynamically create types, and dynamic
polymorphism aren't nearly as trivial to implement. Please show me *how*
you would implement these in C++, while still preserving it's nature. The
burden of proof is on you. I'd love to be shown that it's trivial to do
and won't cause other problems. Better yet, I'd love for the standization
committee to be shown this.

>> And if you could, can you imagine
>> the complexity of such a language?!?! Would you use or even be able to
>> understand all that was going on?
>>
>However, I will not try to add Cluster-like features into C++, because C++ is
>much complicated by many unpleasant patches. I have to remove those patches,
>which will make a language incompatible with C++.

Fair enough, but you have to preserve the C++ burden of C's syntax and
semantics, otherwise your comparison is unfair.

If your language uses a "safe" but "useful" subset of C++ as a core, and it
genuinely better, I see no reason why it can't build off C++'s success. Since
your language would use a "safe" subset of C++ then code written in this
common subset should be "safe" and compilable under both languages. If it is
good enough, then it may even replace C++ -- no language lasts forever.

I, for one, would support such an effort and I'm sure many others here would
also.

>For example, to use Cluster
>generic class, I have to knock off template. It is not the Cluster's feature
>that makes things complex. It is the C++ feature. For example, template is much
>more difficult to understand and to use than Cluster's generic class.

Difficulty is relative. I know some people who believe FORTH is easier to
understand and use than C++. I haven't had any problem with templates in C++,
though I do admit that allowing templates to specify more context-sensitive
information would definitely improve their useability. The syntax for them
could also have been better.

>There are
>many restrictions you have to learn with template. There are many things you
>have to worry about when you use it. And there are many different concepts
>associated with templates.

Name *one* language feature that doesn't have these problems. Even with
integers you have to worry about things like overflow, loss of significant
digits, .... If you want to do bitwise operations on integers you need to know
the representation of integers. Even if you represent an integer as an
auto-extending bit-string, you still have to worry about getting out of memory
errors when doing multiplications (if you represent a fraction as a pair of
extensible integers, this is a very real possibility). I wish life were so
simple that we could ignore all these pesky details.

Templates are a fairly safe language feature. If you want to pick on problem
language features, I can think of at least half a dozen. Fortunately many of
these have been documented, and some of them are being dealt with by the
ANSI/ISO committee.

>And the worse, the standard keeps changing, and the
>implementation varies from one compiler to another, varies from one version to
>another!
>

Don't all pre-standardized languages suffer from this problem? Would Cluster
not suffer from this problem if it were more widely used?


>> How on earth would you debug the beast???
>On the contrary, C++ is already a beast for debugging bacuse of some bad
>features. Template is an example. Replacing some bad features with good ones
                                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>will be helpful in debugging.
 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>


This is the case in all languages, is it not? What is important in debugging
any language, is knowing how features interact. The more interactions, and the
more unexpected interactions there are, the more difficult the debugging.
A more complex language than C++ would necessarily be hard to debug.

>> There will always be languages that are better expressing certain
>> problems than others. We haven't done any better with natural languages
>> and all their jargon so what makes you believe we can do any better with
>> artificial languages?
>>
>> It all comes down to one principle:
>>    "Know your problem. Then choose your tools."
>>
>This is always the excuse when somebody tries to defend C++. It is true when
>you compare SmallTalk or CLOS with C++. However, C++ is not perfect in the
>problem domains where it is used.


True, but is *any* language? Why restrict yourself to one language, anyway?
C++, when suitably restricted is definately a better C. If you need such
dynamic features, why not use C++ to implement the lower and mid level details
and delegate the higher level details to a language like Visual Basic,
SmallTalk, or CLOS? We do this in "real life"[TM] all the time. Nuclear
physicists speak the language of quarks, organic chemists speak the language
of atoms, biochemists speak the language of macromolecules and pharmacists
speak the language of grams. All these levels are needed to fully structure
what is going on, but do you really believe a pharmacist should do his work
in the language of quarks (leptons, etc), or the nuclear physicist should
use grams (if it were even possible!)?

I don't think either language is superior, they just belong to different
problem domains. This doesn't mean C++ (or any other language) can't learn
from Cluster -- it should. It just means that we can't design the perfect
language all at once, but we still need to use something in the mean time,
and we often have to learn from our current mistakes -- not everything can
be anticipated.

I wouldn't try to weaken Cluster by adding too many C++ features to it, just
as I wouldn't weaken C++ by adding too many Cluster features. What I would
concentrate on, would be on ways of making both language more freely linkable.

How freely does Cluster link with C-code? If there is a good *standard*
Cluster to C interface (as there is in Sather and Eiffel) then I see no
reason why you can't have the best of both worlds.

>
>David Shang


Take care
    Robert

--
/----------------------------------+------------------------------------------\
| Robert N. Deviasse               |"If we have to re-invent the wheel,       |
| EMAIL: g2devi@cdf.utoronto.ca    |  can we at least make it round this time"|
+----------------------------------+------------------------------------------/