Core Guile bindings

Core Guile bindings

[Panicz Maciej Godek]

I've noticed that Guile core contains some bindings that shouldn't
necessarily be globally available. In particular, it provides a set of
socket-related functions with very general names, such as "select" or
"bind", that some programmers may want to use for their own purposes.

It is obvious that those functions should not be a part of the core, and
should be moved to some separate module, and so I wanted to ask whether
there are any plans for doing so?

Re: Core Guile bindings

[Thompson, David]

On Wed, Oct 12, 2016 at 2:18 PM, Panicz Maciej Godek
<godek.maciek@gmail.com> wrote:
> I've noticed that Guile core contains some bindings that shouldn't
> necessarily be globally available. In particular, it provides a set of
> socket-related functions with very general names, such as "select" or
> "bind", that some programmers may want to use for their own purposes.
>
> It is obvious that those functions should not be a part of the core, and
> should be moved to some separate module, and so I wanted to ask whether
> there are any plans for doing so?

My understanding is that these symbols have been part of the default
environment for so long that a lot of code would break if they were
removed, so they will be staying for the foreseeable future.

- Dave

Re: Core Guile bindings

[Panicz Maciej Godek]

2016-10-12 20:21 GMT+02:00 Thompson, David <dthompson2@worcester.edu>:

>
> My understanding is that these symbols have been part of the default
> environment for so long that a lot of code would break if they were
> removed, so they will be staying for the foreseeable future.
>
>
On the other hand, the fix would usually be trivial (just one use-modules
clause), and besides I don't think that Guile has ever had a tradition of
worrying too much about backwards compatibility.

Re: Core Guile bindings

[Thompson, David]

On Wed, Oct 12, 2016 at 3:18 PM, Panicz Maciej Godek
<godek.maciek@gmail.com> wrote:
>
>
> 2016-10-12 20:21 GMT+02:00 Thompson, David <dthompson2@worcester.edu>:
>>
>>
>> My understanding is that these symbols have been part of the default
>> environment for so long that a lot of code would break if they were
>> removed, so they will be staying for the foreseeable future.
>>
>
> On the other hand, the fix would usually be trivial (just one use-modules
> clause), and besides I don't think that Guile has ever had a tradition of
> worrying too much about backwards compatibility.

The Guile maintainers care very much about backwards compatibility,
from what I've seen over the last few years.

- Dave

Re: Core Guile bindings

[Ludovic Courtès]

Hi!

"Thompson, David" <dthompson2@worcester.edu> skribis:

> On Wed, Oct 12, 2016 at 3:18 PM, Panicz Maciej Godek
> <godek.maciek@gmail.com> wrote:
>>
>>
>> 2016-10-12 20:21 GMT+02:00 Thompson, David <dthompson2@worcester.edu>:
>>>
>>>
>>> My understanding is that these symbols have been part of the default
>>> environment for so long that a lot of code would break if they were
>>> removed, so they will be staying for the foreseeable future.
>>>
>>
>> On the other hand, the fix would usually be trivial (just one use-modules
>> clause), and besides I don't think that Guile has ever had a tradition of
>> worrying too much about backwards compatibility.
>
> The Guile maintainers care very much about backwards compatibility,
> from what I've seen over the last few years.

I think I asked the same question as Panicz when I started using Guile
ca. 2004.  The situation of global bindings hasn’t changed since then,
and that’s for compatibility reasons that I very much appreciate as a
user.

Ludo’.

Re: Core Guile bindings

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1352 bytes --]


Ludovic Courtès writes:

> Hi!
>
> "Thompson, David" <dthompson2@worcester.edu> skribis:
>
>> On Wed, Oct 12, 2016 at 3:18 PM, Panicz Maciej Godek
>> <godek.maciek@gmail.com> wrote:
>>>
>>>
>>> 2016-10-12 20:21 GMT+02:00 Thompson, David <dthompson2@worcester.edu>:
>>>>
>>>>
>>>> My understanding is that these symbols have been part of the default
>>>> environment for so long that a lot of code would break if they were
>>>> removed, so they will be staying for the foreseeable future.
>>>>
>>>
>>> On the other hand, the fix would usually be trivial (just one use-modules
>>> clause), and besides I don't think that Guile has ever had a tradition of
>>> worrying too much about backwards compatibility.
>>
>> The Guile maintainers care very much about backwards compatibility,
>> from what I've seen over the last few years.
>
> I think I asked the same question as Panicz when I started using Guile
> ca. 2004.  The situation of global bindings hasn’t changed since then,
> and that’s for compatibility reasons that I very much appreciate as a
> user.

What would be possible without breaking backwards compatibility is
moving them ino a module which is imported by default, with a way to
suppress those default imports.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Core Guile bindings

[Panicz Maciej Godek]

2016-10-13 20:19 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:

>
> What would be possible without breaking backwards compatibility is
> moving them ino a module which is imported by default, with a way to
> suppress those default imports.
>
> I think it is a very nice idea. Guile could install with "configurations",
and the default configuration would just load the modules to make all
currently global bindings available, but users could tweak their
configurations in their ~/.guile files, supressing that default
configuration. Or they could change it system-wide, provided that there are
no dependencies in current guile scripts that could break anything.

Re: Core Guile bindings

[Arne Babenhauserheide]

[-- Attachment #1: Type: text/plain, Size: 1346 bytes --]


Panicz Maciej Godek writes:

> 2016-10-13 20:19 GMT+02:00 Arne Babenhauserheide <arne_bab@web.de>:
>
>>
>> What would be possible without breaking backwards compatibility is
>> moving them ino a module which is imported by default, with a way to
>> suppress those default imports.
>>
>> I think it is a very nice idea. Guile could install with "configurations",
> and the default configuration would just load the modules to make all
> currently global bindings available, but users could tweak their
> configurations in their ~/.guile files, supressing that default
> configuration. Or they could change it system-wide, provided that there are
> no dependencies in current guile scripts that could break anything.

To some degree this is already the case for interactive mode (so this is
not really my idea, just an application of what’s already there).

We might need an option to suppress loading the default modules, though,
similar to the -Q in emacs (which I use to make it start faster when I
just need basic editing capabilities).

However I think removing things from the existing default behaviour
should never be automatic, otherwise people won’t be able to rely on the
Guile on another system behaving as expected.

Best wishes,
Arne
-- 
Unpolitisch sein
heißt politisch sein
ohne es zu merken

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 818 bytes --]

Re: Core Guile bindings

[Robin Templeton]

Arne Babenhauserheide <arne_bab@web.de> writes:

> Ludovic Courtès writes:
>
>> Hi!
>>
>> "Thompson, David" <dthompson2@worcester.edu> skribis:
>>
>>> On Wed, Oct 12, 2016 at 3:18 PM, Panicz Maciej Godek
>>> <godek.maciek@gmail.com> wrote:
>>>>
>>>>
>>>> 2016-10-12 20:21 GMT+02:00 Thompson, David <dthompson2@worcester.edu>:
>>>>>
>>>>>
>>>>> My understanding is that these symbols have been part of the default
>>>>> environment for so long that a lot of code would break if they were
>>>>> removed, so they will be staying for the foreseeable future.
>>>>>
>>>>
>>>> On the other hand, the fix would usually be trivial (just one use-modules
>>>> clause), and besides I don't think that Guile has ever had a tradition of
>>>> worrying too much about backwards compatibility.
>>>
>>> The Guile maintainers care very much about backwards compatibility,
>>> from what I've seen over the last few years.
>>
>> I think I asked the same question as Panicz when I started using Guile
>> ca. 2004.  The situation of global bindings hasn’t changed since then,
>> and that’s for compatibility reasons that I very much appreciate as a
>> user.
>
> What would be possible without breaking backwards compatibility is
> moving them ino a module which is imported by default, with a way to
> suppress those default imports.

This is already how it works internally -- the default bindings are
stored in the (guile) module. You can use define-module's #:pure option
to suppress the default import and start with an empty module.

-- 
Inteligenta persono lernas la lingvon Esperanton rapide kaj facile.
Esperanto estas moderna, kultura lingvo por la mondo. Simpla, fleksebla,
belsona, Esperanto estas la praktika solvo de la problemo de universala
interkompreno. Lernu la interlingvon Esperanton!

Re: Core Guile bindings

[Andy Wingo]

On Wed 12 Oct 2016 20:18, Panicz Maciej Godek <godek.maciek@gmail.com> writes:

> I've noticed that Guile core contains some bindings that shouldn't
> necessarily be globally available. In particular, it provides a set of
> socket-related functions with very general names, such as "select" or
> "bind", that some programmers may want to use for their own purposes.
>
> It is obvious that those functions should not be a part of the core, and
> should be moved to some separate module, and so I wanted to ask whether
> there are any plans for doing so?

Besides everything that everyone said -- I actually think that it *is*
possible to migrate bindings over time.  In 2.2 I have moved the threads
exports (current-thread, call-with-new-thread, lock-mutex, etc) to
(ice-9 threads).  However when built with deprecated code (the default),
we also export these bindings in (guile).  They cause a deprecation
warning if you use them, telling you to change your program to
explicitly use (ice-9 threads).  So migration of this kind is possible;
even within the 2.2 series more code can be put into modules.

That said while I think reducing the set of default bindings is a good
it is not without tradeoffs.  Modularizing guile's core bindings isn't
really an active development focus.

Of course there are mitigations as well also; defining "select" in your
module works just fine, exporting it works fine, and users can resolve
the conflicts if needed.  You also have #:replace if you think that your
module should be the one making that decision.

Andy