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: rename from q to queue

[Mathieu Lirzin]

Hello,

ra...@openmailbox.org writes:

> The following library uses a pun writing 'q' instead of 'queue':
> 
>
> I propose renaming the module from (ice-9 q) to (ice-9 queue) and
> spelling queue throughout in the usual scheme style of using full
> words.
>
> Attached is a patch that does this. If there is a positive consensus
> on the rename I am happy to apply the change to all the documentation
> and tests too.

As stated on IRC I think it is an improvement to have a meaningful name
for this module.

However as pointed in other replies, It is not possible to implement it
this way because (ice-9 q) is a public API.

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.

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?

-- 
Mathieu Lirzin