Remove vestigial tap argument

[ohAitch]

I do not believe I've ever seen tap:by in any form other than (~(tap by foo)). Would anyone (@cgyarvin, @philipcmonk) mind if I added a +- all (tap) to by, in, to, and converted existing code to use it? Perhaps tap should go altogether, but that would involve (minor) mucking with jets, official deprecation, etc.

[juped]

• gas is append list elements to set, tap is append set elements to list, so I have no idea what you intend by +- all (gas)
• if you meant +- all (tap), you would have to replace (~(tap by s)) with, uh, (~(all by s))
• if you meant something about gassing, casual containers exists
• even if nobody ever uses gas or tap with anything but an empty set/list, which is pretty dubious, the argument still provides the type to use

[ohAitch]

Oops, definitely meant (tap) in the end there yeah. edited

[ohAitch]

• no, I would replace (~(tap by a)) with ~(all by a), no outer "kick" parens. The motivation here is unwarranted boilerplate.
• gas is definitely used(on non-empty lists), tap is always(afaict) used without arguments so it sure isn't being provided at the call site. In practice tap uses (list _?~(a !! n.a)), which is the right type.

[juped]

OK, sure, let's replace tap while we can still cheat it in there, but only if there's no uses.

[juped]

(Do I want to know why tap is a +- |=?)

[ohAitch]

I mean, "tap into accumulator" sounds maybe useful, but without is definitely the common case; this is why I'm proposing a new name. Though I suppose if it does never get used, tap can be considered deprecated, and the thing renamed back to tap eventually(I recall something similar happening with union/difference).

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

OK, sure, let's replace tap while we can still cheat it in there, but only if there's no uses.

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186855382.

[juped]

I would suspect it to be used in jug or whatever, but you're the proposer, presumably you've been doing due diligence?

[ohAitch]

Performance optimization, so that you can e.g. (roll list-of-sets |=([a=small-set b=big-accumulator](~%28tap in a%29 b)) without having to re-weld every time. In practice I don't think I' ve ever seen it come up.

On Sunday, 21 February 2016, Anton Dyudin antechno777@gmail.com wrote:

I mean, "tap into accumulator" sounds maybe useful, but without is definitely the common case; this is why I'm proposing a new name. Though I suppose if it does never get used, tap can be considered deprecated, and the thing renamed back to tap eventually(I recall something similar happening with union/difference).

On Sunday, 21 February 2016, Raymond Pasco <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

OK, sure, let's replace tap while we can still cheat it in there, but only if there's no uses.

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186855382.

[juped]

Right, I'd expect it in jar/jug if anywhere. Those are pretty barebones right now, though. Anyway, isn't optimization for jets? :)

Can't kick the can to an unspecified future, though. If you foresee "deprecating" something, then do it now, or don't.

[ohAitch]

Idk about "been", there's a reason this is phrased as "hey everyone else, have /you/ ever used the non-empty version?"

But I can't remember off the top of my head seeing any hoon that used it, except a couple examples I contributed to documentation; and this has been slightly bugging me pretty much every time I have the extra parens in a one-liner, and I couldn't think of any usage any of those times either.

Wrt jugs, I think they currently don't /have/ tap/gas; but they should, and that would be valid usage yes. Though I wouldn't be too worried if tap in current form /didn't/ already exist, the definition used weld, and got jetted if there were memory thrashing problems(which there would be from function calls anyway).

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

I would suspect it to be used in jug or whatever, but you're the proposer, presumably you've been doing due diligence?

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186855805.

[ohAitch]

I'd prefer to have a set timeline, so everybody gets a chance to quietly port their branches; but fair enough

[juped]

Jugs have some kind of gas. gas gasses into an accumulator too, it's just that it's the prettier (gas:in etc) when you don't, which doesn't offend your taste.

The issue is that when the incredibly informal times end, changing jetted library functions will be a lot more difficult.

[juped]

And probably involve sacrificing a kelvin.

[juped]

I think it's just bad early Hoon style, however - I see accumulator arguments that are never actually replaced in the sample in a lot of old code. If tap didn't tap into an accumulator, we'd never miss it...

[ohAitch]

I believe the official solution for strongly bound names is to come up with new names(see: marks), which doesn't sit well with me in general but is probably fine in this case. A kelvin would have to be sacrificed anyway if you were to add the functionality in the first place, and make it checkable by /?. In practice this is folded into breaches :/

Generally I feel like we are at(and started at!) far too few kelvins, preventing good development practices. Minor version numbers are useful.

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

And probably involve sacrificing a kelvin.

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186856773.

[cgyarvin]

Of course the non-empty version is there because otherwise you need to weld. But I would be perfectly ok with ~(all by set), etc.

We also need a ++li that's the equivalent of in and by. This can be done later with plenty of bikeshedding, though.

On Sun, Feb 21, 2016 at 8:54 AM, Anton Dyudin notifications@github.com wrote:

I'd prefer to have a set timeline, so everybody gets a chance to quietly port their branches; but fair enough

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186856663.

[ohAitch]

It's there, the question is whether it is ever used, especially in unjetted code.

[ohAitch]

Wrt ++li, if the syntax was #16 made less heavy-handed maybe, and I agree that limo/homo should go to the constructors section, but I'm fond of things like (~(run by a-jug) lent).

[juped]

cf. (~(gas by a) b), which is both there and used, because having to put:by one at a time would suck. No analogous case exists for tap that I can think of.

Only vaguely apropos, but I seem to recall a (map something ~) in extant code, which should obviously be a (set something).

[ohAitch]

It's in arch for performance reasons, being stripped from a (map something value). I am not sure how justified those performance reasons actually are.

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

cf. (~(gas by a) b), which is both there and used, because having to put:by one at a time would suck. No analogous case exists for tap that I can think of.

Only vaguely apropos, but I seem to recall a (map something ~) in extant code, which should obviously be a (set something).

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186913051.

[juped]

And while we're making up heap-based container wishlists, I need to add an arm for treap join, the other internal algorithm operation besides treap split (+-bif) - it's in the curious position of being jetted (as a helper function) but not implemented in Hoon...

[ohAitch]

Treap join as separate from +- uni? I think it's not an arm because it's interleaved with most of the algorithms. P

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

And while we're making up heap-based container wishlists, I need to add an arm for treap join, the other internal algorithm operation besides treap split (+-bif) - it's in the curious position of being jetted (as a helper function) but not implemented in Hoon...

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186914740.

[juped]

Join is not union, it's a lower-level operation just like split is. The algorithms are naive. It's not an arm because I couldn't think of a punchy three-letter name. I should be able to given time. :)

[ohAitch]

Ah, the thing at the bottom of +-del which assumes nonintersection? +-mer perhaps, I can see why del being defined as ?~(a ,~ |=(b/_n.a (mer (bif b)))) would be cleaner.

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

Join is not union, it's a lower-level operation just like split is. The algorithms are naive. It's not an arm because I couldn't think of a punchy three-letter name. I should be able to given time. :)

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186918361.

[juped]

It's a matter of following the standard literature. mer is an alright name, if a bit aquatic...

[ohAitch]

Wait no you still need to descend nvm

On Sunday, 21 February 2016, Anton Dyudin antechno777@gmail.com wrote:

Ah, the thing at the bottom of +-del which assumes nonintersection? +-mer perhaps, I can see why del being defined as ?~(a ,~ |=(b/_n.a (mer (bif b)))) would be cleaner.

On Sunday, 21 February 2016, Raymond Pasco <notifications@github.com javascript:_e(%7B%7D,'cvml','notifications@github.com');> wrote:

Join is not union, it's a lower-level operation just like split is. The algorithms are naive. It's not an arm because I couldn't think of a punchy three-letter name. I should be able to given time. :)

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186918361.

[ohAitch]

wants to comment the first loop in del a "=+(axe=(dig b) ?~(axe a a(+{axe} $(a +{axe}.a))))" now

On Sunday, 21 February 2016, Anton Dyudin antechno777@gmail.com wrote:

Wait no you still need to descend nvm

On Sunday, 21 February 2016, Anton Dyudin <antechno777@gmail.com javascript:_e(%7B%7D,'cvml','antechno777@gmail.com');> wrote:

Ah, the thing at the bottom of +-del which assumes nonintersection? +-mer perhaps, I can see why del being defined as ?~(a ,~ |=(b/_n.a (mer (bif b)))) would be cleaner.

On Sunday, 21 February 2016, Raymond Pasco notifications@github.com wrote:

Join is not union, it's a lower-level operation just like split is. The algorithms are naive. It's not an arm because I couldn't think of a punchy three-letter name. I should be able to given time. :)

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-186918361.

[ohAitch]

(if you're cleaning up h/h anyway)

[juped]

pls no this is not an api-opaque refactoring

[ohAitch]

It is if you add it as a new name and then breach that part out, but yeah the "cleaning" involves jets being moved to %zuse in a way I was assuming would require a vere revision anyway.

On Monday, 7 March 2016, Raymond Pasco notifications@github.com wrote:

pls no this is not an api-opaque refactoring

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-193571159.

[juped]

i said api not abi, i know one letter is just the other vertically flipped but there is a big difference!

[ohAitch]

Sure, I don't see how you'd execute the latter in a way that wouldn't allow for the former though.

On Monday, 7 March 2016, Raymond Pasco notifications@github.com wrote:

i said api not abi, i know one letter is just the other vertically flipped but there is a big difference!

— Reply to this email directly or view it on GitHub https://github.com/urbit/arvo/issues/12#issuecomment-193574821.

[juped]

Do you remember all the stuff you were just complaining about re: electroplating &c.?

You cannot do this stuff en passant, or worse, encourage Curtis to.

[cgyarvin]

We should have a new name which is argumentless tap. tap must not change.

Sent from my iPhone

On Mar 7, 2016, at 7:23 PM, Raymond Pasco notifications@github.com wrote:

Do you remember all the stuff you were just complaining about re: electroplating &c.?

You cannot do this stuff en passant, or worse, encourage Curtis to.

— Reply to this email directly or view it on GitHub.

[juped]

Nothing must change "while you're there" refactoring hoon.hoon

[juped]

(well, not quite nothing, removing whitespace from the ends of lines would be cool, for instance :))

[joemfb]

This seems like a nice thing to fold into cc-release. Is your preference still a new name for argument-less +-tap, or could it just be changed?

[juped]

Good question. I'd say the answer is "discuss that on the thread for the actual patch" :)

[cgyarvin]

This doesn't rise to the level of an issue. It's a potential feature of very dubious value.

[ohAitch]

I appreciate the desire to be done with these, but careful API design isn't of "very dubious value", especially when concerning core language containers.

[juped]

Reopening in order to close with pointer

[juped]

Closed, discussion continues on #352