Jason Dagit wrote:
On 8/2/06, Nathaniel Gray <[EMAIL PROTECTED]> wrote:
You'll have to correct me if any of this is wrong, since this is my
first experience with Haskell, but I don't think records are the way to
go. Using records means every command has to supply every field. Why
should "darcs add" need to care about patchesApplied? It's bad enough
that all the possible env vars have to be defined in one place -- it
would be much nicer if common vars were defined together and vars that
only one command will supply were defined with that command, but I'm not
sure how to achieve that elegantly in Haskell.
It's not as bad as you might think. The record update syntax only
makes you specify the parts you want to update. Combine this with
maybe and you get nice results.
mkCmdStatus e = CmdStatus { cmdStatus'PatchesApplied = Nothing
, cmdStatus'ExitCode = e }
Then when a command returns it does something like:
(mkCmdStatus ExitSuccess) { cmdStatus'PatchesApplied = Just 3 }
Or perhaps even the exit code could be a maybe, in that case:
mkCmdStatus = { cmdStatus'PatchesApplied = Nothing
, cmdStatus'ExitCode = Nothing
}
mkCmdStatus { cmdStatus'ExitCode = Just ExitSuccess }
That would be the case when no patches were applied but the command
ran sucessfully. It's not so bad, the unspecified fields get the
value Nothing and then we ignore them.
Even with record update I would argue it's still not the right data
structure. It creates many complications for no benefit that I can
perceive. Consider how you go about actually creating an environment,
which is a list of String, String pairs. My conversion function is
extremely compact:
map (\ (x,y) -> ((show x), y)) env
I'm pretty sure doing the same with records would require gobs of
boilerplate. (Rinse and repeat for printing help descriptions.
Perhaps it would help if you clarified what you dislike about the way I
did it. Would you be happier we used a *set* of var, string pairs
instead of a list?
> I'm not sure if the formatting will look right when I send this.
> Basically, I line up the comma with the opening and closing bracket,
> line up the type signatures and then use the funny names.
I'll leave the discussions of indentation to those who have to live with
the code. Suffice to say it all looks weird to me. ;^)
Give it some time :) I find that some of the more 'odd' haskell
conventions become the ones I like best.
We'll see... ;^)
Cheers,
-n8
--
>>>-- Nathaniel Gray -- Caltech Computer Science ------>
>>>-- Mojave Project -- http://mojave.cs.caltech.edu -->
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
