chicken-hackers
[Top][All Lists]
Advanced

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

Re: [Chicken-hackers] "simple" SRFI 12 condition api


From: Kon Lovett
Subject: Re: [Chicken-hackers] "simple" SRFI 12 condition api
Date: Thu, 25 May 2017 13:25:09 -0700

> On May 25, 2017, at 5:03 AM, Peter Bex <address@hidden> wrote:
> 
> Hi, Kon!
> 
> I wonder if you still remember the mail below.  It's over 2 years ago,
> but finally I've made a patch to include a procedure like make-condition+
> in CHICKEN 5.
> 
> See http://lists.gnu.org/archive/html/chicken-hackers/2017-05/msg00071.html
> 
> Now, there's a small discussion about what to do with the format, because
> condition->list uses a slightly different list representation of
> conditions.  The idea is to unify the format, but we're wondering whether
> we should change condition->list to match the new constructor, or vice
> versa.  See the follow-up posts for this discussion.

In this instance I think convenience should override precedence. So 
condition->list should return a plist. I think the plist makes a more 
user-friendly literal.

I know the goal is not to add to the core but maybe adding the plist <-> alist 
conversion functions from list-utils eggs would help. (Unless Chicken 5 is 
removing the symbol property-list.)

> 
> Do you have an opinion on the matter?  Feel free to mail to
> chicken-hackers!
> 
> Cheers,
> Peter
> 
> On Fri, Aug 29, 2014 at 10:14:14AM -0700, Kon Lovett wrote:
>> On Aug 29, 2014, at 9:47 AM, Peter Bex <address@hidden> wrote:
>> 
>>> On Fri, Aug 29, 2014 at 09:21:24AM -0700, Kon Lovett wrote:
>>>> (Sorry to drag this out)
>>>> 
>>>> Something like:
>>>> 
>>>>    (make-condition+ `(exn location loc message "foo") `(i/o) `(file 
>>>> filename ,file))
>>> 
>>> Ah, condition-utils already has it!
>>> 
>>> Well, maybe we can pull that into core?
>> 
>> After a little code review & public discussion. (make-*-condition(+) is from 
>> '09 but I only fixed today the requirement of a 'message property for 'exn; 
>> the Error printer wants a message property.)
>> 
>> This is another example of a (widely?) useful extension but not really 
>> "core" functionality, i.e. not primitive in the foundation sense.
>> 
>> But encouraging (by facilitating?) people to throw exceptions is a worthy 
>> goal. The trick is getting them to document said exceptions ;-)
>> 
>> Maybe there is the start of a heuristic for deciding what should be "core" 
>> above & beyond what is primitive: does it encourage a desired coding style.
>> 
>> BTW, condition-utils also has syntax for creating condition predicates & 
>> property getters. However the memeoized nature of the implementation might 
>> be a turn-off.
>> 
>>> 
>>> Cheers,
>>> Peter
>>> -- 
>>> http://www.more-magic.net




reply via email to

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