long-options

[Ralf Hemmecke]

Based on a recent suggestion on fricas-devel, this patch allows to use
double dashes for long options (option names with more than one letter).
Furthermore, it introduces the options --help and --version.
The --version option is programmed in such a way that neither FRICASsys
nor sman are started.

Would be good if "fricas --version" would not only print "FriCAS 1.3.5",
but also "based on SBCL 1.5.8" without calling FRICASsys or sman.

Any suggestions?
Would I have to fetch that information at install time by running

FRICASsys --eval ')lisp (lisp-implementation-type)' --eval ')lisp
(lisp-implementation-version)' --eval ")quit"

and put it as variables into the fricas script?


Current code is at the top commit of my long-options branch.

https://github.com/hemmecke/fricas/commits/long-options

Ralf

[Waldek Hebisch]

I feel that this is overreaction. GNU folks have reason to use
two dashes, AFAICS we do not. IMO, reasonable change would
be to replace current "catch all" item by help, that is
unrecognized option (including '--help') would print help.

Concerning '--version', it is _preferable_ to implement it
by calling 'FRICASsys' with appropriate option. ATM passing
options to 'FRICASsys' is problematic, but probably '--version'
could be done similarly to '-eval'.

--
Waldek Hebisch

[Ralf Hemmecke]

> I feel that this is overreaction. GNU folks have reason to use two
> dashes, AFAICS we do not.

Of course, there is no need to do so, but many people nowadays expect
long options with double dashes. I don't know why we must stick to the
old system.

> IMO, reasonable change would be to replace current "catch all" item
> by help, that is unrecognized option (including '--help') would print
> help.

Yes also possible.

> Concerning '--version', it is _preferable_ to implement it by calling
> 'FRICASsys' with appropriate option. ATM passing options to
> 'FRICASsys' is problematic, but probably '--version' could be done
> similarly to '-eval'.

Honestly, no user must know about FRICASsys, so putting version
information into the script is perfectly OK.

Nevertheless, I would have nothing against also allowing a --version
option for FriCASsys. I am even in favour of adding such an option.

BTW, why is passing options to FRICASsys problematic. As you see from my
patch, I allowed -eval and --eval. And that seems to work at least on my
computer.

Ralf

PS: I've just proposed another patch that gives

%>fricas --version
FriCAS 1.3.6
based on sbcl 1.5.8

information is taken from the 'configure' call, i.e., does not need
FRICASsys.
https://github.com/hemmecke/fricas/commits/long-options

[Waldek Hebisch]

On Fri, Jul 31, 2020 at 11:21:49PM +0200, Ralf Hemmecke wrote:
> > I feel that this is overreaction. GNU folks have reason to use two
> > dashes, AFAICS we do not.
>
> Of course, there is no need to do so, but many people nowadays expect
> long options with double dashes. I don't know why we must stick to the
> old system.

Single dash is widely used for options. The main reason for
double dash was that folks wanted to add new options that
did not fit existing single dash usage. Nobody sane wants
to remove single dash options from existing programs, so to
allow co-existence double dash is used. We do not have
such problem, our single dash options have room for expansion.
Concerning expectation, people who actually use options
will expect single dash options. Simple reason to prefer
single dash is that it is shorter. Another is that this
is what we use. Change would introduce confusion.

Note: '--version' is somewhat special and it is new, so
double dash is reasonable here (however, using '-version'
would be reasonable too).

> > IMO, reasonable change would be to replace current "catch all" item
> > by help, that is unrecognized option (including '--help') would print
> > help.
>
> Yes also possible.
>
> > Concerning '--version', it is _preferable_ to implement it by calling
> > 'FRICASsys' with appropriate option. ATM passing options to
> > 'FRICASsys' is problematic, but probably '--version' could be done
> > similarly to '-eval'.
>
> Honestly, no user must know about FRICASsys, so putting version
> information into the script is perfectly OK.
>
> Nevertheless, I would have nothing against also allowing a --version
> option for FriCASsys. I am even in favour of adding such an option.

> BTW, why is passing options to FRICASsys problematic. As you see from my
> patch, I allowed -eval and --eval. And that seems to work at least on my
> computer.

AFAICS you do not implement passing options to 'FRICASsys'. You
use existing hack... That I call problematic (but for now
it must do).

--
Waldek Hebisch

[Waldek Hebisch]

Bringing back to the list private part of discussion

On Sun, Aug 02, 2020 at 12:51:17PM +0200, Ralf Hemmecke wrote:
> On 8/2/20 3:51 AM, Waldek Hebisch wrote:
> > On Sat, Aug 01, 2020 at 03:37:38PM +0200, Ralf Hemmecke wrote:
>
> > Apparently you think that using two dashes for options is
> > somewhat superior to single dash. Can you give rational
> > argument why?
>
> Giving rational arguments is admittedly a bit hard.
> But there are conventions that could be followed. So why not?
>
> https://nullprogram.com/blog/2020/08/01
>
> Another reason is: we should definitely add --help and --version (with
> double dash) since they are quite common nowadays.
> If all other options are single-dash, then at least I find this confusing.

Well, double dash options apparenty were started by GNU folks.
Look at flagship GNU program, that is gcc. Typing

gcc -v --help

gives you long list of options. A lot uses double dash, but
a lot of multicharacter options uses single dash. There are
conventions, but this is much more complicated than "multicharacter
options use double dash". Or look at 'find', there are many
multicharacter options using single slash, with no apparent
double alternative.

More generally, double dash options appeared to add new options
to existing programs without conflict with existing single dash
options. When there were no danger of conflicts there is no
need to insist on double dash options (as gcc and find show).

> Argument that this means that we should just add -help and -version
> (single dash), is no benefit for users. When I try a program I use
> definitely double dashes, maybe -v, but -v could also mean "verbose".
>
> >> I deliberately only deprecated single dash long options (of course -h is
> >> kept, because it's a short option) and did not remove it.
> >
> > If you deprecate something and do not want to remove it, then
> > deprecation is pure FUD, and FUD is harmful for project.
>
> My intention for deprecation was indeed to warn users that at some point
> in the future single dash long options are a candidate for removal.
> Deprecation gives everyone time to adapt to a new "feature".
>
> > How you would feel about adding double dash support but
> > documenting this as deprecated?
>
> Well, that's. of course, nonsense. Adding something that at the same
> time is deprecated. Then adding is useless and I wouldn't propose it.
> It's about deprecating old behaviour.
>
> > If you plan removal, then it is appropriate to discuss
> > removal.
>
> Yes. I agree. Let's discuss this publicly.
>
> > I gave you two reasons for keeping current state.> To repeat:
> >
> > - single dash is shorter. Rationally, this should not be
> > a big deal, but I spent enough time interacting with
> > users to know that there is strong preference to
> > shorter versions.
> > - confusion. Either in Orwellian way we pretend that past
> > does not exist, or we need conditional description
>
> > If there is enough benefits, we may accept that costs are
> > acceptable.
>
> The costs are currently on my side. Since I have already done the patch.
> Now the question is whether enough user think that providing double-dash
> versions is a benefit.

Well, let me mention here anecdote from newsgroups. Lynn Wheeler
implemented support for FBA disks in IBM VM operating system.
This was working, tested code. Initially IBM rejected proposed
change, because cost of "implementing" it would be too high.
"Implementing" meant change to manuals mentioning new support
(AFAIK few pages of text) and propagating info to salesmen
and users. IIRC estimated cost was 28 million dolars, which
almost surely is 50 times larger than cost of coding and
lilely more than 1000 times more costly.

Times have changed, but if yor change goes in cost for other
folks will be much higher than your coding "cost". To put
it differently, it is likely that I would be able to code
such change in 1% of time spent writing messages discussing
the change.

> I do not insist on the sentence about "deprecating single dash". I did
> not expect that there would be any opposition against introducing double
> dashes.

Well, I do not like introducing double dash as alternative (as
having single way makes thing simpler to explain), but otherwise
no strong reason against such change. IMO main thing is to
replace obsolete message about workspaces by help.

--
Waldek Hebisch

[Ralf Hemmecke]

On 8/2/20 7:29 PM, Waldek Hebisch wrote:
> Well, I do not like introducing double dash as alternative (as
> having single way makes thing simpler to explain), but otherwise
> no strong reason against such change. IMO main thing is to
> replace obsolete message about workspaces by help.

OK, either all people are on holiday or there is nobody interested
enough in that issue.

So I take my double-dash options back and only cleaned the script a
little and introduced --help and --version.

I also replaced this -ws comment by the complete usage message.

Furthermore, for -nogo I also print the value of the FRICAS variable,
because it is necessary for the actual running of FRICASsys.

top 2 commits of:

https://github.com/hemmecke/fricas/commits/help-version

I feel that it's a good idea to also list the underlying lisp, but I
don\t insist on it.

I just want to get it in so that I can work with --version.

Hopefully, acceptable now.

Ralf

[Waldek Hebisch]

Yes, please commit.

--
Waldek Hebisch

[Grégory Vanuxem]

Hello,

Some time has passed...

I noticed changes in regards to this discussion on GitHub. Thanks for
the work behind.

I will build and try it.

Greg
__
G. Vanuxem

> --
> You received this message because you are subscribed to the Google Groups "FriCAS - computer algebra system" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to fricas-devel...@googlegroups.com.
> To view this discussion on the web visit https://groups.google.com/d/msgid/fricas-devel/20200805201811.GA17455%40math.uni.wroc.pl.