[PD-dev] extending the .pd format

[Mathieu Bouchard]

On Wed, 24 Mar 2004, guenter geiger wrote:

> On Wed, 24 Mar 2004, Mathieu Bouchard wrote:
> > 1. "#X connect" lines would take any number of extra arguments, which
> > would have to be preserved by attaching an atom list to each connection
> > and save that list when saving the connection. Ideally this would have to
> > be put in all versions of Pd. Now, miller+devel branches may actually
> > just ignore those extra arguments, and the impd branch would do something
> > else with it.
> .. so this means no changes, right ? Surely a possible extension.

It means some changes, because currently, Pd can load a patch in which "#X
connect" has 5 or more arguments, BUT it does NOT save back the extra
arguments.

> if the {} do not present problems for the tcl/tk interpreter they seem to
> be the best choice.

They don't present problems for Tcl/Tk as long as they are balanced,
because then they are exactly matching Tcl/Tk list semantics.

> I am not sure though if pd supports nested lists.

Pd does not support nested lists, and isn't quite equipped to support them
gracefully. This is partly linked to the fact that objects are expected to
treat "float 42" and "list 42" the same way.

In GridFlow this is particularly exacerbated, as you may have to insert
[float $1( or [list $1( messageboxes in places to fudge the interpretation
of the data. I mean, GridFlow isn't really about nested lists, but its
multidimensional lists ("grids") can be thought of as if they were nested
lists most of the time. And then this problem appears:

"list 42"  is a 1-list   ->   a 1-dimensional grid of size {1}
"float 42" is a scalar   ->   a 0-dimensional grid of size {}

Are essentially different in GF but the same by Pd, and GF cannot be
changed to match Pd, as this is fundamental to handling any-dimensional
grids in a clean, uniform manner.

Now back to nested lists... compare the mess.

If they are effectively introduced, it'd probably be by adding T_LIST as
an atom type. But that means that, to be like other atom types, a list
message would have to have only one argument, of atom type T_LIST. But it
probably wouldn't, because of backward compatibility, and so if you happen
to have a "list" message containing just a T_LIST, this would be a 1-list
containing only another list. Furthermore, you wouldn't be able to
just take a "list" message and extract its value as an atom, as that
atom would've to be constructed. In a list message, $1 refers to the first
element of the list, not the whole list as an atom.

Yet another problem with nested lists is that they require some special
memory allocation tricks. I would assume a reference-counting scheme would
be appropriate, as a mark+sweep system is more difficult to get right.

> I think you would only have to change the parser, and the converter from
> pd internal types to text representation. This should not introduce
> changes in too many places.

Cool, I'll try this eventually, though I'm not completely sure how I'll
implement nested lists -- or how I'll avoid implementing them...

> Considering that the  language itself should be kept as simple as possible
> (everyone is happy that we do not have integer and float types anymore), I
> think, at least for the user, there should not be a distinction between
> symbols and strings. Where would we want to have strings ?

Günter, a symboltable is not meant to be used as a textprocessing
playground. The way it's used in Pd right now, it's a big gaping glorified
developer-approved memory leak. I guess it matters less nowadays, because
with average textprocessing needs, even a gallery installation can stay up
for weeks and months on a commonplace 512M RAM memory card, and I'm not
even talking of swap partitions and swap files. Then the next barrier is
the 2560M limit of virtual memory per process... under 32-bit Linux
anyway... and I guess buying a 64-bit K8 -- with 16 billion gigs of
virtual address space per process -- is easier than fixing a big gaping
glorified developer-approved memory leak... :-}

I mean I can hear John McCarthy scream in disgust and abomination... (he
invented the symbol type back in 1958...)

If there is too much resistance, I guess I'll continue developing them
string features in terms of grids, but currently it's not possible to put
a grid inside a list, so you can't do a list of strings of variable
lengths, so it sort of sucks too. I guess they could be \0-padded ... I
wonder how Jitter's string handling handles this case... if it does at
all...

________________________________________________________________
Mathieu Bouchard                       http://artengine.ca/matju