Mixed stuff

[Matthew Tuck]

Hans-Dieter Dreier wrote:

> I got a new nice language link on Haskell for the link collection:
> http://www-i2.informatik.rwth-aachen.de/Haskell/

Yes.  I'll add that.  I really have to improve on the paltry number of
language links there at the moment.

> But in this Eiffel page I looked at,
> the author stated that a parameterless function
> can actually be viewed as some form of a (read-only) member variable.

Actually, not necessarily read-only.  For example, look at C++'s
reference return values.  You could write a statement like:

hello(a) = 0

A more general alternative to this would be to define "get" and "set"
methods to emulate a variable, like many languages are doing now.

> This has the advantage that you can change
> the implementation of that "feature" (Eiffel speak for instance item)
> if you see that some compilation is needed

Not sure what you mean by "some compilation is needed".

> or want to write-protect the member variable,

I wouldn't favour this as a way of write protecting the variable.  A far
nicer way is to specify access mode in the type's method signature.  It
is not something the implementation should choose.

> without having to rewrite the classes' clients.

Swapping functions and variables is an important feature, since it
allows various changes in implementation.  You could calculate or
redundantly store some piece of information, for example the count of
members in a linked list.  Does it matter whether it's redundantly
stored (as a variable that is updated), or calculated (as a function)? 
No, and you should be able to change between them.  As another example,
you might to somehow compress the field to take less space.

> Q: How do you revent execution if you actually
> want a reference to the feature?
> A: Have the appropriate type (ref <type of the feature>)
> as a required type.

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.
 
> Q: Do you need to recompile clients?
> A: Yes, except when the VM would be able
> to insert the necessary dereferencing
> (which sounds rather messy to me).

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

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

I don't see this as true.  This is because I see this implementated as
having a get and set method in the class whether it is implemented as a
variable or real methods.  The type would not change, only the
implementation, and hence the server class would not change.  Only
inlining would force recompiles.

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

Languages which use multiple dispatch (choosing the method based on the
type of more than one parameter) do things this way.
 
> I'm thinking of automatic conversions, for example.
> Remember the old problem of dyadic operators
> which are commutative and
> take parameters of *different* types.

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.
 
> into account), but guess what happens if I hit
> Alt+F8 to pretty-format my source?
> Two lines become different just because of layout.
> I have to view them all,
> just to make sure not to miss a real change.

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.
 
> 2. Use of special characters.
> ...

This all sounds reasonable, but the fact is that people have widely
ranging opinions on things like this.  Everyone has different screens,
different fonts, different international conventions, different
mathematical and programming backgrounds, etc.

There really is no reason to enforce this sort of thing onto anyone.  As
long as it works with the underlying language (e.g. identifier
construction could affect the allowable grammar), it should be allowable
if its useful to the programmer.

No one is going to create a perfect syntax.  Choosing your own allows
you to tailor it for your own specific needs, and experiment to create
better syntaxes.  It's never been done before to my knowledge, so the
effects will be interesting.

> 3. A language should be designed to make
> it easy on the compiler, even if this means
> that the programmer has to write a little more.

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.

Functional complexity is not a bad thing - without it we would not be
where we are today.  Arbitrary complexity is the problem, and often it
can be removed, making things better for everyone.

> If you look at C++ error messages,
> you see what happens if this is not the case:
> Forget one { and you get *lots* of messages
> which are quite unrelated to the real error.

This is a problem with error recovery in all parsers, not C++.  There is
a tradeoff between reporting false errors and trying to report multiple
true errors.  I don't see it as a major problem - although perhaps a
"possible errors" comment could be useful, below which the status of the
error is not known.

> An (admittedly extreme) counterexample is Centura's 4GL,
> where you got to write "Set X = Y" for an assignment.
> At first I found that annoying, but I quickly got used to it.
> And it has the advantage that you *always* get
> ...

If you change to a structure editor I would imagine you wouldn't get
parse errors.  If we use a text based editor, the situation is really up
in the air.  The view writer would have to worry about such things as
error recovery.

> It's just that the compiler knows all it takes
> for a really intelligent guess: The name is known;
> the type can (usually) be inferred from the usage;
> access properties can be guessed as "local variable".
> I would like the compiler to insert that definition,
> flag it as "compiler generated" (shown in some other color, perhaps)
> and (optionally) issue a warning.

I don't know I'd go as far as making the compiler put it there, but what
we could do is to make it easier to manually generate declarations.  So
for example you might right-click on one or more unhooked variables and
choose "Generate Declaration(s)" from the popup menu.  Then you'll see
them and can change them.

Alternatively, you could right-click on error messages.  If there is a
known solution to the problem, such as "Generate Declaration", you could
choose it.  This could be applied to all manner of situations.  This
sort of thing is view-independent too, which is good.

> If the compiler finds a declaration that is no longer used,
> it should comment it out and mark that as "compiler generated";
> if the declaration was compiler generated in the first place,
> it should be removed completely instead.

This really seems like a lot of hassle to go to to avoid a small hassle.

> If the compiler generated items no longer apply due to a code change,
> they should be removed automatically during compilation.
> That would be a great auto-comment utility.
> If the programmer cares to read those items,
> he may even find logical errors in his program
> that would otherwise only show up during testing.

Is this any different than a "variable unreferenced" warning message?

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