Quite a while ago Steve Linton made various suggestions. I want to make
some remarks. Generally most of them seem reasonable.

Thanks

However, please
don't expect those feature to show up in the next release.

Don't worry. I half had in mind to implement some of them myself, but I thought I'd
float the ideas for consideration first.

Steve write:

It would be nice to be able to access the operating system
environment from GAP. A function Getenv(string) perhaps and/or an
array Environment of pairs of strings.

What about a record? 'ENVIRONMENT.USER' would evaluate to '"sl25"'.
Actually a function like 'Getenv' is probably safer, because I am not
certain that all systems support 'environ'. Anybody knows what ANSI has
to say about this?

A record is clearly correct from a GAP viewpoint, however a quick lok
at the Norcroft
library spec suggests that environ is not required by ANSI.

Steve continues:

It would be nice to have a structure that behaved like a hash-table
or a PERL associative array. This would enable general Orbit
algorithms to go MUCH faster. More generally Aho, Hopcraft and Ulmann
(Design and Analysis...) has a nice general description of
'dictionaries' in terms of which operations can be carried out
quickly. A set of constructs implementing these would be extremely
useful.

This is clearly the most ambitious suggestion. I agree that hash-tables
or associative arrays would be very nice. What I would really like to
have in GAP are *tables*, which are basically mappings from arbitrary
keys to values. A table where all keys are positive integers is a list,
a table where all keys are strings is a record. Very elegant, very
powerfull.

This isn't quite all-powerful. It would also be desirable to be able to get
at the keys in some order (think of heap-sort).

>
> The problem is the implementation. In GAP 2.4 we used hashing for sets.
> We had problems to come up with a reasonable hash function that worked
> well for all possible keys.
>
[ ... more problems with hash functions ... ]

I see the problem with hash functions, perhaps yuou could hash long
lists (permms, etc.)
on certain selected entries (first 10, plus a (pre-chosen) random one from each
subsequent 10 up to 100, etc., etc. However, possibly hashing is not
the right way to go.

Have you considered something like a B-tree or a 2,3-tree (in Knuth and AHU
respectively)? This will cost you log n on a lookup, but simply dpends on having
fast 3-way comparison. This also allows recovery in order.

This is not to say that tables could not be made to work efficiently.
However, clearly this area needs more investigation. Maybe we can learn
more from the Maple people; Maple uses hashing all the time.

Indeed, I wonder how they cope when you generate all elements of GF(2)^16.

Steve continues:

Especially on PCs (I don't know about STs) repeated use of AppendTo
is very slow as the file has to be closed and the directory updated
between each call. It would be nice to have fopen, fread/write and
fclose -like calls using some sort of file handle.

There will be better support for I/O when GAP finally gets the
facilities to communicate with subprocesses. This will also solve
this problem (and some others as well). This will be some Scheme
stream like facility (instead of C like handles).

Great

Steve continues:

It would be nice to be able to control the level of printing when
entering a break loop. When the progran is in a recursive procedure
or something I often loose the piece of information I want off the
end of the traceback.

[.. Description of backtrace omitted ...]

That is just what I needed. It would be nice if the default level for backtrace
were taken from some global variable (or settable by function call).

Steve continues:

Also for debugging purposes, it would be nice to be able to look past
a local variable at a 'hidden' variable of the same name in an outer
scope. Either some way of saying 'The global x' and the 'the x
belonging to procedure foobar' (though what happens if foobar is
recursed 8 levels deep?) or of saying 'The x in the scope outside
this one'.

There will be functions 'NextEnvironment' and 'PrevEnvironment',
which will allow you to step up and down the stack. Each local variable
will then be searched on that level. So to find 'foobar' 8 levels deep
you write 'NextEnvironment(8); foobar; PrevEnvironment(8);'.

Excellent.

Steve continues:

Possibly the read-eval-print loop should suppress or abbreviate the
printing of very long results.

Could you elaborate this a little bit more? On what should it depend
whether GAP suppresses the output? Do you want GAP to detect that the
output is going to be longer than 300 lines, and suppress it?

Ideally yes. It doesn't have to be perfect, but simply printing long lists as
for example

[2,3,5,7,11, <28 ommitted> ,139,149]

and printing long permutations as

<permutation of 10000 points>

would be very nice. Obviously, such should be optional, and controllable in degree.
Ideal, but probably harder would be to control the level of
abbreviation independently
for console output and logfile. Also, when printing nested lists and structures, the
level of abbreviation should probably increase as the level of nesting increases.

This should I think, only apply to the actual read-eval-print loop. Actually calling
Print should always do the whole job, thus Print(last); will always
recover whatever was
abbreviated.

Basically I often forget to use ;; and get 60 permutations on 300
points scrolling past.

As I said, I don't and didn't expect Martin and his team to
implemnt any of this
in any particular hurry, I just had some ideas that seemed worth discussing.

Steve

PS The latest version of DJGPP allows control-C trapping (I think) so a version
of GAP/386 with proper ^C handling should be out soon.