Re: rename from q to queue

[Christopher Allan Webber]

Ludovic Courtès writes:

> Mathieu Lirzin  skribis:
>
>> One way to not break backward compatibility, would be to move (ice-9 q)
>> code in (ice-9 queue) and make (ice-9 q) use it and re-export every
>> variable with its old name.
>
> Right.
>
>> Finally we will need a way to give the information that (ice-9 q) module
>> is deprectated to the users.  I am not sure what is the best way to
>> achieve this.  Maybe with:
>>
>>   (eval-when (expand load eval)
>> (display "..." (current-warning-port)))
>>
>> What do others think?
>
> We could do a quick hack to iterate over the exported bindings,
> re-export them, and print a message.
>
> However, I think it would be best to have a mechanism in the module
> abstraction to /declare/ renames.  That would allow both the compiler
> and the run-time support to emit an appropriate warning.
>
> This would require something like adding a special field to ‘module’
> records, such that one can write, say:
>
>   (define-module (ice-9 q)
> #:superseded-by (ice-9 queue))
>
> With that in place, it will become much easier to discuss about ice-9
> renames, IMO.
>
> Thoughts?
>
> Thanks,
> Ludo’.

I think that would be useful.  There's been talk about renaminig things
from (ice-9) into a (guile) namespace.  Likewise aliasing things from
(srfi) to something more human-readable.  Are the rename and aliasing
thing the same step or two different things?

Re: rename from q to queue

[Ludovic Courtès]

Mathieu Lirzin  skribis:

> One way to not break backward compatibility, would be to move (ice-9 q)
> code in (ice-9 queue) and make (ice-9 q) use it and re-export every
> variable with its old name.

Right.

> Finally we will need a way to give the information that (ice-9 q) module
> is deprectated to the users.  I am not sure what is the best way to
> achieve this.  Maybe with:
>
>   (eval-when (expand load eval)
> (display "..." (current-warning-port)))
>
> What do others think?

We could do a quick hack to iterate over the exported bindings,
re-export them, and print a message.

However, I think it would be best to have a mechanism in the module
abstraction to /declare/ renames.  That would allow both the compiler
and the run-time support to emit an appropriate warning.

This would require something like adding a special field to ‘module’
records, such that one can write, say:

  (define-module (ice-9 q)
#:superseded-by (ice-9 queue))

With that in place, it will become much easier to discuss about ice-9
renames, IMO.

Thoughts?

Thanks,
Ludo’.

Re: anyone define port types?

[Ludovic Courtès]

Hey!

Andy Wingo  skribis:

> I am working on improving our port implementation to take advantage of
> the opportunity to break ABI in 2.2.  I am wondering how much I can
> break C API as well -- there are some changes that would allow better
> user-space threading
> (e.g. http://thread.gmane.org/gmane.lisp.guile.devel/14158/focus=15463
> or Chris Webber's 8sync).  But those changes would require some
> incompatible changes to the C API related to port internals.  This API
> is pretty much only used when implementing port types.  So, I would like
> to collect a list of people that implement their own ports :) I know
> Guile-GNOME does it for GNOME-VFS, though GNOME-VFS is super-old at this
> point...  Anyway.  Looking forward to your links :)

What do you conclude from this poll?  :-)

>From what you’ve seen, how do you think current uses would impact the
refactoring work (and vice versa)?

Thanks,
Ludo’.

Re: thoughts on top-level and cross-module inlining

[Ludovic Courtès]

Hello!  :-)

Andy Wingo  skribis:

> So, we have two questions, then: firstly, what semantic change can we
> make to the language to permit top-level and cross-module inlining?
> Secondly, how do we implement it?

As I view it, the first step would be to allow intra-module inlining
(inlining of unassigned private top-level bindings within the module.)
It seems to me that this would have little impact on semantics; there is
still the occasional, but not so rare, uses of @@ to bypass module
boundaries that we want to allow, though.

IMO a guiding principle should be that top-level inlining can always be
disabled.  This “backdoor” as you write is important for many current
uses (Geiser, monkey-patching of third-party modules, etc.)

> On the semantic side, I propose to add a field in modules indicating
> whether the module permits its top-level references to be inlined.

That sounds like a good idea for cross-module inlining!

I wonder if a separate way to annotate candidates to intra-module (but
not necessarily cross-module) inlining would be needed.  Maybe something
like the ‘declare’ forms found in CL and in some Schemes?

> Let us assume that assigned bindings are not available for inlining, but
> that declarative bindings can be inlined.  Then, a program with inlining
> will be the same as a program without inlining if declarative bindings
> are never assigned from outside their compilation unit.  That is what is
> meant by "used conventionally", and I think it reflects standard Guile
> usage, especially where modules are mostly compiled entirely within one
> compilation unit.
>
> (We should make an enhancement to the compiler to emit a warning when a
> declarative binding is used unconventionally.  Perhaps we should emit a
> warning whenever an imported binding is "set!", perhaps with a view
> towards enforcing conventional usage; but I don't know, we always want
> to have a back-door I think to allow Guile hackers to heal broken
> programs while they are running.)

I think we want to preserve the ability to ‘set!’ third-party bindings,
indeed, in those cases where that is considered more important than
inlining.  But I agree that being able to flag such unconventional usage
with compiler warnings would be helpful.

My 2¢,
Ludo’.