Re: "intrinsic <return>" could be interpreted as "?intrinsic <return>"

[Karim Belabas <Karim.Belabas@math.u-bordeaux.fr>]

* Jacques Gélinas [2018-08-29 02:46]:
> Example of current parsing:
> 
> # primes
> %1 = primes
> 
> Instead of returning the input, why not give the help string 
> (and leave the line count unchanged ? Thus we could have
> in the next version
> 
> # primes
> primes(n): returns the vector of the first n primes (integer), or the primes in
> interval n = [a,b].

I'm reformulating: how should we 'print' a t_CLOSURE ?

The current choice is to be 

1) consistent: a t_CLOSURE is always printed in the same way. It does not
matter if the closure is a whole result in itself (your example), or
e.g. in a vector of functions. The recursive implementation of output routines
does not care.

2) "copy-paste-friendly": we output a character string that can be
copy-pasted as-is in another session and create the same object.
Although the details are different for built-in functions (print
function name) and user functions (print function definition), the
property works for both.  [ For user functions, the output is actually
useful: it tells what actual implementation hides behind a given name. ]

  # f(x) = x+1
  %1 = (x)->x+1

  # v = [cos, f]
  %2 = [cos, (x)->x+1]

  # v[1](Pi)
  %3 = -1.0000000000000000000000000000000000000

  # v[2](Pi)
  %4 = 4.1415926535897932384626433832795028842


The proposed change is to print help strings instead, e.g. respectively
  cos(x): cosine of x.
and
  f =
    (x)->x+1
for 'cos' and 'f'. How should we now print [cos, f] ? Note also that
although the second string is still copy-paste-friendly in certain cases
(if it stands by itself), the 'cos' one never is. So in effect, the only
sensible specification I see is to break consistency:

1) whenever a result consists solely of a t_CLOSURE attached to a builtin
function, i.e. the current output string is identical to the input string,
print the help string instead of the function name;
2) in all other situations, keep current printout [function definition
for user functions, function name in recursive constructs containing
builtin functions].

The rationale I see for the change is to remove the need for prefixing
the name with a question mark '?' in order to get the help string,
thereby saving one keypress.

Note that there is a backward compatibility issue: since the dawn of
time, closures without mandatory arguments can be called without
parentheses, i.e. 'gettime' is actually equivalent to 'gettime()' and
calls the routine. So instead of

  # gettime
  gettime(): milliseconds of CPU time used since the last call to gettime.

we must actually evaluate the function (and return a small integral
number of milliseconds, presumably 0 or 1). Or break compatibility.

Although the feature is not hard to implement [ add a t_CLOSURE-specific
hack in the gp main loop output routine ( src/gp/gp.c:normal_output() ) ],
I don't think it's worth the trouble or inconsistencies.

Cheers,

    K.B.
--
Karim Belabas, IMB (UMR 5251)  Tel: (+33) (0)5 40 00 26 17
Universite de Bordeaux         Fax: (+33) (0)5 40 00 21 23
351, cours de la Liberation    http://www.math.u-bordeaux.fr/~kbelabas/
F-33405 Talence (France)       http://pari.math.u-bordeaux.fr/  [PARI/GP]
`