[m-dev.] Patch: Tcl/Tk interface without '%' prompt

[Julien Fischer]

On Thu, 18 Jan 2007, Jonathan Morgan wrote:

> On 1/17/07, Julien Fischer <juliensf at csse.unimelb.edu.au> wrote:
>> 
>> On Wed, 17 Jan 2007, Jonathan Morgan wrote:
>> 
>> > On 1/17/07, Jörg Roman Rudnick <joerg.rudnick at t-online.de> wrote:
>> >> Next comes the revised Tcl/Tk-Interface, which I propose to be placed in
>> >> a new namespace - tcl. .../tk. ... - to prevent collisions with mtcltk.
>> >> .../mtk. ... . Certainly, there some questions remaining which I will
>> >> pose soon.
>> >
>> > I feel fairly strongly that wrapper libraries should retain their
>> > proper name (e.g. tcl, tk), rather than assuming a name like mtk,
>> > mtcltk, mogl, etc.  The only potential problem with this naming that I
>> > can think of is if it ends up with two libraries with the same name
>> > and a different path, confusing the linker.
>> 
>> The usual technique is to create a package, say mercury_tcltk, and
>> the overall library will named that.  By wrapper libraries above
>> you are presumably referring to the actual module names?
>
> By wrapper library, I am referring to a Mercury library which provides
> a Mercury interface to an existing C library.  I think that the
> (module) name should be the name of the library the module is
> wrapping.
>
> With regard to mercury_tcltk and similar libraries, I think that the
> name should be unnecessary (I already know that I'm using Mercury),
> and I can't see that it helps (the manual isn't very clear, but I
> don't think that the importing it will cause the imported libraries
> (e.g. mtcltk, mtk) to be imported into the calling module.  My memory
> is also that the samples imported mtcltk and mtk directly, rather than
> going through mercury_tcltk.

That's not why use mercury_tcltk.  You can think of it as a substitute
for the package mechanism that Mercury doesn't have - it's just
a convenient way of grouping modules together into a single library.

Arranging them in a hierarchy of sub-modules might seem more natural
but when many of those bindings were originally written sub-modules
hadn't been implemented.

> With regard to naming, I think that the Tcl wrapper module should be
> called 'tcl' and the Tk interface built on it should be called 'tk',
> possibly also containing sub-modules as necessary.  There should be no
> necessity for some kind of a wrapper module with imports like
> mercury_tcltk.  I certainly intend to have the Gtk+ modules using
> module names 'gtk', 'glib', and similar.

As separate libraries?  Even in that case I would still import them
into a dummy package(s) whose name gives some indication that they
are Mercury bindings; I certainly have enough things installed on
my system that match libgtk* to begin with.

Julien.