Class Browsers vs Static Types (Re: Inefficiency of __getattr__)

[Marcin 'Qrczak' Kowalczyk]

Followup-To: comp.lang.functional

Wed, 04 Oct 2000 19:03:50 +0200, Boris * (1+(is->cic)) <borcis at geneva-link.ch> pisze:

> > More errors are fixed at compile time, before testing.
> 
> Mmmhhh...:) one might be tempted to argue that this way of
> putting it is politically loaded in the direction of disallowing
> undecidable compilability...

It is not. There are Haskell extensions which make the type system
undecidable, and we sometimes use them.

Of course it is better when they are eliminated by designing an
appropriately constrained subset of the extension which is decidable.

> and before a language with such a feature, it becomes a bit of an
> abuse to distinguish compilation from testing, does it not ?

Why? An undecidable type system may fail to give any answer, but
when it does give one, it is accurate - if it says a program is type
correct, it is such for sure. It is not the case for testing.

> ...tempting to suggest that dynamic OO languages have natural and
> efficient class browsers and method editors where static typing
> languages have natural and efficient checks and error messages. Is
> that anywhere close to what you wanted to say with "more expressive
> tools" ?

Sorry, I should have said "language features" rather than "tools".
That a static type system at the same time rejects some correct
programs and gives more power to some old constructs.

But it indeed happens that I don't feel comfortable with complex GUIs
for editing programs, and prefer the style of batch compilation :-)
An interactive interpreter is good only for trying out new ideas
and small experiments, not for writing programs.

> This looks as if it could be universally assumed that typing bugs
> would translate to bugs during program execution if they weren't
> caught during compilation...

IMHO it is almost always true.

It is especially true for trivial bugs in boring programs. It is less
often true when trying to develop a library which reaches the borders
of expressiveness of the type system.

I have met two cases when the type system disallowed a particular
design. One is a statically typed HTML tree, where for the possibility
of "included" elements I could not find a better solution than to
group all elements ever "included" in the grammar in a single type
and use that type all over the tree. The other is the design of the
collection framework for Haskell, which uses a few complex language
extensions (two of which are not yet implemented in GHC, only in Hugs)
and still does not allow some sensible usages available in another
framework because it would add too much complexity.

Thousands of other complaints from type checkers were real bugs.
Some of them were obvious from the first sight, sometimes it took
several minutes to locate and fix it, but the fault was always on
my side.

> > One thing applying especially to Haskell:
> 
> Why Haskell and not OCaml ?

OCaml is not lazy, so the debugging output includes the whole
history of computing a value instead of only parts actually used, the
evaluation order is not interleaved with computing and using a value,
there are debuggers for it (although I haven't used one), and the
act of outputting a value does not change the behavior of the program.

OCaml is not pure, so it is easier to add debugging actions at any
place. Fortunately Haskell implementations do provide ways to attach
debugging output to pure values.

Since Haskell is lazy, it is common to put expressions of the form
(error "message") where the value should not be evaluated and trying
to evaluate it will be a bug in the program. It avoids the need to
invent an artificial values. Unfortunately in case of an error it does
not show why, how and where it was attempted to be evaluated. It also
prevents useful printing of structures containing such values. An OCaml
program would be forced to find a representation for these values and
place checks where values are used instead of where they are produced.

> So what we want is an analogue to debugging hooks... again, could
> the "programming language organ" that is an "inferred static typing
> system" not evolve to "a facility to throw tracing (e.g. recoverable)
> exceptions from a lexical distance" ?

I don't know what exactly do you mean, how could it look like.

> What if we assumed the real benefit (or reason for popularity) of
> dynamic OO languages to stem from a particular "implicit adequation"
> of "class & method-ic" division of code with IDE integration (and
> related advantages) ?

I believe that a reason of their popularity is that it's hard to design
a static type system for the usual OO style (Eiffel is trying and
has problems), so if people want OO, they tend to use dynamic typing.

OCaml has a good statically typed OO system, but AFAIK it is not used
much. Perhaps OCaml people prefer other ways to express their ideas,
and OO people find OCaml too exotic.

For designing a user interface the type system or lack of it is
probably not important, especially if the programmer does not write
physical code. But it is important for writing the engine.

-- 
 __("<  Marcin Kowalczyk * qrczak at knm.org.pl http://qrczak.ids.net.pl/
 \__/
  ^^                      SYGNATURA ZASTĘPCZA
QRCZAK