"`map' is truncating" message and other assorted messages

"Stavros Macrakis" <macrakis at alum.mit.edu> wrote:
> Controlling the behavior of functions by global variables is ugly and
> error-prone.  For libraries of Maxima code to have predictable
> behavior, every use of "map" needs to be surrounded by something like
> 
>      block([maperror:<some value>,mapprint:<some value>], ... map(...) ...)

I agree that global variables are generally ugly and error prone. I also
agree that global variables that only control a single function get
some extra ugliness points. Alas maxima often doesn't offer much
other choices.

Having that said I don't think it is as dramatic as you make it sound,
as long as there is some sane policy:

Maxima should work properly with all globals set to their default
values. Changeing global variables might break something.
(simp:false sure does, but I still like to have it)

Libraries should never change global variables, but they might
define new ones.

Global variables (especially those defined by libraries) should
always be documented easily accessible. (I guess everything
mentioned in the index of the manual is ok.)

> We should bite the bullet and decide what behavior we want map to

I think we already do that by picking values for maperror and mapprint.

> have, and get rid of both maperror and mapprint.

As you write yourself, both functionalities of map are useful. I don't
think we should remove it, but perhaps we don't need global variables
in this case? Perhaps functions sloppymap and strictmap would do?

This question boils down to: Will we ever want to control the
behavior of map when it is called from an other function?
Personally I'm not a big fan of inventing new functions. Basically
because to replace n global variables you need up to 2^n functions.

You could always implement sloopymap via block([maperror:false, ...

Summary: I don't think there are really strong argumentes for one
way or the other so it's up to the taste of the one implementing
it, but I think the functionality itself should stay.

As for the mapprint:false as default change: As long as the default
for maperror is true, I think this is ok. If anybody changes maperror,
they should already know what they do.

Harald