Philipp Stephani <p.stephani2@gmail.com> schrieb am So., 4. Okt. 2015 um
11:41 Uhr:

>
>> >     3) How exactly do we represent catch/throw values?
>> >
>> >
>> > I've thought about this a bit, and I think it would be simplest to add a
>> > new function env->set_throw and have get_error and check_error return an
>> > enum { normal, signal, throw }. One could come up with something like
>> > creating a list (error-kind error-tag error-value), but it looks like
>> > the module implementation would create such lists only for the module
>> > code to convert them back, so it's simpler to represent the two kinds of
>> > non-local exits directly in the interface.
>>
>> I'm fine with a list; keep in mind that we'll need to handle OOM
>> somehow, so I'd suggest an opaque type.
>>
>
> I think OOM is currently handled by doing the equivalent of
>
> (apply #'signal memory-signal-data)
>
> so it would be part of the normal signal handling. Using a list would be
> possible, but then the distinction between error tag and data could be
> removed from the module code. But I think the 'magic lists' idiom common in
> Emacs is more of an antipattern and we should try to avoid it in the module
> interface, thus the suggestion to use an enum.
>
>

I've amended the PR with basic handling of throw. It's treated as if it
were at the top level, i.e. it generates a signal with symbol 'no-catch and
data (tag value). There is currently no functionality available to "throw"
from module code, and probably none is needed because "throw" is generally
used as a local control flow mechanism, and modules can use the control
flow mechanisms available in their languages instead.