Unprintable object?

[laurentbartholdi]

I would very much like GAP to have an unprintable object: an object that, when returned, does not display anything. (This exists, e.g., in julia as the object "nothing").

Reason: I have a function called "Draw", which typically opens a window and draws an object in the window. In that case, it should return nothing. However, depending on user preferences it could also return an ascii string with a crude drawing of the object, or a JupyterRenderable object.

Then, if Draw itself is called from another command (say Draw with other parameters), the caller doesn't know if it should forward a return value or not. This forces ugly code of the form

if in_jupyter_mode() then
    return Draw(arguments);
else
    Draw(arguments);
fi;

Having "Draw" always return a value (such as "true") would be an alternative, but would pollute the screen unnecessarily.

I hope I'm not doing anything wrong by putting this in the "issues"... it's not a bug, it's a feature request.

[stevelinton]

So if I understand, you want an object x that such that ViewString(x) is the empty string. Should String(x) and DisplayString(x) also be empty, or does it make more sense for String(x) to print some GAP input that can create the object?

[laurentbartholdi]

Almost... The empty string would still come with a carriage return at the REP loop level.

…

On Fri, May 31, 2019, 18:25 Steve Linton ***@***.***> wrote: So if I understand, you want an object x that such that ViewString(x) is the empty string. Should String(x) and DisplayString(x) also be empty, or does it make more sense for String(x) to print some GAP input that can create the object? — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3482?email_source=notifications&email_token=AARAQUFPAIEWWAE2GXVN23LPYFGO7A5CNFSM4HRZ7XE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODWVWW5Y#issuecomment-497773431>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARAQUBUVPLOJ2W2HVMF65LPYFGO7ANCNFSM4HRZ7XEQ> .

[ChrisJefferson]

While I'm not disagreeing with this, we did in the past think about adding something like Python's "Nothing", or various variants of it (such as allowing "return f(x);" where "f(x)" didn't return anything just continuing to not return anything. None of the possible designs ended up winning.

[ChrisJefferson]

Here is the previous PR (and from here you can get to some related PRs, which tried out other ideas). EDIT: I meant to link to a or here, but @fingolfin linked to them below.

[fingolfin]

I do disagree with this. We thought about this and discussed it at length before. It just doesn't fit in naturally, and opens up tons and tons of corner cases, which need to be dealt with, and quickly (otherwise, we'll do undesirable things in some of them, yet people start to depend on them).

I'd also argue that a GAP function which sometimes returns a value and sometimes doesn't is bad design (in fact, I'd argue the same for any language, not just GAP). If you really need to deal with such a thing, you can use CallFuncListWrap, but really, I'd rather suggest you avoid this.

Finally., why can't your function just return fail or 0 or whatever in the first case?

(Oh, and "issues" include bug reports, feature requests, and support requests equally, so this is the right place for "feature requests").

[laurentbartholdi]

Sorry, I can't find any previous PR about this. My suggestion was the following, in GAP pseudocode. I don't see how it can possibly break anything: DeclareCategory("IsUnprintableObject",IsObject); BindGlobal("UnprintableObj",Objectify(NewType(FamilyObj([]),InUnprintableObject,rec())); InstallMethod(ViewObj,[IsUnprintableObject],ReturnNothing); except that gap> UnprintableObj; gap> so there still in an annoying empty line, and I'm afraid this can only be fixed by tweaking the REP loop.

…

On Tue, Jun 4, 2019 at 1:20 PM Max Horn ***@***.***> wrote: I do disagree with this. We thought about this and discussed it at length before. It just doesn't fit in naturally, and opens up tons and tons of corner cases, which need to be dealt with, and quickly (otherwise, we'll do undesirable things in some of them, yet people start to depend on them). I'd also argue that a GAP function which sometimes returns a value and sometimes doesn't is bad design (in fact, I'd argue the same for any language, not just GAP). If you really need to deal with such a thing, you can use CallFuncListWrap, but really, I'd rather suggest you avoid this. Finally., why can't your function just return fail or 0 or whatever in the first case? (Oh, and "issues" include bug reports, feature requests, and support requests equally, so this is the right place for "feature requests"). — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#3482?email_source=notifications&email_token=AARAQUCYYFZLF2A3KI6NSW3PYZFYJA5CNFSM4HRZ7XE2YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGODW4H36A#issuecomment-498630136>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AARAQUEPH6EUCDS3OY7LH7DPYZFYJANCNFSM4HRZ7XEQ> .

-- Laurent Bartholdi laurent.bartholdi<at>gmail<dot>com Bureau GN1 Nord 472, tel. +33 4 72728722 École Normale Supérieure 46 allée d'Italie, 69364 Lyon Cedex 07

[fingolfin]

We discussed this on at least one GAP day, not necessarily written down. Some relevant PRs are #824, #829, #831

[fingolfin]

Anyway, I stand by my earlier remark that I consider it bad design to have a function which sometimes returns a value and sometimes not; and I kinda wish I could go back in time and enforce this rule on a language level (alas, some legacy code "relies" on this).