removed hard calls on json blobs

[ixv]

Stop harding json blobs in eyre; clam them instead. Mitigates the problem of eyre choking on large json blobs that landscape passes.

[ohAitch]

I thought clams got removed from hoon?

…

On Monday, 4 March 2019, ixv ***@***.***> wrote: Stop harding json blobs in eyre; clam them instead. Mitigates the problem of eyre choking on large json blobs that landscape passes. ------------------------------ You can view, comment on, or merge this pull request online at: #1094 Commit Summary - removed hard calls on json blobs File Changes - *M* sys/vane/eyre.hoon <https://github.com/urbit/arvo/pull/1094/files#diff-0> (4) Patch Links: - https://github.com/urbit/arvo/pull/1094.patch - https://github.com/urbit/arvo/pull/1094.diff — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#1094>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxXhnUjEmGjDAH-7KZ6GQzduJaCtk32ks5vTaD9gaJpZM4bdW6w> .

[philipcmonk]

We use "clam" to refer to irregular ,, which apparently expands to $; now. It's not a clam in the old sense of "don't crash", but it uses the same syntax and you use it in most of the same instances. It should be semantically equivalent to hard but faster. In practice, bugs.

[ohAitch]

Huh, what is hard(or just calling json as a gate) doing that $; isn't?

…

On Monday, 4 March 2019, ixv ***@***.***> wrote: Merged #1094 <#1094> into next. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxXht3rJrUk-Au0hmJbjkEeyoUxC2Wzks5vTbPTgaJpZM4bdW6w> .

[philipcmonk]

Equality check at the end. This can be very expensive.

"calling json as a gate" is equivalent to $;. It's just that "calling a mold as a gate" is a really bad syntactic antipattern, and I think it should be disallowed. It makes you have to think about why ((list [@ @]) ~) doesn't work. We can't at parse time distinguish a mold from a value, so we need to apply Philip's Comma Rule[0]. Much better to simply prefix all clams with , which has the added benefit of being more explicit about what you're doing.

[0] If (1) it's not a function (unlike pair), (2) you can't tell by context that it's a type (unlike the first argument to |= ), and (3) it's ambiguous as context-free as to whether it's a type (unlike * or @ or ^), then you need to prefix it with a comma.

[ohAitch]

Interested in the documentation strategy for that proposal: "a hoon type(mold) is just a gate. You are not however allowed to call this gate" It sounds like the equality check should just be removed from hard? Unless 2019 clams are *inconsistent* about whether they'll crash on mistyped values

…

On Monday, 4 March 2019, Philip Monk ***@***.***> wrote: Equality check at the end. This can be very expensive. "calling json as a gate" is equivalent to $;. It's just that "calling a mold as a gate" is a really bad syntactic antipattern, and I think it should be disallowed. It makes you have to think about why ((list [@ @]) ~) doesn't work. We can't at parse time distinguish a mold from a value, so we need to apply Philip's Comma Rule[0]. Much better to simply prefix all clams with , which has the added benefit of being more explicit about what you're doing. [0] If (1) it's not a function (unlike pair), (2) you can't tell by context that it's a type (unlike the first argument to |= ), and (3) it's ambiguous as context-free as to whether it's a type (unlike * or @ or ^), then you need to prefix it with a comma. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxXhpNo-W8kY_IGP71PZ7DAYvtfzA_aks5vTbpGgaJpZM4bdW6w> .

[philipcmonk]

"You are not however allowed to call this gate"

I mean, calling it a gate has always been a lie, it's just a question of degree. You can't just do (,|=(* +<) 5) for example. OTOH you can do:

=+  m=|=(* ?^(+< +< +(+<)))  (,m 5)

It may be implemented as a gate somewhere deep down, but you shouldn't pretend it's just a gate to the user.

Unless 2019 clams are inconsistent about whether they'll crash on mistyped values

Bingo: ((list) [1 2 3 ~])

[ohAitch]

Sorry, I don't have a repl at hand; are you saying that shouldn't crash, but does? Crashes but doesn't crash if you put a , on the (list)? Generally behaves any differently from (list *)?

…

On Monday, 4 March 2019, Philip Monk ***@***.***> wrote: "You are not however allowed to call this gate" I mean, calling it a gate has always been a lie, it's just a question of degree. You can't just do (,|=(* +<) 5) for example. OTOH you can do: =+ m=|=(* ?^(+< +< +(+<))) (,m 5) It may be implemented as a gate somewhere deep down, but you shouldn't pretend it's just a gate to the user. Unless 2019 clams are *inconsistent* about whether they'll crash on mistyped values Bingo: ((list) [1 2 3 ~]) — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxXhksogt5neh03UFGWQFzRW4dd7UWNks5vTcA6gaJpZM4bdW6w> .

[philipcmonk]

> ((list) [1 2 3 ~])
~[0 0 0]
> (,(list) [1 2 3 ~])
~[0 0 0]
> ((list *) [1 2 3 ~])
~[1 2 3]
> ((list *mold) [1 2 3 ~])
~[1 2 3]
> (,(list ,*mold) [1 2 3 ~])
~[1 2 3]
> (,(list *mold) [1 2 3 ~])
[1 2 3 0]

[ohAitch]

Thanks! That definitely looks like a bug yeah; is it filed? It does not however seem related to ++hard, though using hard certainly downgrades it to a less severe "it is *detected* that the new mold system is corrupting data"; I'm guessing +* is putting in a hardcoded compile time equivalent of *gate instead of *mold? (And the last one is just weird, though I definitely wouldn't describe it as "using , is a good idea")

…

On Monday, 4 March 2019, Philip Monk ***@***.***> wrote: > ((list) [1 2 3 ~]) ~[0 0 0] > (,(list) [1 2 3 ~]) ~[0 0 0] > ((list *) [1 2 3 ~]) ~[1 2 3] > ((list *mold) [1 2 3 ~]) ~[1 2 3] > (,(list ,*mold) [1 2 3 ~]) ~[1 2 3] > (,(list *mold) [1 2 3 ~]) [1 2 3 0] — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxXhkXVTP0ODheu5uOFpuT_B_xUs8Eoks5vTcQ4gaJpZM4bdW6w> .

[philipcmonk]

This is definitely a bug. As for whether all ++hard calls should turn into clams, the question is "do you trust that clams don't corrupt data, given that nobody's ever checked it very well and we know it does in at least one case"?

[ohAitch]

I mean, either it gets checked very well, or should be reverted to the old system known *not* to be broken and with identical semantics in the ++hard case

…

On Monday, 4 March 2019, Philip Monk ***@***.***> wrote: This is definitely a bug. As for whether all ++hard calls should turn into clams, the question is "do you trust that clams don't corrupt data, given that nobody's ever checked it very well and we know it does in at least one case"? — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#1094 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABxXhm7U6aCDlp2mseIULiVV8VYSpgJkks5vTcpvgaJpZM4bdW6w> .