[e-lang] Expanding guarded ignore pattern?
tribble at e-dean.com
Sat Dec 2 19:06:37 CST 2006
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`
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
> e-lang mailing list
> e-lang at mail.eros-os.org
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the e-lang