[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Chicken-hackers] [PATCH] Add more convenient condition object const

From: Peter Bex
Subject: Re: [Chicken-hackers] [PATCH] Add more convenient condition object constructor [was: Re: [PATCH] Turn chicken.condition into a module, with syntax exports!]
Date: Wed, 24 May 2017 08:58:46 +0200
User-agent: Mutt/1.5.23 (2014-03-12)

On Wed, May 24, 2017 at 05:53:04PM +1200, Evan Hanson wrote:
> 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))

That would be nice indeed.

> 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.

I only have a problem with the name, because if it were a true alist,
I would expect it to use dotted (property . value) pairs, not proper
lists of 2 elements.

Perhaps it's best to just change how condition->list works and call
it a day.

> 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)))

That's requires more keystrokes, but at the same time it's more readable.
Of course one reason to add the constructor is to have an API that's
less verbose, and this adds back a little bit more verbosity.  On the
other hand, the constructor is new so it's less hassle for users if we
changed that rather than the ->list that already exists.

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

I don't really care either way, but agree that the extra consistency is
nice here, so it's worth to change one of the two.


Attachment: signature.asc
Description: Digital signature

reply via email to

[Prev in Thread] Current Thread [Next in Thread]