[e-lang] Expanding guarded ignore pattern?
Mark Miller
erights at gmail.com
Fri Dec 1 19:55:30 CST 2006
On 12/1/06, Kevin Reid <kpreid at mac.com> wrote:
> I'm implementing the guarded ignore pattern (epatt`_ :int`) in E-on-
> CL. What I thought of first was to implement it as a nonkernel
> pattern, but I see that current E-on-Java seems to implement it as a
> kernel pattern.
>
> The possible expansions I've thought of are:
>
> sp__1 :int
> via (int.coerce) _
> via (fn s__1, e__1 { int.coerce(s__1, e__1) }) _
>
> The only reason not to make it nonkernel I can think of is its effect
> on __getAllegedType -- the first expansion will introduce a spurious
> name into the alleged type, but the others will hide the guard.
>
> On the other hand, I'd prefer not to introduce an optional guard into
> IgnorePattern and so complicate its semantics and implementation.
Of these, I like the first expansion best. The hiding of the guard
from __getAllegedType is, I think, adequate grounds to disqualify the
others. The spurious name issue is annoying but not terrible. It does
raise the issue: should we get rid of the ignore pattern from Kernel-E
completely, and always expand it to a spurious final variable? For
consistency, we should either keep both uses or get rid of both uses.
My mild preference is to keep both uses in Kernel-E for readability,
and because it's what we're currently doing. But I could probably be
convinced to get rid of both uses, for the sake of shrinking Kernel-E.
--
Text by me above is hereby placed in the public domain
Cheers,
--MarkM
More information about the e-lang
mailing list