Static typing

Dirk Thierbach dthierbach at gmx.de
Fri Oct 24 13:46:54 EDT 2003


Pascal Costanza <costanza at web.de> wrote:

>> I don't have pattern matching to use them efficiently, 

> http://www.cliki.net/fare-matcher

Certainly an improvement, but no way to declare datatypes (i.e.,
pattern constructors) yet:

  There also needs be improvements to the infrastructure to build
  pattern constructors, so that you may build pattern constructors and
  destructors at the same time (much like you do when you define ML
  types).

The following might also be a show-stopper (I didn't test it,
but it doesn't look good):

  ; FIXME: several branches of an "or" pattern can't share variables;
  ; variables from all branches are visible in guards and in the body,
  ; and previous branches may have bound variables before failing.
  ; This is rather bad.

The following comment is also interesting:

  Nobody reported using the matcher -- ML/Erlang style pattern
  matching seemingly isn't popular with LISP hackers.

Again, the way to get the benefits of "more expressive languages"
like ML in Lisp seems to be to implement part of them on top of Lisp :-)

>> and there is no automatic test generation (i.e., type checking) for
>> my datatypes.

> http://www.plt-scheme.org/software/mrflow/

I couldn't find any details on this page (it says "coming soon"), but
the name suggest a dataflow analyzer. As I have already said, the
problem with attaching static typing and inference to an arbitrary
language is that it is difficult to get it working without changing
the language design. Pure functional features make type inference
easy, imperative features make them hard. Full dataflow analysis might
help, but I'd have to look more closely to see if it works out.

- Dirk




More information about the Python-list mailing list