[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