octave-maintainers
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: help --list incorrect on stable


From: Rik
Subject: Re: help --list incorrect on stable
Date: Tue, 17 Jan 2017 11:49:58 -0800

On 01/17/2017 11:04 AM, Mike Miller wrote:
> On Tue, Jan 17, 2017 at 10:11:47 -0800, Rik wrote:
>> The issue is that the internal function __keywords__ does not include items
>> like classdef, endmethods, etc.  I think there's a lot of cruft in help.cc
>> at this point.  Is there any reason not to replace the call to __keywords__
>> with iskeyword which returns a true list of what the parser knows?
> As a data point, it seems extremely counterintuitive to me that
> iskeyword() returns a list of keywords. But I see that is done for
> Matlab compatibility. OTOH, I have found the __keywords__,
> __operators__, and __builtins__ functions to be very useful.
>
> Looking through Octave itself, I see only one place where iskeyword() is
> used to return a list of keywords, and 5 places where __keywords__() is
> used. So it seems that others agree.

I'm not sure it is agree, as much as the fact that most of this code was
written a long time ago and pre-dates iskeyword returning a cellstr.  Of
course, one could use DEFALIAS to alias __keywords__ to iskeyword if you
want to maintain a C++ entry point.

>
>> On the development branch, would there be any problem removing functions
>> like __keywords__, __operators__ from C++ and making them m-files in
>> scripts/help?  They just seem to return a cellstr and it would be easier if
>> these were m-files.
> I agree with deduplication like this where possible. I also wonder if it
> might be a useful feature that these are built-in functions that are
> available even if the load path is undefined.
>
> What if both iskeyword and __keywords__ were refactored to call the same
> library function defined in the parser? Such a function might also be
> useful to users of the C++ API for embedding the Octave interpreter.
>

Could do, but I do think C++ is harder to maintain than an m-file.  And I
don't see it as being worthwhile to spend a lot of programmer time on
corner cases which could easily be worked around in other ways.  Having an
interpreter running where PATH has been re-defined to exclude the default
scripts is possible.  But in this case, the 'help' function wouldn't work
anyways since it is defined in scripts/help/help.m.  In that case, it
wouldn't matter that __keywords__ or __operators__ was an m-file because
'help --list' would fail.

--Rik




reply via email to

[Prev in Thread] Current Thread [Next in Thread]