Neil Madden | 23 Jun 23:45
Picon

Re: blah blah blah can't hear you


On 23 Jun 2008, at 21:43, Frédéric Bonnet wrote:
> Neil Madden wrote:
>
>>> FWIW, I think that your maybe package is very interesting, and  
>>> the implementation is clever in the way you store values. However  
>>> I don't like the maybe/just/nothing terminology, as it sounds too  
>>> foreign to Tcl. If I can make the following suggestion that I  
>>> think is more Tclish as far as the syntax is concerned: use {} (a  
>>> 0-sized list) for nothing, and {value} (a 1-sized list) for Just.  
>>> Hence:
>>>
>>>     set l { {a} {} {{}} }
>>>
>>> is a 3-sized list whose 2nd element is null and 3rd is the empty  
>>> string, encoded as {{}}
>> That is, of course, a possibility for the string rep. I have to  
>> call the constructors something, though. In which case, I'd prefer  
>> the string reps to match the constructor names; it makes it clear  
>> where the values have come from and makes it less likely to  
>> accidentally forget to unwrap a value.
>
> That's a good point. I have no problem with Nothing (or Unknown or  
> whatever), however Maybe and Just sound odd. Of course it makes  
> sense when you know Haskell, but the vast majority of people who  
> don't would certainly find this choice puzzling. But anyway that's  
> a matter of taste.

Several people have brought this up now. I'm not attached to the  
names -- they're just symbols. I'll bring out a new version with the  
constructors changed (version 2 already!). What would you prefer? I  
quite like Some x | None for the symmetry, but could go for NULL |  
Value x or something like that. I've no idea what to call the package/ 
ensemble though - "optional", "nullable", "possible"... (And, should  
the constructors be lower-case?)

>
> May I also suggest that your package be a sub-package of a larger  
> meta-package "functional", perhaps included in the tcllib  
> sometimes? E.g. "package functional::maybe". Functional programming  
> is a very powerful paradigm and a good fit with Tcl's immutable,  
> transparent, COW values, so it would make sense to import all these  
> concepts from a central place.

You are ahead of me! I already have a sort of meta-package "data"  
that is in various states of development: [data type] (algebraic  
datatypes), along with various functional/Tcl_Obj versions of the  
tcllib struct package (trees, graphs, linked-lists, lazy streams,  
closures etc). I also have a copy of Okasaki's "Purely Functional  
Data Structures" that I'm slowly working through... I've been meaning  
to polish off this package collection, matching struct::* APIs where  
possible, and providing efficient optional C/Critcl implementations.  
I'll see about getting it ready for release (and possible tcllib  
submission) over the next few weeks.

-- Neil
This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

-------------------------------------------------------------------------
Check out the new SourceForge.net Marketplace.
It's the best place to buy or sell services for
just about anything Open Source.
http://sourceforge.net/services/buy/index.php

Gmane