Custom Query (1630 matches)

An "unexport" form for modules would be useful. For example, this would only export the identifier "b":

(module m1 *
  (import chicken scheme)
  (define a 1)
  (define b 2)
  (unexport a))

This idea came out of #1376 and ​associated discussions on the mailing list. This would be a counterpart to "export", used to adjust the export list of a module from within its body.

megane has posted a patch on ​chicken-hackers, but it will need to be updated to apply to chicken-5.

User "kluk" brought up on IRC that it would be nice to have line number information in the interpreter, for better error reporting. This is somewhat problematic because the interpreter has to deal with potentially unbounded input, as one can reload files interactively or have code be evaled at will.

Perhaps a relatively simple solution would be to use a weak hash table for the line number database.

Since we already *have* weak pairs in core, perhaps we should simply expose these to the user (and csi).

We could use this API from MIT Scheme:

​https://web.mit.edu/scheme_v9.2/doc/mit-scheme-ref/Weak-Pairs.html

Also in Chez Scheme:

​https://cisco.github.io/ChezScheme/csug9.5/smgmt.html#./smgmt:h2

Then this could form the basis of a weak hash table API as well. Perhaps best left as an internal API (just like other compiler hash tables are also internal). Later someone(TM) can provide an egg with a proper weak hash table API.

We should probably also look seriously into ephemerons (a la ​https://srfi.schemers.org/srfi-124/srfi-124.html), but from ​https://scheme-48.s48.narkive.com/YJq3GJOw/ephemerons-long-message-with-a-brief-preamble it seems these are somewhat trickier to implement, so that might be for a later version.

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