Functions which don't return values don't work properly in nested expressions.

[ChrisJefferson]

I previously submitted a pull request which allowed more interesting nested expressions, such as f().x. It has turned out there are a couple of issues.

1. Sometimes GAP complains when functions don't return a value:

(function () end)(); complains function does not return a value, which it doesn't matter that it doesn't.

2. Sometimes GAP crashes when functions don't return a value:

(function () end)().x; asserts.

This isn't hard to fix, but I wanted to brief consider the semantics we want before we attack it.

In particular, one way to fix this would be to be inspired by 831 or 829, both of which provide a consistent method of handling if a function returns a value or not.

[ChrisJefferson]

To save people going and reading:

#829 : Add a value (python does this, it's called None), which is returned by any function which isn't actually returning a value.

#831 : Make assigning the returned value of a function the same as unbinding the variable.

[ChrisJefferson]

My personal preference (unsurprisingly, as it's my patch) is 829, mainly because Python uses it and everyone seems to like it. While the @frankluebeck's approach in 831 is very interesting, it is a more untested / new idea, which we would be (I think) the first people to do.

[fingolfin]

I don't understand why those two PRs are even relevant. OK, the first of the two issues you report here seems to have a tenous connection (both it and the PRs involve functions returning nothing, aka procedures). But it is not at all clear to me how fixing the issue here is related to those PRs. Could you elaborate?

For the second issue, I see no connection at all...

[ChrisJefferson]

I should have explained.

829 and 831 both add code which makes GAP's handling of functions which do not return values less special cased, and could be used as a base for fixing this bug, and defining the semantics of such expressions.

Alternatively, we could define some other semantics, closer to the current behaviour of GAP.

I shouldn't have bought up those pull requests (in particular 831). The important thing is, what semantics do we want for expressions like the ones I give at the top. Then I can implement whatever we decide.

[fingolfin]

I think the semantics in either case should be the same as if you first assigned the function to a variable; then invoked that function. I.e.:

gap> tmp:=function() end;;
gap> tmp();
gap> tmp().x;
Error, Function call: <func> must return a value

[frankluebeck]

Example 1. should behave like the first two lines in the previous comment. (Does GAP try to assign a result to last there?)

But I cannot see a problem with Example 2. Except that it is a bit inconsistent with (function () return [];end)().x; and (function () return rec();end)().x; which cause a break loop.

[ChrisJefferson]

@frankluebeck : I'm working on fixing this, and have (I think) a fairly easy way to do it. Thanks for mentioning last, it hadn't occurred to me to look at that, I'll make sure I've fixed that too.

[ChrisJefferson]

Now fixed in a patch.

@frankluebeck : Thanks for your feedback. In '2' when I said "asserts", I didn't mean a GAP-level assert, I meant a C-level assert -- GAP just exits entirely in the current master branch! (Now fixed).