Summary of current change suggestions

[Marcin 'Qrczak' Kowalczyk]

Wed, 21 Feb 2001 15:51:35 -0700, Alastair Reid <reid at cs.utah.edu> pisze:

> User defined defaults are really tempting to add (my component
> programming language had them briefly and I am under constant
> pressure to add them back in) but they are kinda messy because:

They are sometimes bessy, but it's not that bad in this case.

Think about the FFI defaults as special variable definitions which
are spelled differently, and proper FFI declarations that use whatever
special variables are in scope.

> 1) You have to resolve (or forbid) use of multiple defaults.

Forbid. You can't have two variables with the same name at the toplevel.

> 2) You need a way to override the default.
>    Do you override the whole default (includes, libraries, etc.) at once or
>    only the bits you don't specify.

Only the bits you don't specify. You can shadow a name locally
(as in SML's 'local' declarations which create a local environment
for some definitions).

> 3) A small change to code in one place can have unexpected results (and it is
>    hard to detect the consequences using typechecking or from a failed link or
>    whatever).

The same can be told about changing a function body. It influences
the meaning of all code which uses it.

> 4) Cutting and pasting some code from one context to another context results in
>    very different behaviour because the defaults don't carry over.

The same can be told about the environment of defined names. You
can't cut and paste without considering the visible names anyway.

A difference between FFI defaults and Haskell 'default' is that it
is used in clearly visible places - foreign declarations - and not
at any point the type inference has a specific problem.

Specifying include files in each foreign declaration is not an option.
We must have a foreign declaration which tells something about the
context in which this module and modules importing this module must
be compiled.

Instead of 'foreign context' or 'foreign language' we may use
'foreign default' and think about it as specifying the defaults which
could be specified in foreign declarations if somebody really wanted
I.e. using 'foreign default' is not mandatory - you could write
everything at each foreign declaration if you wish.

I think that the set of attributes is open enough that we must design
some keyword/value scheme or such, insead of relying on extending the
grammar each time a new kind of attribute is needed.

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