[urbit] Fish faces

[Dan Haffey]

As mentioned in talk earlier, it'd be nice if there was a way to bind local
aliases when pattern-matching ("fishing"?):

=+ a=`(unit)`[~ 42]
?+ a ~
{* b/*}
`+(b)
==

Currently, it appears that faces in the mold being tested do make their way
into the scrutinee's type, but they get inserted underneath any existing
faces, rendering them practically useless. To use b in the above example
you'd have to write b.u.a.

This seemed like something that could be implemented as a combined
"if-fits" macro, since it would have access to both the mold and the yes
branch. The idea being that ?- and ?+ would use the new macro instead of
?:(?=(...)). Eg, if the new rune was ?%, then this:

?% {* b/*} a
[%yes b]
%no

would expand to:

?: ?=({* *} a)
=* b +3:a
[%yes b]
%no

I hacked up a naive proof-of-concept expansion
<https://gist.github.com/dhaffey/2ee9e7bf712c6a2fc5c10c037d7eced8>. It
hijacks :^ to stand in for the new rune, since it wants four sub-twigs and
testing is easier with something ream-able. It only binds faces appearing
in a literal mold, which can be viewed as a bug or a feature. Seems like a
feature to me, binding locally-sourced names is the whole point and fishing
with faces is otherwise fairly pointless.

So it is doable as a macro, but only for certain values of "do". The
problem with that expansion is that it preserves faces already present at
the aliased axis. Not really an issue for atoms, but if you wanted to
access foo.bar.b you'd be out of luck on account of the original u= face
provided by unit. You'd have to write foo.bar.u.b instead, blegh. (There's
actually more interference in my implementation because I didn't bother
scraping faces out of the mold before handing it off to ?=, but that
wouldn't be hard to do.)

So a proper treatment probably requires deeper compiler integration, at
least enough to allow the alias to drill down through any faces present at
the axis. Which sounds like a fun project, but a bit much to bite off
without getting some feedback on the basic idea and approach first. (And
I'm ++knee-deep in a regex implementation I'd like to finish to before
digging into an area as context-heavy as the compiler.)

Anyone interested in something like this existing? And/or implementing it?
:)

[Curtis Yarvin]

A nice hack, but obviously you can't really do this properly as a macro.

Actually what you're doing here is even more unconstitutional than a
macro -- it's source-to-source translation. Hoon does this basically
nowhere.

Once you establish the principle than an expression may be rewritten
by its context to mean something else, or the source form of the
expression (eg, a "literal mold") and not simply its product defines
its semantics, no twig will ever feel safe again. Keeping this
transformation as simple as possible helps keep the programmer
comfortable that his twigs will never be interpreted non-literally.

And yet, your feature doesn't seem utterly unachievable. Or
undesirable. It would just require actually wrestling with ++ut.

I remember fighting with this problem quite zestfully, like, five
years ago at least. Fishing (pattern-matching) began as a more
generalized intersection thing, and then became stupider as time went
on. I haven't really regretted this enstupening.

It is of course the icon that ++fish has access to, not the mold --
the span produced by bunting the mold. This makes no particular
difference.

Can a face in the icon being used as the fish-hook be defined as
etching away any number of faces on the span below it? I suppose it
could, although historically Hoon has been wary of this kind of
special-case complexity. But I can't see what harm it would cause, as
we basically never put faces in our icons. It's a UI feature, after
all, and UIs are inherently gnarly.

So I think it is perhaps worth a try. The ++fish:ut code is certainly
not terribly complex -- although note that you have to modify the C
jet at the same time, because it is called directly from the ++mint:ut
jet and friends. Sorry, this is some of the oldest and gnarliest jet
interface code for obvious reasons.

When operating on spans, you need to have a careful sense in your mind
of what your code will do for each of the span stems. Note also that
you don't need a recursion blocker of any kind if you don't traverse
cells. Also, it is bad manners to pay any undue attention to %hold or
%fork -- just traverse through them.

I would certainly not attempt this mountain at the same time as
regexps! But anyone else is presumably welcome to try it while
~ladhut-docfyn is in his current labyrinth...

Post by Dan Haffey
As mentioned in talk earlier, it'd be nice if there was a way to bind local
=+ a=`(unit)`[~ 42]
?+ a ~
{* b/*}
`+(b)
==
Currently, it appears that faces in the mold being tested do make their way
into the scrutinee's type, but they get inserted underneath any existing
faces, rendering them practically useless. To use b in the above example
you'd have to write b.u.a.
This seemed like something that could be implemented as a combined "if-fits"
macro, since it would have access to both the mold and the yes branch. The
idea being that ?- and ?+ would use the new macro instead of ?:(?=(...)).
?% {* b/*} a
[%yes b]
%no
?: ?=({* *} a)
=* b +3:a
[%yes b]
%no
I hacked up a naive proof-of-concept expansion. It hijacks :^ to stand in
for the new rune, since it wants four sub-twigs and testing is easier with
something ream-able. It only binds faces appearing in a literal mold, which
can be viewed as a bug or a feature. Seems like a feature to me, binding
locally-sourced names is the whole point and fishing with faces is otherwise
fairly pointless.
So it is doable as a macro, but only for certain values of "do". The problem
with that expansion is that it preserves faces already present at the
aliased axis. Not really an issue for atoms, but if you wanted to access
foo.bar.b you'd be out of luck on account of the original u= face provided
by unit. You'd have to write foo.bar.u.b instead, blegh. (There's actually
more interference in my implementation because I didn't bother scraping
faces out of the mold before handing it off to ?=, but that wouldn't be hard
to do.)
So a proper treatment probably requires deeper compiler integration, at
least enough to allow the alias to drill down through any faces present at
the axis. Which sounds like a fun project, but a bit much to bite off
without getting some feedback on the basic idea and approach first. (And I'm
++knee-deep in a regex implementation I'd like to finish to before digging
into an area as context-heavy as the compiler.)
Anyone interested in something like this existing? And/or implementing it?
:)
--
You received this message because you are subscribed to the Google Groups "urbit" group.
To unsubscribe from this group and stop receiving emails from it, send an
For more options, visit https://groups.google.com/d/optout.