Re: [PATCH, doc RFA] Add guile gdb parameter support

Re: [PATCH, doc RFA] Add guile gdb parameter support

[Doug Evans]

+ guile-user for more eyes

On Mon, May 26, 2014 at 3:03 PM, Ludovic Courtès <ludo@gnu.org> wrote:
> Hi, Doug,
>
> Doug Evans <xdje42@gmail.com> skribis:
>
>> +@deffn {Scheme Procedure} parameter? object
>> +Return @code{#t} if @var{object} is a @code{<gdb:parameter>} object.
>> +Otherwise return @code{#f}.
>> +@end deffn
>
> There’s the problem that in Guile “parameters” are something different,
> and ‘parameter?’ is already provided by core Guile (info "(guile)
> Parameters").
>
> Unless “parameter” is the official (public) name for this in GDB, I’d
> recommend using a different name in the API, perhaps “knob” or something
> like that.  WDYT?

"parameters" is what the python side calls them, I think the name in
gdb is pretty concrete.
Not entirely so, but using a different name isn't without its own problems.

fwiw, and I know a lot don't like this approach,
but I personally intend to always import the gdb module with a gdb: prefix.

As you know, we also have the problem with symbol?.

A flat symbol namespace is going to have problems regardless, and I
like the prefix approach.
People don't want it to be the default though.

We're pretty much on our own though.
No one else on @gdb-patches is going to have an opinion (he boldly says :-)).
If you think gdb:parameter? vs guile's parameter? is materially
different than the current gdb:symbol? vs symbol? collision then I'm
happy to revisit and think about knobs more.

But I'd also like to hear your thoughts on the general solution of
just saying the convention is to important the gdb module with a gdb:
prefix.
I think it's reasonable to assume this issue will arise again, and
who's to say guile 3.0 won't have its own knobs. :-)

Re: [PATCH, doc RFA] Add guile gdb parameter support

[Ludovic Courtès]

Doug Evans <xdje42@gmail.com> skribis:

> + guile-user for more eyes
>
> On Mon, May 26, 2014 at 3:03 PM, Ludovic Courtès <ludo@gnu.org> wrote:
>> Hi, Doug,
>>
>> Doug Evans <xdje42@gmail.com> skribis:
>>
>>> +@deffn {Scheme Procedure} parameter? object
>>> +Return @code{#t} if @var{object} is a @code{<gdb:parameter>} object.
>>> +Otherwise return @code{#f}.
>>> +@end deffn
>>
>> There’s the problem that in Guile “parameters” are something different,
>> and ‘parameter?’ is already provided by core Guile (info "(guile)
>> Parameters").
>>
>> Unless “parameter” is the official (public) name for this in GDB, I’d
>> recommend using a different name in the API, perhaps “knob” or something
>> like that.  WDYT?
>
> "parameters" is what the python side calls them, I think the name in
> gdb is pretty concrete.
> Not entirely so, but using a different name isn't without its own problems.

Yes, surely.

> fwiw, and I know a lot don't like this approach,
> but I personally intend to always import the gdb module with a gdb: prefix.

Yes.

[...]

> But I'd also like to hear your thoughts on the general solution of
> just saying the convention is to important the gdb module with a gdb:
> prefix.

I generally agree with the idea that name clashes are best handled via
module renamers.

I also think it’s convenient when obvious name clashes are avoided
altogether.  For instance, at the GDB prompt, it’s easier if you just
have to type “guile (use-modules (gdb))” instead of the longer thing.

So I’d really consider name issues on a case-by-case basis.

Back to this particular case, if the Python API already uses the term
“parameter”, that’s probably enough to argue that the Guile API should
use that name as well.

Thanks,
Ludo’.