Re: [newbie] Define and use records in sum types

[Markus Mottl <mottl@miss.wu-wien.ac.at>]

On Sat, 22 Jul 2000, Frank Atanassow wrote:
>  > But how about "capturing logical invariants"? You need both ways of
>  > information hiding there: restricting the number of exported functions
>  > *and* restricting their types! Otherwise there could be ways to destroy the
>  > invariant.
> 
> Can you be more specific about "capturing logical invariants"? I don't know
> quite what you mean.

If you have axioms that specify invariant properties about the types and
functions in question. E.g. that removing an element from a set results
in a set that does not contain it and that this is true for all sets.

Exporting auxiliary functions from the module might allow the programmer
to violate this condition. The same is true for not restricting the types
of the functions. Therefore, you need both means of information hiding to
guarantee correctness (i.e. the properties in question).

> An instance I can think of where access to names could have semantic
> significance is if it has to do with generativity. I hate generativity with a
> passion, but eliminating it from ML modules would require a wholesale revision
> of the module system, which it is not my object to propose here. So, I will
> concede that generativity may cause name access to acquire semantic
> significance. (But I hope you agree that it is at least desirable that names
> and namespaces should have no semantic significance whatsoever.)

I guess you mean that it is only the structure of the module that counts
and not the naming? But how about ambiguities then? You need a way to
refer to the right function, whatever, if it has the same signature as
another one.

>  > I'd rather use different namings like "r1_name" and "r2_name" for the
>  > field: although this requires me to always include the name of the type,
>  > one cannot get confused either: it makes the sources easier to understand.
> 
> I don't find that argument very convincing; Ocaml _already_ allows type, value
> and field label definitions to shadow each other, which many people consider a
> cognitive burden. I don't have an opinion on that issue; I'm just trying to be
> consistent with the way Ocaml treats bindings currently, and add a little bit
> more flexibility.

There's not much you can do about shadowing of value bindings unless you
prohibit it which would cause other problems: you'd have to invent a new
name each time even if you just want to "transform" a value using the same
name - this could cause horror if you wanted to add such a transformation
in the middle of a function body...

What concerns type names: I guess this is a consequence of having
an "open"-statement for modules, which shadows previous type
declarations. Otherwise, forbidding it would probably be a good idea
since its scope is the whole module from the point of definition.

Now, accessing fields more flexibly is surely possible. The question is
whether adding this feature is really of so much help: the only case
where it pays off is when you have large records which share a great
deal of names. Then it might be a bit more convenient to have an initial
declaration that tells the compiler what kind of record you are talking
about instead of inventing new names for records. A rather statistical
question...

> In fact, I don't see how this makes programs any less readable.

It adds another construct that people have to learn. Reading constructs
that you are not familiar with is confusing. I bet that there are plenty
of people who do not even know about the "with"-construct for records...

> If you don't add this mechanism, then the rule remains, "an identifier X
> refers to the last definition of X in scope".

Yes.

> If you do add this mechanism, then that doesn't change (since the identifier
> [path] "t.x" is still distinct from "x").

Right. But you have to invent additional syntax for doing this. Even
though it seems to be a rather marginal addition, it also adds to making
the language more complex. I haven't felt the need for it so far, but
if other people have other requirements, they are free to ask for it...

Regards,
Markus Mottl

-- 
Markus Mottl, mottl@miss.wu-wien.ac.at, http://miss.wu-wien.ac.at/~mottl