[PD] should 'flags' always come first?

[Christof Ressi]

IMO there is a convention that "flags" should come before positional 
arguments - but after "methods", like in [text define -k foo].

[sigmund~] is a curious case because its arguments "pitch", "notes", 
"env", "peaks" and "tracks" are *not* positional arguments but rather 
named arguments. [sigmund~] doesn't really distinguish between 
"arguments" on the one hand and "flags" on the other hand, instead it's 
just a single big loop. As a side effect, you can freely mix "arguments" 
and "flags". In fact, these "arguments" could just as well be flags, 
i.e. "-pitch", "-notes", etc. In the case of [sigmund~], the real 
difference is that all the "flags" can also be changed dynamically via 
messages while the "arguments" are fixed at creation time.

The current documentation follows the established practice to put flags 
before other arguments and I think we should keep it. I'm not sure 
whether it's necessary or even helpful to mention that the flags can 
actually come at any position. It might create more confusion than it 
tries to avoid...

Christof

On 27.02.2022 18:19, Alexandre Torres Porres wrote:
> I didn't mean to define things in a broader sense outside the context 
> of Pd. I'm just concerned in defining what is the "official" settings 
> and behaviour of flags in Pd.
>
> Em dom., 27 de fev. de 2022 às 06:33, IOhannes m zmölnig 
> <zmoelnig at iem.at> escreveu:
>
>     that's typically not how it works. see Postel's law.
>
>
> I see. It's not actually a bug if you allow non-conformant input, as 
> long as the meaning is clear. But the point here is to define what is 
> the correct way, in order to document it as such.
>
> Lots of people use a bogus symbol argument for inlet (such as [inlet 
> hz]) and Pd allows it, even though it is meaningless and 
> non-conformant input, but the point is that it is not documented and 
> it shouldn't be. In the same way you can have [osc~ 440 
> hz(cycles-per-second)] and [osc~] will not complain that it is 
> meaningless and that's fine.
>
> But this is a bit different, it's something that is meaningful and 
> that will work.
>
> Therefore, my main concern here is to agree on what is the standard 
> way and document it. And I believe the idea is that flags in pd are 
> supposed to come first for optional settings, and I should not say 
> that you can have it come later in [sigmund~], even though it works.
> I'm also concerned to conform to this principles in my externals.
>
> Would it be weird or wrong to have an external that NEEDS to load 
> flags AFTER the creation arguments? This has been necessary for 
> parameters that take a non fixed number of elements.
>
>     Pd has mostly adopted single-dash flags, both for cmdline args and
>     for
>     arguments.
>
>
> I think Pd has "only" adopted single-dash flags, right? Unless you 
> mean externals out there have adopted things differently.
>
>     that doesn't mean that other suffixes (e.g. '@') are "bugs". they are
>     just uncommon.
>
>
> cyclone uses "@", but that's because MAX uses it (and calls it 
> "attributes"). They can come later, though.
>
>     - They're always optional
>
>     i don't think so.
>
>
> I meant in Pd, but I remember now how [declare] works, and it only 
> takes 'flags', so yeah, not really "optional".
>
>     - They come before "actual" arguments.
>
>     what do you mean by "actual arguments"?
>
>
> Arguments that are not flags, in [sigmund~] they'd be "pitch" and 
> "env" for instance.
>
>     I've never heard of anything like that. i guess you mean arguments
>     that
>     are not "flags" (named arguments), but what is typically called
>     "positional arguments" (as their semantic is encoded in the position:
>     the 1st argument means something else as the 2nd arg).
>
>
> yup
>
>
> _______________________________________________
> Pd-list at lists.iem.at  mailing list
> UNSUBSCRIBE and account-management ->https://lists.puredata.info/listinfo/pd-list
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20220228/e031036c/attachment.htm>