caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
From: Yotam Barnoy <yotambarnoy@gmail.com>
Cc: caml users <caml-list@inria.fr>, Jeremy Yallop <yallop@gmail.com>
Subject: Re: [Caml-list] Warnings opening modules (was: why is building ocaml hard?)
Date: Tue, 19 Jul 2016 12:37:27 -0400	[thread overview]
Message-ID: <CAN6ygO=ggyNYsJRtC3CGVN4ghO+GV-j9cbA5OLjD-CczTgCzZg@mail.gmail.com> (raw)
In-Reply-To: <CAJgjwehskByKQXr2Qv6v7kp00rhxExLEhBbsBoUgTqQcB-gm6w@mail.gmail.com>

Jeremy, how about taking a page from haskell, and having

type t = A.t(..)

This would import the same constructors locally. It also means we have
the full functionality covered, in terms of both opens and creating
limited local modules:

haskell:
import A(foo, bar, T(..))

ocaml:
let foo, bar = A.(foo, bar)
type t = A.t(..)

haskell:
import qualified LongA(foo, bar, T(..)) as A

ocaml:
module A = struct LongA.(let foo, bar = foo, bar type nonrec t = t(..)) end

It's still more verbose (especially the limited-qualified module) but
at least it's decent.



On Sat, Jul 16, 2016 at 5:58 AM, vrotaru.md@gmail.com
<vrotaru.md@gmail.com> wrote:
>
> About that missing type constructors problem. Seems doable:
>
> module A = struct
>   module T = struct
>     type t1 = ...
>     type t2 = ...
>   end
>   include T
>
>   let foo _ = ...
>   let bar : t2 -> t1  = ...
> end
>
> module B = struct
>
>   include A.T
>   let foo, bar = A.( foo, bar )
>
> end
>
> Obviously, not for already existing code.
>
> În sâm., 16 iul. 2016 la 10:41, Petter A. Urkedal <paurkedal@gmail.com> a
> scris:
>>
>> On 15 July 2016 at 18:13, Hendrik Boom <hendrik@topoi.pooq.com> wrote:
>> > And that's a real problem -- that fact that openning a module can fill
>> > the namespace with lots of stray identifiers, which the user does not
>> > control.
>>
>> Apart from the selective opens discussed, it would be good to tell
>> apart which modules are meant to be open and which are intrusive
>> without looking through them.  Most importantly the writer of the
>> library should be clear about it from the start when designing a
>> module, then the names will be consistent with the choice, and users
>> should be able to decide without evaluating the whole interface.
>>
>> A warning when opening an invasive module in a global scope could
>> help, as well.  One could maybe decide a module to be invasive from a
>> few heuristics with fall-back to a declaration:
>>
>> - A module interface defining a single-letter identifier, most
>> importantly a type "t" or a signature "S", is invasive.
>> - A module interface overriding any operator (or identifier?) defined
>> in Pervasives is invasive.
>> - A module interface declaring itself `[@@@ocaml.invasive]` is invasive.
>>
>> Conversely the user may silence the warning with `open M
>> [@@ocaml.invasive]`.
>>
>> --
>> Caml-list mailing list.  Subscription management and archives:
>> https://sympa.inria.fr/sympa/arc/caml-list
>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners
>> Bug reports: http://caml.inria.fr/bin/caml-bugs

      reply	other threads:[~2016-07-19 16:37 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-07-10 11:57 David Allsopp
2016-07-10 19:45 ` Gerd Stolpmann
2016-07-13 12:08   ` David Allsopp
2016-07-13 12:20     ` Gerd Stolpmann
2016-07-13 12:30       ` David Allsopp
2016-07-14  9:03     ` Goswin von Brederlow
2016-07-15  9:52       ` David Allsopp
2016-07-15 16:13         ` Hendrik Boom
2016-07-15 16:57           ` Yotam Barnoy
2016-07-15 18:09             ` Jeremy Yallop
2016-07-15 18:26               ` Hendrik Boom
2016-07-15 18:58               ` Yotam Barnoy
2016-07-15 19:26                 ` Hezekiah M. Carty
2016-07-15 19:42                   ` Yotam Barnoy
2016-07-15 19:52                     ` Jeremy Yallop
2016-07-15 20:25                       ` Yotam Barnoy
2016-07-15 18:50             ` Alain Frisch
2016-07-15 19:44               ` Hendrik Boom
2016-07-15 17:04           ` Gerd Stolpmann
2016-07-20  7:49             ` Louis Gesbert
2016-07-16  7:40           ` Petter A. Urkedal
2016-07-16  9:58             ` vrotaru.md
2016-07-19 16:37               ` Yotam Barnoy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to='CAN6ygO=ggyNYsJRtC3CGVN4ghO+GV-j9cbA5OLjD-CczTgCzZg@mail.gmail.com' \
    --to=yotambarnoy@gmail.com \
    --cc=caml-list@inria.fr \
    --cc=yallop@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).