RE: Undefined labels

RE: Undefined labels

[Manuel Fahndrich]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 1484 bytes --]


This is the standard example for why we need a local open in the language.

-Manuel


-----Original Message-----
From: Christian RINDERKNECHT [mailto:rinderkn@hugo.int-evry.fr]
Sent: Friday, November 12, 1999 8:48 AM
To: caml-redistribution@pauillac.inria.fr
Cc: caml-list@inria.fr
Subject: Re: Undefined labels


Hello,

> 	(Unix.fstat argument).st_kind
> 
> Here, the function returns a structure, st_kind
> is a label of that structure, but it is not known
> in the calling module. Is there a syntax for this?

Yes:

        (Unix.fstat argument).Unix.st_kind
                              ^^^^
because the compiler doesn't know in what module to look-up for label
[st_kind]. 


> Using 'open Unix' is unacceptable.

I also never use the "open" feature, but the consequence is, when using
nested records, I must qualify all the labels (as in your example),
and the code becomes unreadable.

I recently started using classes in order to avoid this practical
problem, since methods are in the scope of their object, not of the
module embedding their class.

But this doesn't work if the library you are using is not
object-oriented, of course:)

Best regards,

-- 

Christian

-----------------------------------------------------------------------
Christian Rinderknecht                     Phone +33 (0)1 60 76 44 43
Institut National des Télécommunications   Fax   +33 (0)1 60 76 47 11
Département Logiciels Réseaux (LOR)        WWW
9, Rue Charles Fourier, F-91011 Évry Cedex

RE: Undefined labels

[Brian Rogoff]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: TEXT/PLAIN; charset=X-UNKNOWN, Size: 1861 bytes --]

On Fri, 12 Nov 1999, Manuel Fahndrich wrote:
>
> This is the standard example for why we need a local open in the language.
>
> -Manuel

Let me second that motion. Coming from Ada, I always wondered why OCaml
doesn't allow you to restrict the scope of open, instead of putting it
always at module level.

-- Brian

>
>
> -----Original Message-----
> From: Christian RINDERKNECHT [mailto:rinderkn@hugo.int-evry.fr]
> Sent: Friday, November 12, 1999 8:48 AM
> To: caml-redistribution@pauillac.inria.fr
> Cc: caml-list@inria.fr
> Subject: Re: Undefined labels
>
>
> Hello,
>
> > 	(Unix.fstat argument).st_kind
> >
> > Here, the function returns a structure, st_kind
> > is a label of that structure, but it is not known
> > in the calling module. Is there a syntax for this?
>
> Yes:
>
>         (Unix.fstat argument).Unix.st_kind
>                               ^^^^
> because the compiler doesn't know in what module to look-up for label
> [st_kind].
>
>
> > Using 'open Unix' is unacceptable.
>
> I also never use the "open" feature, but the consequence is, when using
> nested records, I must qualify all the labels (as in your example),
> and the code becomes unreadable.
>
> I recently started using classes in order to avoid this practical
> problem, since methods are in the scope of their object, not of the
> module embedding their class.
>
> But this doesn't work if the library you are using is not
> object-oriented, of course:)
>
> Best regards,
>
> --
>
> Christian
>
> -----------------------------------------------------------------------
> Christian Rinderknecht                     Phone +33 (0)1 60 76 44 43
> Institut National des Télécommunications   Fax   +33 (0)1 60 76 47 11
> Département Logiciels Réseaux (LOR)        WWW
> 9, Rue Charles Fourier, F-91011 Évry Cedex
>

RE: Undefined labels

[Gerard Huet]

At 16:30 15/11/99 -0800, Brian Rogoff wrote:
>On Fri, 12 Nov 1999, Manuel Fahndrich wrote:
>> 
>> This is the standard example for why we need a local open in the language.
>> 
>> -Manuel
>
>Let me second that motion. Coming from Ada, I always wondered why OCaml
>doesn't allow you to restrict the scope of open, instead of putting it 
>always at module level.
>
>-- Brian
>

open is a facility that is convenient to the programmer because the code is
uncluttered with long explicit names, but it is of course a source of bugs.
The addition of a new binding in a module may change drastically the
semantics of modules which open it, in a way that stays unnoticed if types
match. 
Things would get worse with a local open. This reminds me of the old days
of Pascal, with the dreadful "with" construction which opened an implicit
scope (the field names of the corresponding record declaration) at this
point in the code. This made the scope structure dependent of the type
analysis in a global way, and thus broke an essential phase distinction for
the compiler. This was the source of unending headaches. For instance, it
was a cause of unnecessary complications in terminal recursion removal,
since the names of the formal parameters of procedures could be hidden at
the point of call by an intermediate with. 

GH

RE: Undefined labels

[David Brown]

Gerard Huet writes:
 > open is a facility that is convenient to the programmer because the code is
 > uncluttered with long explicit names, but it is of course a source of bugs.
 > The addition of a new binding in a module may change drastically the
 > semantics of modules which open it, in a way that stays unnoticed if types
 > match. 

One feature I like of Python and Erlang is a selective import.  It is
possible to specify only the items that you would like imported from a
module.  If you use the selective open, the open declaration itself
states which symbols come from that module.  Since the scope is
explicit, it makes it easy to tell where something is coming from.

I'm not familiar with the parser too much, but perhaps something like:

open (bleep, bloop, SubMod) Module;;

There probably should also be a way to open all of the constructors of
a type.

Dave Brown

RE: Undefined labels

[Anton Moscal]

On Mon, 15 Nov 1999, Brian Rogoff wrote:

> > This is the standard example for why we need a local open in the language.
> > 
> > -Manuel
> 
> Let me second that motion. Coming from Ada, I always wondered why OCaml
> doesn't allow you to restrict the scope of open, instead of putting it 
> always at module level.

This construction can be easy simulated by `let module' construction:

let open M in E 
 =>
let module _TEMP = struct 
   open M;
   let __RES = E
end
in __RES

I implement this conversion for my own use by camlp4 as syntax extension
(with other local declarations: let type, let exception, etc.)

Anton

Re: Undefined labels

[Markus Mottl]

> I'm not familiar with the parser too much, but perhaps something like:
> 
> open (bleep, bloop, SubMod) Module;;

I think there is not really a big difference to:

  let bleep = Module.bleep
  let bloop = Module.bloop
  module SubMod = Module.SubMod

The typing effort is nearly neglectible, especially if you use a convenient
editor. It also may make things clearer. In fact, your proposal would be
ambiguous, because it is not clear whether "bleep" is a function or a type
(different name spaces!).

> There probably should also be a way to open all of the constructors of
> a type.

Now this would not be so bad an idea, because often such types may have
quite many constructors and in general you need all of them at once.

Unfortunately, e.g.

  module M = struct type t = A | B end

  type u = M.t

will not do this for you.

What problems could arise if the semantics of "type" were changed to allow
"importing" constructors like this? - It looks pretty harmless at first
sight and would fit to the style of abbreviations used above...

Regards,
Markus Mottl

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

Packages?

[skaller]

Please correct me if I'm wrong, but my understanding is that
ocaml only searches for modules referenced  like:

	open X
	..
	Y.x

in the path given to the compiler. A recent addition to Python
has helped reduce module clutter; a related idea for ocaml is
as follows: given a module name:

	X.Y.Z

X must be on the path, as before, however, if it is a directory,
it is taken to be a module containing all modules contained
in the directory: say the files are Y.cmx, Y2.cmx, then it is
as if Y and Y2 were nested in X like

	(* X.ml *)
	module Y = ..
	module Y2 = ..

Given this construction, multimodule packages can be distributed
so they unpack into a single directory, reducing name clashes,
making upgrading and removal easier, and without needing
to continually fiddle with the search path. This feature works
well in Python. It requires no changes to the language (only
some changes to the compilation model).

By default, contributed packages with install options tend to
install themselves in the same place as the standard library.
This is unfortunate, because it is useful to totally wipe out
the whole ocaml distribution and rebuild it, which clobbers
any such contributed modules.

With the package system, a symbolic link could be used to
what Python calls 'site-packages', which is where contributed
modules are installed by default. In this case, the nice feature
is that a fresh ocaml would not contain contributed packages,
but they can be reinstated by reinstalling the old symbolic link.

-- 
John Skaller, mailto:skaller@maxtal.com.au
10/1 Toxteth Rd Glebe NSW 2037 Australia
homepage: http://www.maxtal.com.au/~skaller
voice: 61-2-9660-0850