Re: [Tcllib-devel] dictutil commands on the wiki ...

[Neil M. <ne...@Cs...>]

On 13 Feb 2007, at 19:21, Andreas Kupries wrote:
...
>> Problem is the format -- should it be a simple [eq? $a $b]
>> or include the index too [eq? $i $a $b]? The first is simpler (and
>> allows using things like {string equal}), whereas the latter is
>> perhaps more flexible (e.g., if a list is being used like a tuple).
>
> Hm. My gut feeling just after reading the above is have it with  
> index, with
> the antagonistic part of me asking for a concrete example where it  
> would
> truly be useful. Which I don't have, causing me overall to sit on  
> the fence
> here. I wonder how much of a problem having the index would be,  
> given that
> 8.5 also has apply and thus the ability to write anon wrapper  
> commands to
> get something like 'string equal' to work.

It's hard to say. The only good cases I can think of, it'd be just as  
easy to write a new equality check anyway, doing something like:
   foreach type $types a $as b $bs {
       if {![$type equal $a $b]} { return 0 }
   }

>> I've some other bits of code that could be contributed to tcl/tklib
>> at some point:
>>
>> * A higher level channel API (http://wiki.tcl.tk/17012) -- I have a
>> bunch of updates/changes to this that I want to finish up, then I
>> think it might be worth adding.
>
> Hm. Interesting. Note that I recently added some higher-level  
> channel stuff
> as well, see the 'transfer' packages (transfer::connect ,  
> transfer::copy ,
> transfer::data::destination , transfer::data::source ,  
> transfer::receiver ,
> transfer::copy::queue , transfer::transmitter)

Great. I'll have a look and see whether my stuff fits in with any of  
that.

>> * A thread-safe message queue (http://wiki.tcl.tk/17652) -- might be
>> better bundled directly with the Thread extension, but could also go
>> in tcllib. I have some tests and docs for this too, so it could go
>> straight in (subject to review).
>
> I agree with the sentiment that this belongs more with Thread than  
> tcllib.

Yes. Are tcllib modules even allowed to depend on Thread?

>
> Hm. ... It seems you are using the 'shared var' facility of Thread to
> implement them. I wonder if it might be easier to use  
> 'thread::send' as a
> basis instead, i.e. the C-level event (message) queue as the  
> foundation.

Not really. With thread::send the consumer thread must enter the  
event loop, either by calling vwait or by unwinding to a top level  
event loop. Sometimes you want more control than that. For instance,  
you might not want posted jobs to start processing just because you  
called tk_messageBox. Similarly you might not want other events to be  
processed when you need a message from a queue. You might also want  
to accept messages from different queues at different times:

  set msg1 [mqueue pop $queue1]
  ...
  set msg2 [mqueue pop $queue2]

Or you might want to filter which messages you actually accept. You  
can't have that control with a single big event queue. (This is a  
pain I've felt even in single threaded Tk apps on occassion --  
wanting more control over exactly which events get processed).

...
>> I also have a variety of other bits and pieces sitting on my laptop
>> that could be polished up -- e.g., an "article" widget for  
>> displaying/
>> composing email/usenet articles,
>
> Interesting. A new mail/news reader in Tcl/Tk ?

A fairly substantial rewrite of the code in http://wiki.tcl.tk/11104  
that never really got finished.

>
>> various implementations of algebraic
>> datatypes
>
> Which types ? And what advantages do we get from their algebraic- 
> ness ?

No types in particular (probably a BST and some others). More the  
framework, which allows you to do things like:

   datatype cons BST = Leaf
   datatype cons BST = Branch left val right
   set tree [Branch [Leaf] 3 [Branch [Leaf] 5 [Branch [Leaf] 6 [Leaf]]]]
   proc toList tree {
       datatype case BST $tree {
           Leaf            -> { return {} }
           {Branch l v r}  -> { concat [toList $l] [list $v] [toList  
$r] }
       }
   }

Note the "BST" here is just sugar -- no type checking goes on (yet).

-- Neil