Re: [Chicken-hackers] [PATCH] Add more convenient condition object constructor [was: Re: [PATCH] Turn chicken.condition into a module, with syntax exports!]

[Evan Hanson]

Hi Peter,

Nice work, this is a great idea.

I'm definitely in favor of a procedure like this, but I do have one
thought regarding the specifics: the procedure `condition->list` already
defines a convention of sorts for representing the constituent parts of
a condition as data, whereas this new constructor introduces another. I
think it would be valuable to align the two so that the following holds:

  c = (apply condition (condition->list c))

The only real difference is the representation of properties in the cdr,
alist vs. plist. Personally, I think plists are nicer to use, so I'd
propose changing `condition->list` to return the same sort of list the
new procedure expects as its arguments, and possibly adding a
`condition->alist` that provides the old behaviour, so that:

  (list '(exn location "foo" message "hi") '(file bar 1))
    =
  (condition->list 
   (condition '(exn location "foo" message "hi") '(file bar 1)))
    = 
  (condition->list
   (make-composite-condition 
    (make-property-condition 'exn 'location "foo" 'message "hi")
    (make-property-condition 'file 'bar 1))))

However, it would of course be possible to go the other direction and
make `condition` use the existing convention instead:

  (condition '(exn (location "foo") (message "hi")) '(file (bar 1)))

Does anyone have a strong argument for or against one of these options?

Evan

signature.asc
Description: PGP signature