<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<p>IMO there is a convention that "flags" should come before
positional arguments - but after "methods", like in [text define
-k foo].</p>
<p>[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.</p>
<p>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...</p>
<p>Christof<br>
</p>
<div class="moz-cite-prefix">On 27.02.2022 18:19, Alexandre Torres
Porres wrote:<br>
</div>
<blockquote type="cite"
cite="mid:CAEAsFmg5ZfTvn+pjwSuz-09vSZANhd1xoVOOAKtdWmE9NnD+Xg@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">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.</div>
<br>
<div class="gmail_quote">
<div dir="ltr" class="gmail_attr">Em dom., 27 de fev. de 2022
às 06:33, IOhannes m zmölnig <<a
href="mailto:zmoelnig@iem.at" moz-do-not-send="true"
class="moz-txt-link-freetext">zmoelnig@iem.at</a>>
escreveu:</div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
that's typically not how it works. see Postel's law.<br>
</blockquote>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>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.</div>
<div><br>
</div>
<div>But this is a bit different, it's something that is
meaningful and that will work.</div>
<div><br>
</div>
<div>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.</div>
<div> </div>
<div>I'm also concerned to conform to this principles in my
externals.</div>
<div><br>
</div>
<div>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. </div>
<div> </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
Pd has mostly adopted single-dash flags, both for cmdline
args and for <br>
arguments.<br>
</blockquote>
<div><br>
</div>
<div>I think Pd has "only" adopted single-dash flags, right?
Unless you mean externals out there have adopted things
differently.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
that doesn't mean that other suffixes (e.g. '@') are "bugs".
they are <br>
just uncommon.<br>
</blockquote>
<div><br>
</div>
<div>cyclone uses "@", but that's because MAX uses it (and
calls it "attributes"). They can come later, though.</div>
<div> </div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
- They're always optional<br>
<br>
i don't think so.<br>
</blockquote>
<div><br>
</div>
<div>I meant in Pd, but I remember now how [declare] works,
and it only takes 'flags', so yeah, not really "optional".</div>
<div><br>
</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
- They come before "actual" arguments.<br>
<br>
what do you mean by "actual arguments"?<br>
</blockquote>
<div><br>
</div>
<div>Arguments that are not flags, in [sigmund~] they'd be
"pitch" and "env" for instance.</div>
<div> </div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px
0.8ex;border-left:1px solid
rgb(204,204,204);padding-left:1ex">
I've never heard of anything like that. i guess you mean
arguments that <br>
are not "flags" (named arguments), but what is typically
called <br>
"positional arguments" (as their semantic is encoded in the
position: <br>
the 1st argument means something else as the 2nd arg).<br>
</blockquote>
<div><br>
</div>
<div>yup</div>
<div> </div>
<div><br>
</div>
</div>
</div>
<br>
<fieldset class="moz-mime-attachment-header"></fieldset>
<pre class="moz-quote-pre" wrap="">_______________________________________________
<a class="moz-txt-link-abbreviated" href="mailto:Pd-list@lists.iem.at">Pd-list@lists.iem.at</a> mailing list
UNSUBSCRIBE and account-management -> <a class="moz-txt-link-freetext" href="https://lists.puredata.info/listinfo/pd-list">https://lists.puredata.info/listinfo/pd-list</a>
</pre>
</blockquote>
</body>
</html>