On Mon, Jul 24, 2006 at 10:18:23PM -0700, Nathaniel Gray wrote:
> Jason Dagit wrote:
> >On 7/20/06, Nathaniel Gray <[EMAIL PROTECTED]> wrote:
> >
> >>I think that would do it. That would allow me to do 'darcs changes
> >>--last $N_PATCHES' in the posthook to generate a nice log message.
> >
> >I don't think this would be hard to implement (famous last words...)
> >and could possibly serve as good introduction to haskell/darcs. Are
> >you interested in trying to implement this? Maybe I could help
> >advise...
>
> Ok, now we're on darcs-devel so we can talk code. I suppose a sensible
> design would be to have each command return a list of string pairs
> representing additions to the posthook environment. For the moment,
> they would all return [] except for apply, which would return something
> like [("darcs_patch_count", "7")]. Let me know if there's another
> approach you'd prefer.
Sounds reasonable to me, but it'd be nice to also add something to the
framework to document which environment flags are set, and to arrange
things so the documentation (provided by --help) is always guaranteed
to be correct. And to make sure that the commands behave in a unified
manner. I'm thinking that we could perhaps achieve this in a
moderately friendly way with a:
data PostHookEnvironmentVariable = NUMBER_PATCHES | ChangeLogEntry | PhaseOfMoon
deriving ( Show )
and then add to DarcsCommand an entry like
data DarcsCommand =
DarcsCommand {command_name, command_help, command_description :: String,
...
command_posthook_envs :: [PostHookEnvironmentVariable],
which would list the defined environment variables, and then we'd have
...
command_command :: [DarcsFlag] -> [String] -> IO
[(PostHookEnvironmentVariable,String)],
which is equivalent to what you describe, but command --help can be
written to automatically include which post-hook env variables are
included. We can document the meaning of each variable in only one
place, with a function of type
document_post... :: PostHookEnvironmentVariable -> String
If this isn't possible, perhaps we should have different variable
names (i.e. you shouldn't reuse a posthook env variable to mean
different things for different darcs commands).
Then we could also have the command-running code verify at runtime
when running the posthook that the command provides all the promised
environment variables. It's not as nice as a static constraint, but I
don't see how we can do this statically. But still, a runtime check
should catch almost any errors.
The important thing is that we need to ensure that our post-hook
environment variables are properly documented, particularly since I
forsee that once we get started, we're likely to end up adding quite a
few of them.
> I see run_posthook in Test.lhs, which looks like the place to begin, and
> there's also consider_running in DarcsCommands.lhs. Hopefully the type
> checker will make it clear how to proceed from that point. Guess it's
> time to deal with the frustration of being an "expert beginner" all over
> again...
Indeed, that sounds like a good starting point, and yes, the type
checker is your best friend.
--
David Roundy
_______________________________________________
darcs-devel mailing list
[email protected]
http://www.abridgegame.org/cgi-bin/mailman/listinfo/darcs-devel
