[e-lang] Expanding guarded ignore pattern?

[Dean Tribble]

If IgnorePattern is special, then you cannot simply match an interesting
kernel-E tree to, for example, extract the guard.  "_" does not seem
interesting enough to motivate having a redundant pattern for it.  Thus, I
would expect that:

? e`def _ :int := 3` =~ e`def @n :@g := @v`
# false

Would actually return true, with n bound to "_" or even null (because
essentially, no name was supplied).  "_" is equivalent to using a unique
name, so there seems little value in having anything special there.  Indeed,
since you cannot express a reference to "_", having it *actually* define "_"
might even be valid, semantically.

Where would you use this?  My slang parser has checks whether guards are
well-known in several locations (e.g., void, any, int) and does various
optimizations as a result.  It doesn't care whether there's a name or not,
and yet I end up needing to handle that special case in a bunch of places.
It generally does care about def vs. var vs. slot, so I'm not worried about
those being different.

On 12/2/06, Mark S. Miller <markm at cs.jhu.edu> wrote:
>
> Kevin Reid wrote:
> > 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)
>
>
> Ok, these are good reasons for keeping the ignore pattern. For
> consistency, I
> still think we should then keep guarded-ignore as well.
>
> --
> Text by me above is hereby placed in the public domain
>
>     Cheers,
>     --MarkM
> _______________________________________________
> e-lang mailing list
> e-lang at mail.eros-os.org
> http://www.eros-os.org/mailman/listinfo/e-lang
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.eros-os.org/pipermail/e-lang/attachments/20061202/6a1122e8/attachment.html