Hello,
Newbie question, but a frustrating one I haven't been able to solve on my own yet.
I can send a message, e.g. [gain 0.1] to [route gain] which gets through nicely. But after packing a symbol and float (from an OSC message), resulting in [list gain 0.1], this gets rejected by [route gain]. What am I not understanding here, i.e. what am I doing wrong?
Thanks!
Steve

@jameslo Or suggest you idea here: https://github.com/pure-data/pure-data

@Jona A concept with implicit types would break many old patches, so i don't think it will ever come or it would be a fork that is not compatible with Pd. A solution could be to create some new objects that don't care about the type, so a new [route] and [list] and [symbol]. Don't know if this is reasonable.

@ingox that makes sense (perhaps the best to live with it?). could it be that the most current github issue is related? https://github.com/pure-data/pure-data/issues/990

"sidenote: i think the entire idea to use symbols (s, f, pointer,...) to denote the type is somewhat broken in the first place. but it's been there since before some of my students were born. i guess we will never be able to change it."

@Jona Yes, this is somewhat related as the whole concept of default values in Pd is also flawed in my opinion. In other languages you can have empty variables and you can check if a variable is empty. That would be handy in Pd too.

On the other hand it may also be a matter of opinion. There are strict languages where you have to explicitly define the type of your variables and "loose" languages like JavaScript where the language does type conversions for you.

Pd's concept is somewhat inconsistent in some places, but you can work around those issues in most cases. It is just a little bit inconvenient sometimes.

Anyhow, in many cases [list] can help, as it does type conversions.

[something(
|
[list]

gives "symbol something".

@Jona @ingox Just to be clear, I'm not suggesting any changes--this language existed almost a decade before I started using it and I know how hard it is to change APIs even when there is only one stakeholder. I was just hoping there would be some vanilla object that differentiated its behavior on the presence of a "list" selector so that I would never again forget to trim it. Maybe this discussion served that purpose.

But I can't resist piling on. The silent substitution of 0 for all division by zero operations is outrageous by normal language standards. But again, don't go changing! Stay beautiful, PD!

BTW, I wouldn't be surprised if the strong typing in Java, c#, c++, and c has saved me hundreds of debugging hours, so I wouldn't be in favor of a duck-typed PD. The irregular, spaghetti-ish nature of these visual dataflow languages is freedom enough, thank you.

@jameslo said:

The silent substitution of 0 for all division by zero operations is outrageous by normal language standards.

That is true. [expr] does give an error though...

This could actually be changed. Maybe this deserves a github issue.

@ingox The big no-no for me is how list....... which after all is just a tag to let a left inlet know to distribute the list across its inlets....... is limited to a list that starts with a float.
A list that starts with a symbol is handled completely differently..... with an assumption that it is not a "real" list.
So for example [route float symbol list] applies that rule and breaks the message handling.

Even message boxes will handle a float as $1 but not a symbol unless there is an explicit list tag.....
route-help.pd (bottom left..... my favourite).
It seems float is implicit.
Symbol can be once run through an object....... but sometimes needs to be defined.
And list will always be a mess defined so narrowly.
David.

@whale-av Haha, great overview over the inconsistencies of Pd's atom system. I agree with all you said.