[PD] Selectors was: confused about $1 in messages

[Jonathan Wilkes]

On 01/21/2014 11:23 AM, Funs Seelen wrote:
> On Tue, Jan 21, 2014 at 10:02 AM, IOhannes m zmölnig <zmoelnig at iem.at 
> <mailto:zmoelnig at iem.at>> wrote:
>
>     On 01/20/2014 10:01 PM, Jonathan Wilkes wrote:
>     >
>     > It might help some if the selector inside a message box were
>     visually
>     > distinct from the rest of the message.
>
>     +1
>
> I don't see how this would prevent the mentioned confusion.

It wouldn't prevent it.  But it would still help.

For an example: IDE syntax highlighting can't prevent confusion when 
learning C or Java or anything else.  But it can cut down on mistakes 
and make things easier/quicker to read.  This would be the same.  Aside 
from the [list] objects, the selector is treated special in message 
passing (in fact it usually determines what happens next), so giving a 
visual clue would be quite helpful.

Additionally, because of implicit float messages the first thing one 
sees in a message box is not necessarily the selector.  One of the 
sources of confusion is looking at [1 2 3( and deducing that the first 
atom is "$1", the second atom is "$2", and so on.  That's fine but it 
doesn't work for the general case.  And that's when someone has to 
understand how selectors work.  They aren't very complex, and I try to 
be consistent when describing the anatomy of a message-- but in a visual 
programming environment it's really great to connect the dots by saying 
"the word in the little rounded box there". Furthermore, it serves as a 
reminder of what the user just learned.

It might seem superfluous or even distracting.  But look back at the 
OP's message: "one two three".  That's a message which implicitly 
assumes all atoms of the message are created and treated equally. Again 
it doesn't prevent confusion, but having the word "one" visually 
distinguished from "two three" is one step closer to understanding 
what's going on.

In essence, it helps to create a low latency learning environment by 
removing unnecessary round trips through the Pd-list.

> And how would you like to do this? Italics, size, colors, different font?

I like the little "token" widgets that are used in email apps and other 
places.  That's hard to do in a tk canvas, easier in tkpath (Pd-l2ork).

Of course it's complicated by nonlocal message-passing when using 
semicolons, so it may prove to be rather troublesome to implement. But I 
still like the idea and will look into what it would take to do it.

-Jonathan

>
> It seems that [list] classes (e.g. [list split]) turn words into 
> symbols and multiple words into a list automatically, just as numbers 
> are turned into floats and multiple numbers into a list everywhere in 
> Pd. The confusion is not that people cannot remember the words float, 
> list, bang, symbol to be reserved, but that they are used to the 
> convenience of how Pd handles floats and list of floats. You would 
> almost forget that "dog" is not a symbol and that "dog cat bear" is 
> not a list, particularly because [list split] doesn't complain and 
> just returns a real list.
>
> --Funs
>
>
> _______________________________________________
> Pd-list at iem.at mailing list
> UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.puredata.info/pipermail/pd-list/attachments/20140121/d182806f/attachment.htm>