chicken-janitors
[Top][All Lists]
Advanced

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

[Chicken-janitors] #474: Additional library procedure condition->list


From: Chicken Trac
Subject: [Chicken-janitors] #474: Additional library procedure condition->list
Date: Fri, 07 Jan 2011 19:05:29 -0000

#474: Additional library procedure condition->list
-------------------------------+--------------------------------------------
 Reporter:  ckeen              |       Owner:       
     Type:  enhancement        |      Status:  new  
 Priority:  not urgent at all  |   Milestone:  4.7.0
Component:  core libraries     |     Version:  4.6.x
 Keywords:                     |  
-------------------------------+--------------------------------------------
 I would like to add introspection facilities for conditions to our chicken
 library core. Programs should be able to know which properties are
 available.

 Rationale:

 Programs currently have not a good method of inspecting conditions.
 Property names have to be known in advance, there is no introspection
 facility as there is no way of querying the properties that are available.

 csi's describe function atm does peek inside the slots directly.

 Sometimes I do have the need to convert exceptions programmatically to
 either some other exception or structure. The way this can be done up to
 now is to use ##sys#slot and peek into the internal record structure which
 is fragile.

 After some initial thoughts there is:

 Way 1:

 With the exception->list procedure properties and their values are
 returned in one list, ordered by exceptions.

 Example:

 {{{
     Example:
     (condition->list http-client-condition)
      => ((exn (arguments
                 (#<URI-common:...>))
               (message "Client error: 400 Bad Request")
               (location call-with-input-request))
          (http)
          (client-error
             (body "\"invalid UTF-8 JSON\"}")
             (response #<response>)))
 }}}

 (output shortened for readability)

 Way 2:
 Why everything into one list? Well I guess it could be split up into two
 parts, a query api for introspection and then the usual get-condition-
 property-accessor dance as well. For composite conditions this could
 amount to lists like:

 {{{
 ((exn location arguments message)
  (http)
  (client-error response body))
 }}}

 This could then again traversed to extract the wanted properties.

 I have attached a patch that implements this procedure as described in way
 1. As well the additional test case for it. As a bonus it adds test cases
 for the exception slots so we can tell it this breaks in the future.

 I am interested in suggestions or even a better way to do this. Maybe way
 3...

-- 
Ticket URL: <http://bugs.call-cc.org/ticket/474>
Chicken Scheme <http://www.call-with-current-continuation.org/>
Chicken Scheme is a compiler for the Scheme programming language.

reply via email to

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