This is the mail archive of the kawa@sourceware.org mailing list for the Kawa project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: GSOC | Extending Common Lisp support


* Charles Turner [2012-06-13 14:43] writes:

> Currently implementing the EXPORT feature. I've attached some code
> showing how I think it should be done. One thing I've noticed in ANSI
> is the notion of correctable errors with some package conditions (such
> as name conflicts, missing symbols...). I've highlighted where such
> interactions will need to be performed in my code, but I'm wondering
> if there is any existing framework in Kawa for this kind of stuff (Per
> has normally covered all bases :-)).

In theory, Kawa/Scheme should have something like with-exception-handler
from R6RS.  In practice, Kawa uses Java exceptions to handle errors and
that makes it almost impossible to get continuable errors as required
for CL.

Until Kawa gets a working with-exception-handler, I would suggest that
you as an idiom like:

  throw signal(<error message>)

where signal is a method like

  RuntimeException signal(Throwable error) { 
     throw new RuntimeException(error);
  }

Currently signal would just turn any error into an RuntimeException and
throw it, but in the future it could invoke the current exception
handler.

> I imagine the whole prompting
> business will require its own abstraction somehwere (condition systems
> in CL?) as the notion seems quite pervaisive in CL (I'm always getting
> dropped into "Blah blah blah, select from the following restarts:"
> when experimenting with CL.

Restarts are built on top conditions.  Should be relatively easy once
conditions work (which is not likely to happen anytime soon).

> public static void export (LList syms, LispPackage pkg)
>   {
>     Stack<Symbol> validSyms = new Stack<Symbol>();
>     Iterator symiter = syms.getIterator();
>     Symbol s;
>     Values v;
> 
>     while (symiter.hasNext())

I wonder why this can't be written as 
    for (Symbol s : syms) 
Ah, I see LList is not generic.  Maybe it should be.

>     {
>       s = (Symbol) symiter.next();

I think syms can also contain strings, not just symbols.

>       v = pkg.findSymbol(s.getName());
>       if (v.get(1) != CommonLisp.FALSE
>           && !validSyms.contains(s))
>       {
>         validSyms.push(s);
>       }
>     }
> 
>     NamespaceUse usedBy = pkg.imported;

I think this should be: usedBy = pkg.importing

Helmut


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]