[e-lang] Expanding guarded ignore pattern?

[Kevin Reid]

On Dec 1, 2006, at 20:55, Mark Miller wrote:
> On 12/1/06, Kevin Reid <kpreid at mac.com> wrote:
>> 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.

I dislike the idea of getting rid of IgnorePattern as a kernel node.

While these reasons apply to guarded-ignore as well, I argue for the  
moment that it is a tradeoff and guarded-ignore is a much rarer case:

   -- __getAllegedType

   -- anonymous objects couldn't get numbered fqns easily

   -- aesthetics of expansions, and readability for manual inspection  
(having to check whether all these new variables are used anywhere)

-- 
Kevin Reid                            <http://homepage.mac.com/kpreid/>