Not at all, Zach, great questions. I have only one question in
response (Customer Feedback Survey #42): which docs did you read in
which order, and which helped the most?
i) The pretty-printing of floats (and everything) is not in :dojo, but
in hoon.hoon (++co) (specifically in r-co). Note that I didn't write
the floating-point code -- it's a contributor's work (Max Greer).
ii) In older versions of Hoon there was no constraint on equality
testing, because you can test any two nouns for equality. This was
only one of many things in Hoon that horrified people with a
traditional typed FP background. In this case I decided that the
traditionalists were right, because I have seen this check turn up
bugs. On the other hand, most other people who know Hoon are a little
horrified by most of my recent changes, so it could be that I'm just
losing my mojo. In any case, equality testing requires one side of
the test to be a subtype of the other (nest within it).
iii) A core contains compiled Hoon code in Nock form. An invertible
printer would have to decompile it, or something -- basically
impossible. You've lost informatoion.
iv) Ha! This is a bug (if a small one). Do you want to file it?
You'll get valuable Bug Points which may in future be exchangeable for
exciting action figures.
v) This is because (a) we can't statically verify auras (for obvious
reasons, since Hoon is not Coq), and (b) we don't in practice check
them adequately before feeding them to the console, resulting in wacky
formatting for invalid strings (another small bug).
vi) One, Hoon can't actually validate that a mold is idempotent
(because not Coq). Two, ;; doesn't normalize; if (mold a) doesn't
equal a, it crashes. There are cases where normalization is good
practice, but they tend to be the exception, even though defining
molds as normalizers is a good design. For instance, in networking,
Urbit has definitely moved away from Postel's law, which seems to be a
lot less relevant when you have, like, types and stuff.
vii) There isn't but that's a great idea (thanks ghci). There is
history with a kill buffer, though, so ^P^A^K^N^Y will do the same
thing. I'd have to think about how to fit this into the dojo, though,
it's non-obvious.
viii) The "type" output in the prettyprinter is its own thing -- it is
not either a mold or a span, just a thing derived from inspecting the
span. See under "not invertible." In this case, we see that your
structure is a repeating structure of the form {i/item t/tail}, which
happens to be what ++list makes, so we're basically saying it's a
list. If you make this same span with any other mold, though, you'll
get the same results -- all typing in Hoon is structural.
On Mon, Aug 15, 2016 at 6:13 AM, Zach Gotsch <orbipe...@gmail.com> wrote:
> Hey I was looking at some of the Hoon resources this weekend and I had a few
> questions and things I didn't understand. I hope this is an appropriate
> place for my questions.
>
> i)
> There seems to be some sort of output formatting for floats, since
>
>> (add:rs .0.1 .0.2)
> .3e-1
>
> but
>
>> (add:rd .~0.1 .~0.2)
> .~3.0000000000000004e-1
>
> Where can I see how the pretty-printing in dojo is happening (if that's even
> what this is...)?
>
> ii)
> I don't think I understand how constant nouns (rocks?) are represented.
> %a has aura (mold? not sure of the difference here either) $a, but the raw
> value 97
> %97 also has raw value 97, but aura $97
>
> I would expect =(%a %97) to be .y, since I don't expect the types to have
> any bearing on equality testing. Instead it is an error. I guess my main
> question here is "When do types (er, auras?) matter?" Something like (add
> %97 1) doesn't cause an error, and produces 98, which I expect if add
> doesn't care about types. Side note, casting the rocks seems to prevent the
> error and I get the behavior I expect:
>
>> =(`@ud`%a `@ud`%97)
>
> %.y
>
>
> iii)
> From the docs: "When we print b, or any core, we see that typed noun
> printing can't be an invertible function in Hoon". I don't understand why
> it's not invertable. Is it because the battery is Nock, and you can't enter
> nock code in Hoon?
>
> iv)
> @n seems to be a thing but I can't use it at the prompt without causing an
> error. Is this like undefined/bottom in haskell?
>
> v)
> I was messing around with auras and I was wondering if `@tr`1 was something
> like ~s1 (or milliseconds or microseconds). When I typed it into dojo, it
> printed all sorts of stuff and overwrote the prompt. What is the stuff that
> it prints and why does this happen? (After typing this out, I realized that
> it's a runtime error of some kind. Where can I learn how to interpret the
> printed stuff?)
>
> vi)
> In the documentation, it says ;; applies a mold, asserting fixed point. All
> molds should have fixed points for all inputs because they are idempotent,
> right? So is this just a function application of the mold and an assertion
> that it is, in fact idempotent?
>
> vii)
> Is there a way to refer to the last twig in the dojo prompt (like `it` in
> ghci)?
>
> viii)
> When I do:
>
>> ? (gulf `@u`0 `@u`5)
> it(@)
> ~[0 1 2 3 4 5]
>
> I don't understand the type of gulf's output, it isn't a cell, and I haven't
> seen `it(@)`. Does `it` mean "iterated". Is `@` a type parameter here?
>
>
> I hope this wasn't too much for the mailing list but since the network is
> down I haven't been able to bother people on :talk
>
> Zach
>
>
>
> --
> 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
> email to urbit-dev+unsubscr...@googlegroups.com.
> To post to this group, send email to urbit-dev@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.
--
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 email
to urbit-dev+unsubscr...@googlegroups.com.
To post to this group, send email to urbit-dev@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
