idiomatic ways to refer to the subject for multi-arm cores

[drbeefsupreme]

Hoon has four runes used for defining multi-arm cores: |%, |_, |@, and |^. We have at least a couple different ways in which we refer to the current subject in Hoon. For example:

Gall apps typically have:

|_  =bowl:gall
  +*  this  .

Cores made with |% often use ++:

|%
  ++  foo  .

A quick look for |@ and |^ runes with an arm whose content is just . didn't yield any results, but I didn't look for very long and am not clever enough with regular expressions to search the whole repo.

Can the appropriate lus rune to use always be directly inferred from the runes used to define the core? To be more precise, can we say something like "when you have a multi-arm core made with X bar rune and wish to name it, use Y lus rune".

Does this change at all when the core is iron/gold/zinc/lead/wet/dry?

What is it called when you name a core this way? Is it the face of the core, or some other name?

I suggest including this information in /docs/tutorials/hoon/style.md.

[belisarius222]

Only a |_ can use the +* rune to define virtual arms, as I found out recently.  I do not like this situation, but I don't know enough about it to fix it right now, so c'est la guerre.

— ~rovnys-ricfer https://urbit.org

On Tue, Apr 21, 2020 at 4:33 PM, poprox < notifications@github.com > wrote:

Hoon has four runes used for defining multi-arm cores: |% , |_ , |@ , and |^ . We have at least a couple different ways in which we refer to the current subject in Hoon. For example:

Gall apps typically have:

|_ =bowl:gall +* this .

Cores made with |% often use ++ :

|% ++ foo .

A quick look for |@ and |^ runes with an arm whose content is just. didn't yield any results, but I didn't look for very long and am not clever enough with regular expressions to search the whole repo.

Can the appropriate lus rune to use always be directly inferred from the runes used to define the core? To be more precise, can we say something like "when you have a multi-arm core made with X bar rune and wish to name it, use Y lus rune".

Does this change at all when the core is iron/gold/zinc/lead/wet/dry?

What is it called when you name a core this way? Is it the face of the core, or some other name?

I suggest including this information in / docs/ tutorials/ hoon/ style. md ( http://docs/tutorials/hoon/style.md ).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/urbit/docs/issues/858 ) , or unsubscribe ( https://github.com/notifications/unsubscribe-auth/AAGVR5PFNPUWJKCONHZMQC3RNX7J3ANCNFSM4MNTBBWA ).

[ohAitch]

{requesting departure from lawn voice} the idiomatic way is +>.^^^^$

On Tue, Apr 21, 2020 at 13:58, Ted Blackman notifications@github.com wrote:

Only a |_ can use the +* rune to define virtual arms, as I found out recently. I do not like this situation, but I don't know enough about it to fix it right now, so c'est la guerre.

— ~rovnys-ricfer https://urbit.org

On Tue, Apr 21, 2020 at 4:33 PM, poprox < notifications@github.com > wrote:

Hoon has four runes used for defining multi-arm cores: |% , |_ , |@ , and |^ . We have at least a couple different ways in which we refer to the current subject in Hoon. For example:

Gall apps typically have:

|_ =bowl:gall +* this .

Cores made with |% often use ++ :

|% ++ foo .

A quick look for |@ and |^ runes with an arm whose content is just. didn't yield any results, but I didn't look for very long and am not clever enough with regular expressions to search the whole repo.

Can the appropriate lus rune to use always be directly inferred from the runes used to define the core? To be more precise, can we say something like "when you have a multi-arm core made with X bar rune and wish to name it, use Y lus rune".

Does this change at all when the core is iron/gold/zinc/lead/wet/dry?

What is it called when you name a core this way? Is it the face of the core, or some other name?

I suggest including this information in / docs/ tutorials/ hoon/ style. md ( http://docs/tutorials/hoon/style.md ).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub ( https://github.com/urbit/docs/issues/858 ) , or unsubscribe (

https://github.com/notifications/unsubscribe-auth/AAGVR5PFNPUWJKCONHZMQC3RNX7J3ANCNFSM4MNTBBWA ).

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/urbit/docs/issues/858#issuecomment-617410695, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAOFPBUQF42PQSLBTGT26FLRNYCIBANCNFSM4MNTBBWA .

[ohAitch]

More seriously, I would advocate ++ this . in `|cores_ also, reserving+for patterns that can't be expressed without a macro. (Should we find any besides "transparent-faced"+<, which imo should be sth like abol=bowl:gall` syntax instead anyway)

[drbeefsupreme]

Only a |_ can use the +* rune to define virtual arms, as I found out recently.

What are virtual arms? I don't think I've heard that terminology before.

[drbeefsupreme]

(Should we find any besides "transparent-faced" +<, which imo should be sth like a bol*=bowl:gall syntax instead anyway)

Can you elaborate? I don't have any idea what you're talking about.

[ohAitch]

+* "arms" are a misfeature for defining core-level = macros; commonly used for `+ this .to refer to the core itself, which works just as well with++(either as an armthis(et c)or legfoo.this`). On further review of master I have not been able to find anything that is used for write-through capabilities actually.

There are however things like sc:/===/app/soto which afaict would type-fail if anything were ever to call it, but nothing does :)

Question for =* proponents: is my search missing any legitimate uses? There are a lot of variants on |_ abcd +* parent-core +>, which seem much less clear than =* parent-core . |_ abcd: it's not, after all, an alias in the context of the door.

[hoclun-rigsep]

https://github.com/urbit/arvo/issues/361 for a little background

[hoclun-rigsep]

More seriously, I would advocate ++ this . in `|cores_ also, reserving+for patterns that can't be expressed without a macro. (Should we find any besides "transparent-faced"+<, which imo should be sth like abol=bowl:gall` syntax instead anyway)

That's saying the same thing as https://github.com/urbit/arvo/issues/361#issuecomment-292750648, right?

I've been thinking about this the past few days—shouldn't hoon have "transparent faces," i.e. faces that do not obscure their noun to a limb search? I've been reading hoon.hoon and I am starting to think that I could implement this. We would have a new rune, perhaps ^/ (irreg. face/mold would be my first thought), and the core runes could apply faces to the battery, payload, sample, context where appropriate. We tell novice hooners that a core is a [battery payload]—why shouldn't you be able to call it that in the code? It would solve the problem of referring to stacked cores.

[hoclun-rigsep]

Can the appropriate lus rune to use always be directly inferred from the runes used to define the core? To be more precise, can we say something like "when you have a multi-arm core made with X bar rune and wish to name it, use Y lus rune".

As I understand it, +* this . is used in gall agents because ++ this . would cause the resulting core to fail to nest in the agent:gall interface. As before, I do not like seeing boilerplate in the code, and I hate seeing the word "this" in the code, and believe this could be improved.