Tim Blechmann wrote:

more generally, it might be a good idea to think of an improved list handling (similar to scheme or python) ... or forbid empty lists (= bang, which is done) and one element lists (which should be atoms)

Not sure about scheme, but given its relation to Lisp, this may be true: empty lists are allowable in Lisp, and very useful. Just today I was working on a problem in Pd, constructing a list dynamically, where empty lists would have been handy (the cyclone prepend object doesn't do empty lists). It required some obnoxious extra wiring because I needed to take the first atom in the potential list and route it out elsewhere so it could be prepended to the second atom, then I could start adding on the new atoms as they were created.

Lisp is beautiful and easy to use becuase it's logical: there aren't (m)any exceptions to the rules. A list can hold anything. That can be nothing, atoms, or other lists. The more exceptions you add the more confusing things get imho.

Of course Lisp also ends up with obnoxious things like trying to select an atom and it being the wrong type because it's actually a one-atom list.

Just my two cents.

Ian

cheers ... tim

Mathieu Bouchard wrote:

...

Of course Lisp also ends up with obnoxious things like trying to select an atom and it being the wrong type because it's actually a one-atom list.

That's a weak argument against Lisp. You can replace every occurrence of CAR with CAR2 defined like

I didn't intend it as an argument against Lisp, but rather a gripe about the eccentricities of Lisp, or perhaps my own stupidity. Dealing with things like this might be even more annoying in a dataflow language like Pd, but maybe not.

I guess this gets back to a question someone raised earlier in the conversation about where Pd wants to go. Do we want a high level application, like Eyesweb or Isadora, or a programming language? It looks right now like we want somewhere in between. I know I do, if I wanted to program everything I'd do it in C (or Lisp (CLM)), but I need more control than something like Eyesweb offers (dealing with a dastardly problem right now that seems unsolvable given the nature of Eyesweb in combination with my little knowledge of it). Does your average Pd user want to think about converting 1-lists to atoms?

The problems in Pd seem to arise at the borders of either side of the somewhere-between-app-and-language niche Pd has carved out. Like trying to build lists dynamically, or on the other side, just wanting a fancy drum machine I can drop in bada-boom. But then, RRADICAL fixes the latter, and things like the Python and Ruby plugins help on the other end.

Speaking of which... I've been thinking about porting the MAX Lisp object to Pd when I have more time.

(defun car2 (my-list) (if (listp my-list) (car my-list) my-list))

and it's true that it would be cumbersome to do it for every function that processes lists, but then, code that doesn't treat atoms as 1-lists tends to work better when it comes to handling nested lists.

If I have a two-element list (A B), with both elements being lists themselves, then if I remove B, is the result (A), or just A ? why ? (that's where the Pd way can get really annoying, though nested lists aren't yet implemented in Pd)

---

Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

---

PD-list@iem.at mailing list UNSUBSCRIBE and account-management -> http://iem.at/cgi-bin/mailman/listinfo/pd-list

On Mon, 14 Feb 2005, Ian Smith-Heisters wrote:

Mathieu Bouchard wrote:

...

...

Of course Lisp also ends up with obnoxious things like trying to select an atom and it being the wrong type because it's actually a one-atom list.

That's a weak argument against Lisp. You can replace every occurrence of CAR with CAR2 defined like

I didn't intend it as an argument against Lisp, but rather a gripe about the eccentricities of Lisp, or perhaps my own stupidity.

Ok, so let me say, it's a weak argument against a bunch of programming languages.

Dealing with things like this might be even more annoying in a dataflow language like Pd, but maybe not.

I wouldn't say it's because it's dataflow. I see "dataflow" in general as open-ended with a lot more to explore. Within that large dataflow-land there's a tiny dot called puredata that's still near the start in many respects.

I guess this gets back to a question someone raised earlier in the conversation about where Pd wants to go. Do we want a high level application, like Eyesweb or Isadora, or a programming language? It looks right now like we want somewhere in between.

Whenever both at once are possible, pick both. You can use Pd as a tool to make high-level applications.

Does your average Pd user want to think about converting 1-lists to atoms?

It's not just about your average Pd user, you know. It's about all the users at once.

Now, about those 1-element lists, I think the problem introduced by not having them is more difficult to solve than the problem introduced by having them. But that kind of thing would appear mostly in cases where lists are grown gradually (or reduced gradually). Not everyone does that.

and things like the Python and Ruby plugins help on the other end.

Well I don't think it's much relevant... I think Pd should have better support for collections.

Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju

On Mon, 21 Feb 2005, Krzysztof Czaja wrote:

it does, since alpha51: 'list' (or 'bang') in the left inlet outputs an object's state, 'list' in the right inlet clears its state. Be careful with recursion, though, Pd is not that sort of a language...

I've already done some recursion in Pd, but only to see whether it would work.

The problem about it is that Pd is too much dependent on object-state instead of call-state, so it's not easy to just pile things on the call/return stack and unpile them, because a lot of critical data is stored in other locations that don't follow the call/return stack at all. So it's basically a mess.

Fortunately, this isn't too often "required". There's always one more workaround for anything, so there's always one more way to solve a problem without using recursion, but it's a pity that in Pd there is so much of a disincentive to use recursion.

(The worst offenders are actually my own externals... I've done some progress in rearranging things so that in the future it will be easy to fix the problem.)

Sometimes I may talk about data recursion vs control recursion; we're talking about the latter, as data recursion is just any kind of feedback that _doesn't_ use the call/return stack.

I remember talking to Miller (at Andrey Savitsky's show?) about a test suite for Pd, and how that could be structured. It would be cool if, from the code of a test for basic functionality of an object, a test for control-recursion (and one for data-recursion) could be automatically generated, because it would give us a list of all classes that currently support those features, although no documentation mentions those cases.

Mathieu Bouchard -=- Montréal QC Canada -=- http://artengine.ca/matju