Re: GSOC | Extending Common Lisp support

[Helmut Eller <eller dot helmut at gmail dot com>]

* Per Bothner [2012-06-13 22:53] writes:

> On 06/13/2012 01:44 PM, Helmut Eller wrote:
>> 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.
>
> Why signal return a RuntimeException, rather than void?
> Did you mean:
>
>   RuntimeException signal(Throwable error) {
>      return new RuntimeException(error);
>   }
>
> What is the advantage over:
>
> @NeverReturns void signal(Throwable error) {
>      throw new RuntimeException(error);
> }
>
> (where @NeverReturns is annotation I'm planning on adding).
>
> Actually, I can see an advantage of having the user code do the throw,
> since then the VM knows about it and doesn't get confused
> about unreachable code.  But I'm working on fixing Kawa to
> avoid such problems.

Would  

  Object foo () { signal("not yet implemented"); }

pass the bytecode verifier?

>
>> Ah, I see LList is not generic.  Maybe it should be.
>
> Tricky, given that Pair needs not actually be a (true) list.
> So Pair isn't always a Sequence, in spite of the current
> usually-but-not-always-correct class hierarchy.
>
> Conceptually, you have:
>   class Pair<CAR_T, CDR_T>
> and
>   typedef List<T> = Union(Empty, Pair<T,List<T>>
>
> I guess ...  Not sure how to model this in Java,
> though of course the Kawa typesystem isn't bound by Java.

Hmm.. 

    LList syms ...
    java.util.Collection<Symbol> seq = (java.util.Collection<Symbol>)syms;

seems to work just fine.

Helmut