[PD-dev] [ANN] mostly for devs and tcl'ers: tclpd

[Mathieu Bouchard]

On Tue, 23 Oct 2007, Hans-Christoph Steiner wrote:

> - About the symbol/float stuff, I think Pd is intended to always reduce 
> atoms to their elemental type based on their content. Therefore, {symbol 
> 123} shouldn't really exist.

If I make symbol 123456789 it's because it's intended to stay 123456789. I 
don't want tclpd to bastardise it by assuming that i'm ok with an 
approximation of the number that it could be representing if my intent was 
really to represent a quantity instead of just having a string of 
characters.

Federico and I came to the conclusion that we came to because pretty much 
anything else sucked in some way. We don't care that Pd seems perfectly ok 
with blowing up the saving of symbols that look like numbers, and we don't 
care that you don't want support for pointers.

I don't think that you and I and all of us have to stick with mere 
original intents.

The main alternative I would have had to that, is to represent Pd symbols 
in Tcl as the Pd parser would accept them. This means that a float would 
be backslashed. But I had ruled that out because then there would be no 
way to represent a pointer, unless some extra syntax is designed, plus 
other reasons.

> Therefore, I think it would be better to just use normal Tcl lists, at 
> least for now.

If you do it "at least for now", you're stuck with it forever or so.

> Plus, I think Pd's type handling is partially modeled after Tcl's.

I don't know how you can argue that, but there's a large enough chunk of 
difference, that you could ignore the similarities. If Pd's type system 
was roughly like Tcl's, then users would never have to think about 
types in [pack], [unpack], [t], and such, for example.

  _ _ __ ___ _____ ________ _____________ _____________________ ...
| Mathieu Bouchard - tél:+1.514.383.3801, Montréal QC Canada