Feature suggestion: shorthand to create a picture

[user202729]

Currently, if we want to create a picture then add it, we write

picture p;
size(p,…);
draw(p, …);
add(currentpicture, p); // can be simplified to add(p);

I think this is rather cumbersome, which requires a temporary variable.

Does it make sense if we can write the following?

add(currentpicture, picture(new void(){
  size(…);
  draw(…);
}))

In other words, the expression picture(new void(){…}) evaluates to a picture object, which consist of all the things drawn inside the anonymous function.

Ideally we could make a "special syntax" like picture{…} evaluates to a picture, but that requires language modification and making picture into a keyword, which may be undesirable.

[charlesstaats]

I agree that having to repeat the p every time is annoying and error-prone. Fortunately, there's already a way to get around that:

• Save currentpicture to a temporary variable (say, oldpicture).
• Set currentpicture = new picture;
• Run all the size, draw, etc. commands as usual, without specifying the picture.
• Add currentpicture to oldpicture.
• Set currentpicture = oldpicture;.

See also https://sourceforge.net/p/asymptote/discussion/409349/thread/282f4337de/

The syntax is still a little cumbersome, but if we wanted to slim it down even more, I think something like Python's context manager syntax would make more sense than a picture-specific syntax.

[user202729]

Context manager is okay. And I already figure out the currentpicture thing.

But what I really want is to make it into an expression instead of a function.

The context manager would still be useful though. E.g.

picture p;
with setcurrentpicture(p) {
  draw((0, 0) -- (1, 1));
}

Another case where contextmanager is useful is to locally apply transformation, like TikZ.

with applytransform(rotate(45)) {
  draw((0, 0) -- (1, 1));
}
// equivalent to draw(rotate(45)*((0, 0) -- (1, 1)));

But note that contextmanager can already be implemented with closure, it's just a bit heavy on syntax (need another pair of parentheses and new void()). (This is not Lisp, but closure is not too bad.)

onpicture(p, new void(){
  draw((0, 0) -- (1, 1));
})
// implemented by
void onpicture(picture p, void f()){
  var backup=currentpicture;
  currentpicture=p;
  f();
  currentpicture=backup;
}

[charlesstaats]

So, why can't you just alter this to do what you wanted? Perhaps I'm misunderstanding?

add(currentpicture, onNewPicture(new void(){
  draw((0, 0) -- (1, 1));
}));
// implemented by
picture onNewPicture(void f()){
  var backup=currentpicture;
  currentpicture=new picture;
  f();
  picture result = currentpicture;
  currentpicture=backup;
  return result;
}

[user202729]

Actually that's not a bad idea. Using quote{…} instead of new void() would be slightly shorter as well.

Maybe then the suggestion is then "is it worth it to include it by default".

[charlesstaats]

John, would you support this?

Personally, I think both functions (onPicture and onNewPicture, possibly with different names) could be useful and worth including in plain_picture.asy and documenting.

Random note from conversations with John Bowman: going forward, camelCase names should be preferred to runoncase.

[user202729]

Do we want to refactor and gradually deprecate old names then...?

(How do we support "both versions" of things like currentpicture even? Is operator= overloadable?)

[user202729]

Actually thinking about it, there's a little problem. What if you want to use variables defined inside the onNewPicture construct?

Current code:

picture p;
save(); // I don't remember if this works but theoretically
currentpicture=p;
object X=draw("abc", box);
object Y=draw("def", ellipse);
restore();
// use X and Y here

New code:

object X, Y;
picture p=newPicture(quote{
    X=draw("abc", box);
    Y=draw("def", ellipse);
});

(Side note: I think if onNewPicture returns a new picture, it makes more sense to name it newPicture.)

Problem: we cannot use var for X and Y anymore.

Proposal 2:

var [p, X, Y]=newPicture(quote{
    X=draw("abc", box);
    Y=draw("def", ellipse);
    return [X, Y];
});

Problem: destructured assignment (or even automatic tuple of arbitrary type) isn't available in Asymptote yet.

[charlesstaats]

I'd go with your first option. If you need to modify X and Ywithin the void function and have them available afterwards, then make them global variables. (Or if you want to be really clever, put the void function inside an object of which X and Y are fields. In most cases, though, I doubt this is worth it.)

Problem: we cannot use var for X and Y anymore.

Speaking as someone who rarely uses var at all, I don't see this as a big issue. But not all workflows are the same. How bit a pain point is it for you if you can't use var? Is there some other alternative (e.g., a tool for figuring out the type of an object while you are writing the code) that would mitigate the pain here?

[user202729]

Mypy has reveal_type() special construct that just tells what the type is.

I think Asymptote already have LSP (although I haven't gotten around to figure out how to use it), which isn't too bad.

Also we have asy command-line and write which can occasionally write out the type (for things like typedef drawer ⟨complicated function type⟩ though…)is

And then there's also go-to-definition (Asymptote haven't gotten universal ctags integration yet, but then universal ctags is written in C which is far from the most powerful language)

---

Actually they need not be global variables, they just need to be variables in the enclosing scope ("nonlocal" variables in Python's terminology).