Mixed stuff

[Hans-Dieter.Dreier@materna.de]

--sucH6q9GScO33UmwD7ML0hJ7Mnq0TlLU
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

>Hans-Dieter.Dreier@materna.de wrote:
>
>>> Normally in OOPs you can't take references to methods, if you want to d=
o
>>> that you get an object reference.  C++ is an exception and I don't thin=
k
>>> there's a necessity to follow it's lead here.
>> Maybe it's not needed very often, but if I can get it for free, I'll tak=
e
>> it,  since I don't consider it harmful. There may be cases where this so=
rt
>> of dynamism allows for shorter programs (avoiding the switch statement).
>
>Not sure how.  Can you give an example?  I think there might be some
>problems with this facility, I'll have to check.

Example: lazy evaluation of parameters. Someone chooses to write a method c=
all as an actual parameter, and wants to evaluate that lazy (when and if it=
 is actually needed). We got to pass a reference to that parameter to the f=
unction that is called. =


>>> A problem is that all variable accesses turn into method calls with thi=
s
>>> system.
>> Why _all_? I'd rather think, just those that really are method calls. Of
>> course, a "normal" variable access may be seen as an inlined method call=
,
>> if you like; but then again there wouldn't be any difference in
>> performance.
>
>I meant to say, all accesses to variables in an object - local variables
>would be accessed as normal.

I still can't see why. Could you please explain ?

>>> These are less efficient, and hence method inlining is
>>> essential.  Since this is a inter-class optimisation, it make the
>>> program more fragile and subject to recompilation.  During development
>>> these inlines can be disabled if desired.
>> If the method calls can be inlined, all the better. But inlining wouldn'=
t
>> avoid the inter-class optimisation either, since the inlined code would =
be
>> used to *implement* the base class's feature. It would need
>> recompilation whenever the implementation of that feature changes.
>
>And yes, inlining across classes is always going to increase fragility
>(chance of needing recompile).  But that's a choice that the programmer
>should make.
>
>If the actual code was just a stub to access a variable, and you can
>inline, you always should, else you will lose performace.  You can't
>inline
> unless you can determine it's a static dispatch though.

That's true. I wonder which way is better:
C++ assumes static dispatch for efficiency,
Eiffel assumes dynamic dispatch to reduce fragility.

Certainly the user should have the chance to override whatever the compiler=
 assumes as a default.

>>>> This is a little disadvantage, but recompilation
>>>> may be required anyway most the time when an implementation
>>>> of a client class changes (because method addresses change).
>> Sorry, I meant _base class_ (instead of client class).
>
>Hmm, I think the JVM does something to avoid this - can't remember what
>though.

If you find out, please let me know.

>Dynamic dispatch is there because it improves flexibility.  An optimiser
>can remove its overhead if it's not needed, including, but not
>necessarily
>limited to, static dispatch determination, subsequent method inlining,
>and
>table method elimination after there are no possible uses of it exist.

At the expense of having to do global analysis, yes. BTW, if we implement w=
eak pointers, table elimination may be done by GC. There's a lot of elimina=
tions GC can do for us.

>Sure, I have been advocating conversions for all types - it's essential
>for multiple implementations.  So, your issue is really one of
>namespace?

Yes. It's the old problem that you can look at conversions to be *to* or *f=
rom* some classes, but you can normally only implement the *to* direction i=
nside the class using normal methods and the *from* direction using constru=
ctors, which (at least in C++) involves different syntax (return...), so sh=
aring a common function would be impossible. IMO, a conversion should be co=
ded only once and be visible to *both* classes, in different roles. That wo=
uld help to avoid having ambiguous conversion paths. If either class were d=
eleted, the conversion would also be deleted.

>> Sure. May everybody do it his way and get what his deserves. I don't min=
d
>> ;) That is, after all, a point that should make Ultra stand out amongst
>> other languages. As you said, we should try to keep those representation=
s
>> transformable, however.
>
>I'm not sure what you mean by "representations transformable", but if I
>said it, I agree.  =3D)

I mean, you can take a program that was edited with one editor, put it into=
 another editor, change it there using the syntactic sugar that is defined =
there, reload it into the first editor where that sugar is not available,
and it will show the *equivalent* syntactic construct without the sugar.

>> Just compare a space shuttle with a russian rocket: The US did it the
>> complicated way and ended up with a complex, expensive thing, while the
>> russians did it as simple as possible, yet powerful enough and *cheap*.
>> All I'm trying to say is: At some point it is good enough; the extra
>> effort of making it better will simply not justify the benefit gained.
>
>I'm not going to make a lot of comments on this without hearing any
>specifics.  Maybe the US version had plush add-ons like seat-belts.

To put it in other words: Small and simple but not top-performing may be be=
tter than big and sophisticated.

>I think you underestimate the challenge of designing a syntax.  I've
>haven't heard anyone say they've designed a significant text language
>that
>has a perfect parser.  Parsing just isn't that easy.  You might well be
>achieve to achieve some benefits though.  But since there will still be
>errors, you need to live with false errors, and the tradeoff between
>this
>and all other factors (writability, readability) happens.

The more complicated the syntax, the more difficult to produce meaningful e=
rror messages because the number of possible error scenarios gets too big. =
That may not be true in any case, but IMO in general it is.

I wrote an interpreter many years ago that had an extremely simple yet powe=
rful syntax (no static type checking, though). I always got decent error
messages.

>Agree - but while I'm interested in a structure editor first, I'm also
>interested in an enhanced text editor.

As I have heard, Emacs is a pretty powerful and very customizable editor. D=
o you know anything about it? I personally wouldn't like to program Yet Ano=
ther Text Editor.

>Well the reason we have explicit declarations is so a programmer has to
>go
>through and write the type in, to avoid typing errors.  I didn't want to
>lose that.  You wanted to make things easier to write.  I was trying to
>go
>somewhere in between.

There is a general solution to issues like this: Make it customizable. Who =
wants it may use it; who doesn't want it, may switch it off.

>Agreed, though I would prefer not choosing a name, requiring it to be
>entered, otherwise we'll end up with silly names being left around.  As
>much as we might complain about extra effort, programmers are lazy, and
>often we'll just not do something if we don't need to, even if we
>should,
>like choosing a good name.  Some do, some don't.  This would just be
>enforcing what we all know is best.  If "x" is the best you can think
>of,
>so be it, but we shouldn't encourage it.

See note above. If it comes to programming GUIs, one can pretty soon loose =
the desire to attach a meaningful name to each new control. And if there is=
 a context-aware renaming utility (I'd love that), no harm is done if the w=
indow was named wnd23.

>> Shouldn't be much hassle, inserting, deleting and identifying
>> items in a structure is easier than in a plain text. If such
>> options are not present in the plain text based solution because
>> it was too much hassle, so be it.
>
>Yes, but I was thinking more about back-end effort in the logistics of
>doing all those actions.

What do you mean by that? back-end =3D compiler ?

>You can probably see my point of view here.  I want to actively let the
>programmer do what they want easily, but I don't want the compiler to do
>things without asking, even if the programmer says they would like that.

Certainly we should be careful about letting the compiler do irreversible c=
hanges to a program. I think a lot of this needs to be evaluated in everyda=
y programming business. I'm just uttering some ideas here that come to my m=
ind everytime when the C++ compiler or the IDE forces me to type in a lot o=
f stuff that I deem unnecessary.

BTW, if you lean back and think it over, you may find that the compiler alr=
eady *does* a lot without asking you explicitly. I found that out the hard =
way when I wondered why something wasn't doing what I wanted it to do: Wron=
g (local) assumed storage class of some intermediate value (that I wasn't e=
ven aware of), which went out of scope prematurely. Sure this is a beginner=
's mistake, but doesn't it fall into the same category?

What is really important is that the compiler doesn't do such a thing *sile=
ntly*.


--

Regards,

Hans-Dieter Dreier
(Hans-Dieter.Dreier@materna.de)=

--sucH6q9GScO33UmwD7ML0hJ7Mnq0TlLU
Content-type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: quoted-printable

IDENTIFIKATIONSANGABEN:
a20722a.txt IA5 DX-MAIL X.400 User Agent=

--sucH6q9GScO33UmwD7ML0hJ7Mnq0TlLU--