Source: http://xbiblio-devel.2463403.n2.nabble.com/Macro-condition-td7579255.html
Timestamp: 2019-04-19 15:05:40+00:00

Document:
seems necessary for modular style support.
otherwise be an awkward problem.
Wouldn't that extend to modular macros?
> seems necessary for modular style support.
> otherwise be an awkward problem.
which returns true if and only if the string returned by the macro is non-empty?
I don't see how the implicit conditional of groups would help here, since you can't actually test for them?
In a non-modular set-up, there are a number of ways to do this--e.g. normally we'd just handle the "at" in the same macro as the §. But if you want to modularize that, that's no longer possible.
Correct me if I'm misunderstanding this, Frank.
1. I don't like the name "alt-macro".
3. More general a test as Sebastian propose could also work.
The problem with the if test is that you would end up calling the macro twice. Once to check it and then to generate the content. Not an issue for simple macros, but would be unnecessary overhead otherwise. Though depending on how flexible you want this mechanism to be, there might not be another way.
and we lack a means of testing for that.
running the macro in the condition and then caching the result.
indeed have to happen twice, there's no way around that.
separate node doesn't seem to contribute much to expressiveness.
liking a simple attribute for this edge case.
>> 1. I don't like the name "alt-macro".
>> 3. More general a test as Sebastian propose could also work.
>>> you can't actually test for them?
>>> In a non-modular set-up, there are a number of ways to do this--e.g.
>>> want to modularize that, that's no longer possible.
>>> Correct me if I'm misunderstanding this, Frank.
>>>> are called are empty."
>>>> Wouldn't that extend to modular macros?
>>>> > seems necessary for modular style support.
>>>> > Ibid. at 123.
>>>> > Ibid. § 45.
>>>> > otherwise be an awkward problem.
This is another case I just don't have the time/energy to wrap my head around fully.
I also agree with others the syntax seems inconsistent with the current design.
Bigger: the design of CSL has always been premised on monolithic styles. Why shouldn't we be leery of the potential can of worms this opens up?
> shouldn't we be leery of the potential can of worms this opens up?
for CSL to do the same.
>> and we lack a means of testing for that.
>> running the macro in the condition and then caching the result.
>> indeed have to happen twice, there's no way around that.
>> separate node doesn't seem to contribute much to expressiveness.
>> liking a simple attribute for this edge case.
>> >> 1. I don't like the name "alt-macro".
>> >> 3. More general a test as Sebastian propose could also work.
>> >>> you can't actually test for them?
>> >>> In a non-modular set-up, there are a number of ways to do this--e.g.
>> >>> want to modularize that, that's no longer possible.
>> >>> Correct me if I'm misunderstanding this, Frank.
>> >>>> are called are empty."
>> >>>> Wouldn't that extend to modular macros?
>> >>>> > seems necessary for modular style support.
>> >>>> > Ibid. at 123.
>> >>>> > Ibid. § 45.
>> >>>> > otherwise be an awkward problem.
> want to say "Ibid. § 123."
right, that's why for regular styles, this is no problem. Frank, however, wants to be able to render the "at" in a different macro than the label variable (because both can take different forms in different styles). So this really only applies to modularization.
> this really only applies to modularization.
>> > want to say "Ibid. § 123."
* Let me try to continue on Sebstian's conditional approach: We would test for macro A, if successfully then call macro A otherwise call macro B. Well, in theory we could also call macro C in the success case, but this seams to make no sense, right? However, we could continue with different else cases. Is it possible to have more than two cases A, B? How would you do that? Second-alternative-macro?
It looks like we could also simplify some conditional if construction with this method (but have to enjoy more modularized styles).
which is probably the main reason we have it.
(although I think the examples contain a few typos).
citeproc-ruby and I'd be happy to support it.
problem that does need to be addressed in the proposal.
has, in fact, output something.
really don't want to let people go there.
throughout the processing of a cite (item fields, position, context).
fault would be harder than for other conditions.
> make no sense, right? However, we could continue with different else cases.
> Is it possible to have more than two cases A, B? How would you do that?
> this method (but have to enjoy more modularized styles).
>> > this really only applies to modularization.
>> >> > want to say "Ibid. § 123."
macro output, the attribute thing provides enough coverage.
>> problem that does need to be addressed in the proposal.
>> has, in fact, output something.
>> really don't want to let people go there.
>> throughout the processing of a cite (item fields, position, context).
>> fault would be harder than for other conditions.
>> > for macro A, if successfully then call macro A otherwise call macro B.
>> > Is it possible to have more than two cases A, B? How would you do that?
>> > this method (but have to enjoy more modularized styles).
>> >> > variable (because both can take different forms in different styles).
>> >> > this really only applies to modularization.
>> >> >> > want to say "Ibid. § 123."
I still think we need to start with first principles: do we really want to make CSL "modular"?
Or do we merely want to make it easy for its most complete and widely used implementation to add the benefits of such modularity?
Do these benefits only really apply to the legal use case, or are they potentially much more general?
How do we imagine this unfolding over next five years vis-à-vis style content?
How will it intersect with things like repositories?
My initial answer to first question is no, and that maybe this feature should not be core to CSL, but an extension attribute. But this would also have downsides, and opens up further questions (like, what's our long term strategy on CSL evolution, extensions, etc.?).
> implementation to add the benefits of such modularity?
> potentially much more general?
> How will it intersect with things like repositories?
> strategy on CSL evolution, extensions, etc.?).
I'll step aside here, as I have a clear interest that is well known.
These will be questions for the rest of the group to settle.

References: § 45
 § 45
 § 123
 § 123
 § 123
 § 123