--- Clint Jeffery wrote: > > > I've been thinking some more about that. It > looks to me like we just have > > to be careful about character combinations in > creating new tokens. > > That might be all we have to do, but we will have to > live with this for > the next 40 years so what we want to do is pick the > very best notation > we can, so I am willing to be picky.
Yes - agreed. > > > I think that [< >] for tables rather than < > > makes a table constant look > > like a list With Something Special, which they > kind of are. > > This is an especially useful comment; I have been > systematically extending > operators to be more polymorphic, and thinking of > tables as a special list > (or rather, I think of lists as a special table > whose keys are constrained) > suggests that the notation be similar. Yes. > > So if table and set constructors are based on the [] > constructor that > would work for me, I am just not thrilled with [< Nor am I. > and >] yet; create > new tokens only when existing tokens won't do the > job.. And Yes. > > Sudarshan Gaikaiwari should have posted here about > his proposed new > (snobol style) pattern data type by now, but in case Interesting. > he hasn't, I think > it includes a -> operator which might mean that > token is spoken for > (and yes, adding a pattern type introduces some new > tokens). > > [ k1 : v1, k2 : v2, k3 : v3, : dedefv This makes sense and feels right. Much nicer than [<>]. > and > [: v1, v2, v3, v4 :] Ummh I'm not sure about that. > > are not too bad for tables and for sets, > respectively. > [:] would be the empty table > [::] would be the empty set I think of sets as bags of keys. And sets/tables as being closer than lists. I've always wondered about extending set operations to tables. But that is another thread. :-) > > But other folks may see problems or find this > notation vile. > :-) [::] seems somehow more than [:] and a bit counter intuitive. It looks and feels a bit odd for sure, but I wouldn't go as far as vile. Problem is I can't think of an alternative right now that wouldn't have the same problem. Using [: k1:v1 :] would give [::] and [:::] as empty sets and tables, but I'm not sure I like the non-empty table syntax. Something like [.] looks more interesting but probably would cause all kinds of problems. Not the least of which is how do you code the non-empty version. I'm also not sure if we were starting from scratch to integrate the notation for lists/sets/tables that we wouldn't end up at the same point anyway. The only places I briefly thought about for possible conflicts were the sectioning syntax and addressing into records. I doubt either is a problem. On the other hand, sets are probably least used so making the notation for an empty set longer than tables or lists isn't unreasonable. BTW. Does anyone know if tables/lists are more frequently used? > > Clint David (My ISP's webmail interface has been garbling some words, I may have missed one or two) ------------------------------------------------------- This SF.Net email is sponsored by the JBoss Inc. Get Certified Today Register for a JBoss Training Course. Free Certification Exam for All Training Attendees Through End of 2005. For more info visit: http://ads.osdn.com/?ad_id=7628&alloc_id=16845&op=click _______________________________________________ Unicon-group mailing list Unicon-group@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/unicon-group
