Frédéric Bonnet | 23 Jun 22:43

Re: blah blah blah can't hear you

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.

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 
(Continue reading)

Neil Madden | 23 Jun 23:45

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  
(Continue reading)

Frédéric Bonnet | 26 Jun 21:52

Maybe package (was Re: blah blah blah can't hear you)

Neil Madden wrote:
> 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?)

Perhaps we should run a little poll ? ;-)  I like Unknown/Value or 
Nothing/Value. But on second thought, if it's part of a larger package 
with Haskell-inspired constructs, then maybe (pun intended) we should 
keep the original names.

> I've been meaning to polish off this 
> package collection, matching struct::* APIs where possible, and 
> providing efficient optional C/Critcl implementations.

Take a look at Odyce (http://wiki.tcl.tk/20086). Currently it is only 
part of the eTcl distrib, but the creator considers releasing it as a 
separate extension. As it's TinyCC-based, it's fully embedded and no 
existing C compiler toolchain is required on the client machine. I've 
used it successfully for my Cloverfield parser.

-------------------------------------------------------------------------
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
(Continue reading)


Gmane