[PD] should 'flags' always come first?

[José de Abreu]

some thoughts:

i think that sigmund~ is ok with flags that come last, because of the way
that sigmund~ parses its arguments. It doesn't impose any order, since the
user will create it the way it wants ([sigmund~ env pitch] and [sigmund~
pitch env] are both valid and gets its outlets swapped, and it is ok), so
for sigmund~ the point of view is that all arguments needs to be parsed and
if you throw a flag in the middle, it will be parsed accordingly, so even
if you put a flag in the middle (like [sigmund~ env -npts 512 pitch]) it
will also work.

but not all objects works if the flags appear in different order, and this
actually confuses me more than sigmund~

for example

[netreceive -u 5000] will listen to port 5000 and will use udp protocol,
but
[netreceive 5000 -u] will listen to port 5000 and use tcp protocol!! -u is
ignored in this case...

(you can check this using pdsend... for the first case "pdsend 5000
localhost udp" will work, but for the second it doesn't... it only works
with "pdsend 5000 localhost tcp")

but on the other hand, pd also has the opposite case, where flags comes in
the end, they are on the text family objects, specifically the [text
sequence] object

[text sequence text-help-seq2 -g], the -g goes after the creation argument
with the name of the text... and -w or -t also goes in the end


Em dom., 27 de fev. de 2022 às 14:22, Alexandre Torres Porres <
porres at gmail.com> escreveu:

> 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/20220227/87721faf/attachment-0001.htm>