23 Jun 23:45
Re: blah blah blah can't hear you
From: Neil Madden <nem@...>
Subject: Re: blah blah blah can't hear you
Newsgroups: gmane.comp.lang.tcl.core
Date: 2008-06-23 21:45:14 GMT
Subject: Re: blah blah blah can't hear you
Newsgroups: gmane.comp.lang.tcl.core
Date: 2008-06-23 21:45:14 GMT
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
RSS Feed