23 Jun 22:43
Re: blah blah blah can't hear you
From: Frédéric Bonnet <fredericbonnet@...>
Subject: Re: blah blah blah can't hear you
Newsgroups: gmane.comp.lang.tcl.core
Date: 2008-06-23 20:43:53 GMT
Subject: Re: blah blah blah can't hear you
Newsgroups: gmane.comp.lang.tcl.core
Date: 2008-06-23 20:43:53 GMT
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)
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 (
RSS Feed