iv) One of my "way too fancy to be practical rn" ideas is abbreviation of
printed nouns via replacing sections with .^(... %gx /=dojo=/n), which
could work on arbitrarily large nouns incl cores and such. Not much you can
do if you have to render the whole noun in one go thought, yeah.
v) I think you mean @dr, which would in fact be 2^-16 seconds. @t is text
though, was the core error %bad-utf8?
On Monday, 15 August 2016, Curtis Yarvin <cur...@tlon.io> wrote:
> 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
> <javascript:;>> 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 <javascript:;>.
> > To post to this group, send email to urbit-dev@googlegroups.com
> <javascript:;>.
> > 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 <javascript:;>.
> To post to this group, send email to urbit-dev@googlegroups.com
> <javascript:;>.
> 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.
