Mixed stuff

[Matthew Tuck]

Hans-Dieter.Dreier@materna.de wrote:

>> A more general alternative to this would be to define "get" and "set"
>> methods to emulate a variable, like many languages are doing now.
> If there is a function returning the feature itself, that would be the
> "get", and the function returning a reference to the feature would be the
> "set" (which could also be used as a "get", after automatic
> dereferencing). Right? It would involve polymorphic use of the feature's
> name, however, which I personally do not like very much because it adds
> some ambiguity to the source code (ambiguous not to the compiler, of
> course, but to the forgetful programmer).

No a set is usually a procedure.  I'm thinking these days though that it
might be best to just return an object like C++ allows though, since
get/sets can't be easily passed as parameters (you do want to be able to
pass fields), whereas objects which actually contain get/set code can
be.  These object are basically of a nested class.

> If you mean the interface definition by "method signature", I agree.

Yes.

>> Normally in OOPs you can't take references to methods, if you want to do
>> that you get an object reference.  C++ is an exception and I don't think
>> 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 take
> it,  since I don't consider it harmful. There may be cases where this sort
> 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.

>> A problem is that all variable accesses turn into method calls with this
>> 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.

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

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

> >> aClass::aMethod (int p1) vs. aFunction (aClass this, int p1)
> >> ============================================================
> >> IMHO the *compiled* code for those examples
> >> may actually be *identical*.
> >
> >A call to the first may well involve a method dispatch, the second, at
> >least in a single dispatch language, would not.
>
> You mean in case of virtual functions? That's true. I would like
> to use static "dispatch" (actually an ordinary direct call) wherever
> possible, because of better performance, combined with less memory usage
> (due to shorter v table). In this case they would be the same.

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.

>> Languages which use multiple dispatch (choosing the method based on the
>> type of more than one parameter) do things this way.
> Do you mean the formal (declared) or the actual type (which may well be a
> derived class)?

I'm not aware of any language which uses the formal type in dispatch, at
least not as the default calling mechanism.

>> No, I've never been very comfortable with this either.  This as far as I
>> can see is the reason why C++ has the friend keyword.  In this way, it's
>> put in neither class but still has access to private members.  I and
>> most people I know don't really like friend, but it does its job.

> I didn't mention access to private features to the class. If that is
> needed and the function is not part of the class, surely there must be a
> friend declaration. But IMO most conversions should be able to do without
> if there is a suitable public constructor available.

Sure, I have been advocating conversions for all types - it's essential
for multiple implementations.  So, your issue is really one of
namespace?
I'm not sure what to say about this - let me have a think.

> Anyhow, to allow the compiler to use a given method for automatic
> conversions should explicitly granted by the programmer. Otherwise
> the weirdest things can happen.

I don't know of any situation where implicit conversions would be
warranted.  An exception would be converting from one implementation to
another, but I don't consider that a conversion in the same sense since
it
retains interface.

>> I'm not sure what you're getting at here.  If there's a problem, it
>> indicates the implementation should be tweaked rather than abandoned.
>> It should be simple to tell you if the file has been updated.
> In plain words, I was just trying to say: "Not having an automatic,
> mandatory layout has its problems, especially in a text file".

Oh I see.  Lack of coding convention and all.  Yes.  The beauty of AST
editing is it skips all that stuff.

> Sure. May everybody do it his way and get what his deserves. I don't mind
> ;) That is, after all, a point that should make Ultra stand out amongst
> other languages. As you said, we should try to keep those representations
> transformable, however.

I'm not sure what you mean by "representations transformable", but if I
said it, I agree.  =)

>> While it's impossible to comment in general on a general comment like
>> this, I have to disagree.  The compiler is there to save the programmer
>> time.  That's why it was invented, and that's still what it's for.
> But if you take that to an extreme, you end up with PL/1 or Ada or
> C++. Certainly there must be some balance.

Therein lies the difference between functional and arbitrary complexity,
although even functional complexity can go too far.  I tend to think
that's
 a long way however.

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

> See, this is exactly what I would want to avoid: Introducing a new
> feature "possible error report" just because of a (IMHO) design flaw of
> the underlying syntax which does not provide for robust error recovery.
> Why not rework the syntax instead: You get only benefits (simpler parser,
> syntax that is easier to understand, better error messages, most likely
> shorter runtime ...).

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.

> If people insist on using a plain text editor, they have to live with
> the consequences, as you said. (It's not _that_ bad, after all;
> zillions of programmers are stuck with stuff like this ;)

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

> view independent? Well, I actually wanted the *compiler* to insert
> missing declarations, not the editor. That's because the programmer
> must explicitly say "Now it's ready to give it a try", otherwise
> some confusion about premature actions taken by the editor might
> occur. You can see this nicely in Visual Studio: Quite often it
> starts updating some internal tables (or something similar, I
> really dunno) on some innocent mouse click and there is an annoying
> delay. The compiler also has most of the neccessary functionality
> already built in, so it need not be duplicated.

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.

> If you drag'n drop a class definition into the "parameters" section of
> your function's outline (thereby requesting a parameter of that type
> to be declared), the situation is reversed: Now the *editor* may (or
> may not, if you choose) propose some default name or default prefix
> for the item's name. This is OK because here the context is quite
> clear, the action is quickly performed and is confined to the
> immediate neighborhood of the cursor.

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.

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

> IMO the actual user interface
> with which the programmer is working every day should be as
> comfortable as possible. Every hour spent enhaceing the
> development environment will in the long run save much more
> time (and nerves) spent dealing with a less-than-perfect
> solution otherwise.

I agree, but I don't think it's a positive change.  My compromise would
use
 intelligent editors to improve the situation while retaining the
explicit
declaration characteristic.

>> Is this any different than a "variable unreferenced" warning message?
> Yes, it adds customising capabilities to the compiler,
> since it is then able to actively add info to the source
> code. Example: Unless you specify else, you won't be
> bothered with the same warning messages over and over
> again, because the compiler knows (from the comment it
> left in the source) that you already recognised that
> warning. You do not need to change the code yourself
> to explicitly disable that warning.

That's true, but you might not want it to disappear.  An intelligent
option
 to remove these errors/warnings at the programmer's request is what I
mentioned in my last message, and does a similar thing.

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.

> If this feature is done in a sensible way, I think many
> people will appreciate the enhanced ease of use. Of
> course, all this is just an option; you may as well
> perfer not to have the compiler change your code in
> any way.

Sure, but I don't even like the option there.  It's tempting to the
programmer, but it could cause bugs if done behind backs.  Even
stand-out
colours and stuff could be missed.

-- 
     Matthew Tuck - Software Developer & All-Round Nice Guy
             mailto:matty@box.net.au (ICQ #8125618)
       Check out the Ultra programming language project!
              http://www.box.net.au/~matty/ultra/