axiom-developer
[Top][All Lists]
Advanced

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

Re: [Axiom-developer] Re: help function (Waldek Hebisch)


From: Waldek Hebisch
Subject: Re: [Axiom-developer] Re: help function (Waldek Hebisch)
Date: Wed, 5 Sep 2007 17:15:19 +0200 (CEST)

Martin Rubey wrote:
> Waldek wrote:
> 
> > Also, we have at least on bug report where closing parenthesis is user input
> > is wrongly read as system command.
> 
> I didn't see this bug report, could you send me a reference, please.  Do you
> think using another character to distinguish name spaces would be better
> suited?  Or would you advocate getting rid of the distinction alltogether?
> 

Sorry, I can not find the report now -- many reports are widely mis-labeled
so I would have to go trough all of them...  But I can show what the
problem was.  Put the following in a file:

poly := (x_
)*y

and try )read command on corresponding input file -- you will
get syntax error and message about unrecognized system command.
The same on the command line works fine -- command line uses old
parser which recognizes system commands only outside of
parenthesis.  But the new parser rejects this.

BTW: User example was much bigger -- when you naively split big
polymomials into multiple lines you will quickly hit this problem.

I am not sure if we need separate namespace for user commands.
But I think that we need sparate namespace for some programming
constructs, notably )if.  Also ')set message auto off' should
be handled immediately which is easy with separate namespace.
So I would probably keep separate namespace.

Choosing good prefix character is not easy, mnemonically !
would be very good, but ! really is allowed as first character
in names... IMHO # causes at least as much possibilities for
errors as ).  So we may be stuck with ).

OTOH for users we may provide alternative commands, for example
one can do:

help(x) == systemCommand("help " . x)

Drawback is that one have to give string as an argument  (I would
guess that having help as system command was at least partially
motivated by need to have unevaluated argument).

-- 
                              Waldek Hebisch
address@hidden 




reply via email to

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