[PD-dev] First attempt at "list" object uploaded

[B. Bogart]

Hey all,

I've been barely able to keep up with this thread. Lots of ideas and
changes. Here I agree with everything that HC has to say.

I'm also a bit confused (anoyed) about the whole list vs nonlist things
just for the reasons HC mentions. Miller, you said it is probably
"better" to use lists rather than lists that do not start with "list" as
the first element, non-lists. Why is this?? I think a list should be:

* interpreted in many cases as a non-list. (ie creating OSC names for
   example, [list send /hello/blah value] automatically gets rid of the
   "list" part because it knows what to do about it.

* be able to contain a mix of symbols and float atoms

* there be only be one "list-like" thing, I don't know what this would
   make a non-list into... an undefined list? One would not need a
   non-list if the first point above was true and the "list" part not
   considered part of the list. (NOT the first element, but something
   invisible that you never need to see, like "float [float]" where I
   have never had the need to worry about it but the damn list selector
   comes up all the time. :(

Thats all for me.

b>

Hans-Christoph Steiner wrote:
>
> On Jul 24, 2005, at 3:51 PM, Miller Puckette wrote:
>
>> hi all,
>>
>> Thanks for all the discussion, which changed my mind on a number of
>> points.
>
>
> I am definitely glad you are working on this!  This is something that
> will greatly improve message handling in Pd.
>
>> I've uploaded a first attempt at a "list" object to CVS...  see the help
>> window, which also provides some examples.  So far, I implemented these
>> options:
>>
>>     list append - append a list to another
>>     list prepend - prepend a list to another
>>     list split - first n elements to first outlet, rest to second outlet
>>     list trim - trim off "list" selector
>>
>> I'm not sure whether to keep the "list <function>" format or not now; the
>> list seems divided over it and so am I.  The advantage is it's the least
>> visually cluttered way to name them.  I can't use "append", "prepend", or
>> "split" as names in their own right
>
>
> At pd~conf, we discussed renaming Pd's [append] for data structures to
> [add] so it would match [get] and [set].  Then [append] could be made to
> match [prepend].  Also, the current [append]'s help file describes it as
> "add an item to a list", so [add] makes sense.  There is no existing
> [add] that I know of.
>
>> (they're already used, and using namespaces
>> to alias well-known names would cause endless confusion!)
>
>
> Such namespaces work well in many languages like Java, C, C++, perl,
> etc. etc.  I think there would be rough-ish bits in transition, but in
> the long run would work much better for managing externals. It would
> also allow external writers to do whatever they want with their
> externals yet still be able to interoperate.  The centralized management
> of a single namespace would no longer be necessary, it would be split up
> into chunks managed by individuals.  And it would push Pd to the next
> step of becoming a fully fledged programming language.
>
> This would also allow Pd to have its own distinct namespace without
> breaking Max compatibility.  If you import cyclone in a patch, then
> cyclone's [split] would override Pd's.  Then you could rename it to
> [cyclone/split] and you could take out the import statement and both
> splits would work.  Or vice versa, with something like [pd/split].
>
>> The advantage to
>> Iohannes's suggestion (list_append, etc.) is that external objects
>> could supply
>> list_whatever objects that could belong naturally to the series.
>
>
> Its not so pretty but it would work.
>
>> I think I have an adequate way to deal with non-list messages; they're
>> converted
>> to lists on input, and the "list trim" object can be used to
>> explicitly convert
>> back.  I still think it's better style to use "true" lists wherever
>> possible,
>> but this will probably never find general agreement.  My only advice
>> is that,
>> if you want to use non-list messages, just never, ever name a file
>> "bang"!
>
>
> One of the core problems with message handling using lists is that they
> are not interpreted consistently across objects.  For example, objects
> like [route] and  [print] only interpret the first element 'list' when
> the following body of the message is an implied list, i.e. a set of
> atoms with a float as the first element.  This means you can't use
> [route] to deal with a message stream that has both lists and undefined
> sets.  If this was fixed, it would make mixed message handling in Pd
> much easier.  With [print], this is a bummer because it means that there
> is no method within Pd that allows you to see the actual raw messages as
> Pd sees them.
>
> This leads to me something that can be very confusing when dealing with
> message streams made up of lists, atoms, and "undefined sets": there are
> some objects that work with lists and some that work with "undefined
> sets" and its often not easily apparent to see which is which.  Examples
> are [route], [print], [prepend].  I attached a patch to illustrate this.
>
> .hc
>
>
> ________________________________________________________________________
> ____
>
>  As we enjoy great advantages from inventions of others, we should be
> glad of an opportunity to serve others by any invention of ours; and
> this we should do freely and generously.
>
>                          - Benjamin Franklin
>
>
> ------------------------------------------------------------------------
>
> _______________________________________________
> PD-dev mailing list
> PD-dev at iem.at
> http://lists.puredata.info/listinfo/pd-dev
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 256 bytes
Desc: OpenPGP digital signature
URL: <http://lists.puredata.info/pipermail/pd-dev/attachments/20050727/53f5481f/attachment.pgp>