support non symbolic labels

[jw3126]

This allows namespacing labels. Symbol labels still work, but you have to write the symbol with :

@mark :label code

[simeonschaub]

Why use eval here at all? Can't we just interpolate the expression? I'm also not really sure, whether it wouldn't make more sense to have a lower level @mark macro, which would allow having labels other than symbols and asking users to use Skip directly to skip them. I just don't see that many use cases, where a custom type would make more sense than a Symbol and I am a bit afraid that that would just complicate the API unnecessarily. Or do you have other use cases in mind where this would be useful?

[jw3126]

Why use eval here at all? Can't we just interpolate the expression?

It would be great to avoid eval, but I don't see how. Can you elaborate?

I'm also not really sure, whether it wouldn't make more sense to have a lower level @mark macro, which would allow having labels other than symbols and asking users to use Skip directly to skip them.

That would be fine as well.

I just don't see that many use cases, where a custom type would make more sense than a Symbol and I am a bit afraid that that would just complicate the API unnecessarily.

I don't think it complicates the API. You can still @mark :label .... I find this even slightly clearer then @mark label ..., which raises the question, what is label?

Or do you have other use cases in mind where this would be useful?

The use case is that if PackageA and PackageBboth use the same label, they don't interact. E.g. you can skip PackageA code without skipping PackageB code at the same time.

[simeonschaub]

Sorry, I didn't look into this thoroughly enough. You're right, the way that this PR proposes is only possible, if we use eval. What would you think about having a lower level mark function, that you can pass a custom label and an expression to, and it then wraps that expression with :[begin|end]_optional and the passed label. Packages then could just export their own macro, which calls this function with their custom label type. I have kind of a bad feeling about relying on eval in a macro, because it will introduce weird problems w.r.t. scope and world age, which I fear would be quite confusing for unsuspecting users.

[jw3126]

I agree eval is bad. I think it ould be nice if we could have helper functions that make the following possible:

module MyPackage

using OptionalArgChecks: markmacro, skipmacro

struct MyLabel end

macro mymark(code)
    markmacro(MyLabel(), code)
end

macro myskip(code)
    skipmacro(MyLabel(), code)
end

end#module

[simeonschaub]

Yes, that's basically what I was thinking of