On 01/21/2014 11:23 AM, Funs Seelen wrote:
On Tue, Jan 21, 2014 at 10:02 AM, IOhannes m zmölnig <zmoelnig@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@iem.at mailing list
UNSUBSCRIBE and account-management -> http://lists.puredata.info/listinfo/pd-list