Curtis Yarvin
2016-01-05 01:27:07 UTC
Hi urbiters, welcome to {current-year}!
You might have noticed that I disappeared slightly in December. Not
to put too fine a point on it, this was because I was doing language
design, a process highly inimical to all kinds of human contact.
Especially contact with fellow hackers, which tends to result in a
process known as "bikeshedding."
That said, people playing with this young Urbit are here because they
have something to contribute. Language design ideas are especially
welcome! It's just easier to argue about changing something that
exists and runs, not something hypothetical to be implemented later.
(Also, I have one question about a change I haven't made yet, but
generally favor: currently, ~[1 3 5 7] means [1 3 5 7 ~], and [1 3 5
7]~ means [[1 3 5 7] ~]. This is highly confusing and I want to
reverse it. The codebase can be patched up with a lexical (but
non-regex) change. Any votes?)
The new Hoon is on cgyarvin/urbit-1/newdeal. It works perfectly as
far as I can tell -- in fact, I don't recall introducing any runtime
bugs, and I patched *a lot* of code by hand. Type systems work!
There's some master code to merge in and the tree has been slimmed
down a little for dev speed, although I also ported everything that's
deleted on this branch. I want to do a couple more minor tweaks,
possibly including the above, and the compiler is missing some jets
and thus slow; but ideally we'll merge and breach this week.
As far as I know, and really believe, Hoon 151 has are no language
bugs, jet mismatches, or major misfeatures / missing features. It
would be nice to put battery inheritance (%oak/%yew feet) back in, but
that's really a 2.0 feature. ++ut, the main compiler body, has been
simplified and had the printer pulled out -- it's now about exactly
1000 lines of code, which is not too bad for higher-order type
inference plus code generation.
The cause of this unscheduled diversion (it's not easy being both a
company and a research project!) was that I found myself writing
sentences like "this is the most confusing thing about Hoon"). The
language had been stable with these rough areas for about a year and a
half, and I realized that I could actually fix them and it would be
irresponsible not to do so. I'm a much better Hoon programmer than I
was in 2014, and the rough areas were generally stabs in the dark at
problems I didn't really understand.
Since I was in research mode, I don't have a comprehensive list of all
the bugs that got fixed or even the language changes that happened.
I'm just going to rigorously document the resulting language, which I
believe now actually deserves to be frozen (and taught and learned).
If you have existing Hoon 164 code, it's unlikely to compile without
changes -- *but* there are no gotchas. Naively using old code won't
produce incorrect semantics. (Not even if you were abusing one of the
holes in the type system, all of which are now closed to my knowledge
:-)
Let me just go over the two main changes: explicit molds, and devulcanization.
Probably the main design mistake in Hoon 164+ was the modal syntax.
Some nodes in the AST were ++twig; some were ++tile. But a tile could
be used as a twig and a twig as a tile, so we had mode-switching
runes. I can't think of it without a small shudder.
The intention here was good: to use the same syntax for a *direct*
value, like [a=%foo b=%bar], and an *indirect* value, like (in the old
syntax) ,[a=%foo b=%bar] or (new syntax) {a/$foo b/$bar}. The latter,
of course, is a "mold" (a completely informal term, there is no
++mold) - a normalizing function, accepting any noun and always
producing a value matching [a=%foo b=%bar]. Basically, a mold is just
any gate whose sample is `*` and whose function is idempotent.
Sweeping this distinction under the rug was a very un-Hoon-like design
decision which I now regret quite a bit. Large quantities of menial
labor in rewriting the whole codebase was the only conceivable
punishment for this error.
Syntactically, to convert a direct noun into an indirect mold, []
becomes {}; % becomes $; = becomes /. (Thanks to Raymond for
suggesting / as an improvement on +.) _ works as it did before; there
is no conversion syntax, so now it's just (list *) and (list {@ @})
instead of (list ,*) and (list ,[@ @]).
(The implementation of these macros is basically unchanged -- we even
keep the ++tile structure internally, which is important, because a
naive implementation of {} would be very inefficient.)
"De-vulcanization" of wet gates is the second major change I made.
There's a serious problem inherent in wet gates: if I write a ++swap
gate |*({a/* b/*} [b a]), and call (swap %foo %bar), I find myself
compiling =+([%foo %bar] [b a]), when I really want =+([a=%foo b=%bar]
[b a]). But I blasted the whole sample of the gate with my [%foo
%bar]. In a dry gate all that matters is that this is compatible with
the default sample, but a wet gate is really a macro, and we need
those labels.
In ancient versions of Hoon I had some horrible way of matching the
sample to the target which didn't work, so I tore it out and replaced
it with "vulcanization," a hack which compiles |*({a/* b/*} [b a]) as
|*({* *} =>([a=+12 b=+13] [b a]). This works, but it's horrible and
causes weird problems.
Instead, I changed symbols in ++limb from term to (unit term). A null
limb [%| @ ~] has the syntax (you would almost never use this
explicitly) , - as in ,.foo.bar. You can think of a wing as digging a
hole into the subject, and where +2 cracks open a noun, , just rubs on
it gently -- removing any cosmetic face, but otherwise doing no
damage.
Then, (swap %foo %bar) doesn't expand to $:swap(+6 [%foo %bar]), but
rather $:swap(,.+12 %foo, ,.+13 %bar). This makes no difference at
all for a dry gate. For a wet gate, however, it makes the call
actually work with no vulcanization -- as long as your sample
structure actually matches the gate's structure. This is slightly
un-Hoonish, but then again Hoon is the only language where you can say
=+(a=[3 2] (add a)), so it's not giving up that much.
Some things broke, of course. Rewriting a language written itself is
a lot easier than writing a language written in itself, but it's not
trivial! And yes, we will introduce Hoon 151 in a breach; in theory
we don't have to, but I want to test this mechanism with a trivial
change, not a nontrivial one.
Anyway, what else is up? Our current goal is to release an Urbit
product this spring that's actually, genuinely, useful -- even for
people who don't give a fsck about the technology. Better yet, we
actually know what this product is and believe we can build it. We'll
say more about this later...
And once again: happy 2016!
You might have noticed that I disappeared slightly in December. Not
to put too fine a point on it, this was because I was doing language
design, a process highly inimical to all kinds of human contact.
Especially contact with fellow hackers, which tends to result in a
process known as "bikeshedding."
That said, people playing with this young Urbit are here because they
have something to contribute. Language design ideas are especially
welcome! It's just easier to argue about changing something that
exists and runs, not something hypothetical to be implemented later.
(Also, I have one question about a change I haven't made yet, but
generally favor: currently, ~[1 3 5 7] means [1 3 5 7 ~], and [1 3 5
7]~ means [[1 3 5 7] ~]. This is highly confusing and I want to
reverse it. The codebase can be patched up with a lexical (but
non-regex) change. Any votes?)
The new Hoon is on cgyarvin/urbit-1/newdeal. It works perfectly as
far as I can tell -- in fact, I don't recall introducing any runtime
bugs, and I patched *a lot* of code by hand. Type systems work!
There's some master code to merge in and the tree has been slimmed
down a little for dev speed, although I also ported everything that's
deleted on this branch. I want to do a couple more minor tweaks,
possibly including the above, and the compiler is missing some jets
and thus slow; but ideally we'll merge and breach this week.
As far as I know, and really believe, Hoon 151 has are no language
bugs, jet mismatches, or major misfeatures / missing features. It
would be nice to put battery inheritance (%oak/%yew feet) back in, but
that's really a 2.0 feature. ++ut, the main compiler body, has been
simplified and had the printer pulled out -- it's now about exactly
1000 lines of code, which is not too bad for higher-order type
inference plus code generation.
The cause of this unscheduled diversion (it's not easy being both a
company and a research project!) was that I found myself writing
sentences like "this is the most confusing thing about Hoon"). The
language had been stable with these rough areas for about a year and a
half, and I realized that I could actually fix them and it would be
irresponsible not to do so. I'm a much better Hoon programmer than I
was in 2014, and the rough areas were generally stabs in the dark at
problems I didn't really understand.
Since I was in research mode, I don't have a comprehensive list of all
the bugs that got fixed or even the language changes that happened.
I'm just going to rigorously document the resulting language, which I
believe now actually deserves to be frozen (and taught and learned).
If you have existing Hoon 164 code, it's unlikely to compile without
changes -- *but* there are no gotchas. Naively using old code won't
produce incorrect semantics. (Not even if you were abusing one of the
holes in the type system, all of which are now closed to my knowledge
:-)
Let me just go over the two main changes: explicit molds, and devulcanization.
Probably the main design mistake in Hoon 164+ was the modal syntax.
Some nodes in the AST were ++twig; some were ++tile. But a tile could
be used as a twig and a twig as a tile, so we had mode-switching
runes. I can't think of it without a small shudder.
The intention here was good: to use the same syntax for a *direct*
value, like [a=%foo b=%bar], and an *indirect* value, like (in the old
syntax) ,[a=%foo b=%bar] or (new syntax) {a/$foo b/$bar}. The latter,
of course, is a "mold" (a completely informal term, there is no
++mold) - a normalizing function, accepting any noun and always
producing a value matching [a=%foo b=%bar]. Basically, a mold is just
any gate whose sample is `*` and whose function is idempotent.
Sweeping this distinction under the rug was a very un-Hoon-like design
decision which I now regret quite a bit. Large quantities of menial
labor in rewriting the whole codebase was the only conceivable
punishment for this error.
Syntactically, to convert a direct noun into an indirect mold, []
becomes {}; % becomes $; = becomes /. (Thanks to Raymond for
suggesting / as an improvement on +.) _ works as it did before; there
is no conversion syntax, so now it's just (list *) and (list {@ @})
instead of (list ,*) and (list ,[@ @]).
(The implementation of these macros is basically unchanged -- we even
keep the ++tile structure internally, which is important, because a
naive implementation of {} would be very inefficient.)
"De-vulcanization" of wet gates is the second major change I made.
There's a serious problem inherent in wet gates: if I write a ++swap
gate |*({a/* b/*} [b a]), and call (swap %foo %bar), I find myself
compiling =+([%foo %bar] [b a]), when I really want =+([a=%foo b=%bar]
[b a]). But I blasted the whole sample of the gate with my [%foo
%bar]. In a dry gate all that matters is that this is compatible with
the default sample, but a wet gate is really a macro, and we need
those labels.
In ancient versions of Hoon I had some horrible way of matching the
sample to the target which didn't work, so I tore it out and replaced
it with "vulcanization," a hack which compiles |*({a/* b/*} [b a]) as
|*({* *} =>([a=+12 b=+13] [b a]). This works, but it's horrible and
causes weird problems.
Instead, I changed symbols in ++limb from term to (unit term). A null
limb [%| @ ~] has the syntax (you would almost never use this
explicitly) , - as in ,.foo.bar. You can think of a wing as digging a
hole into the subject, and where +2 cracks open a noun, , just rubs on
it gently -- removing any cosmetic face, but otherwise doing no
damage.
Then, (swap %foo %bar) doesn't expand to $:swap(+6 [%foo %bar]), but
rather $:swap(,.+12 %foo, ,.+13 %bar). This makes no difference at
all for a dry gate. For a wet gate, however, it makes the call
actually work with no vulcanization -- as long as your sample
structure actually matches the gate's structure. This is slightly
un-Hoonish, but then again Hoon is the only language where you can say
=+(a=[3 2] (add a)), so it's not giving up that much.
Some things broke, of course. Rewriting a language written itself is
a lot easier than writing a language written in itself, but it's not
trivial! And yes, we will introduce Hoon 151 in a breach; in theory
we don't have to, but I want to test this mechanism with a trivial
change, not a nontrivial one.
Anyway, what else is up? Our current goal is to release an Urbit
product this spring that's actually, genuinely, useful -- even for
people who don't give a fsck about the technology. Better yet, we
actually know what this product is and believe we can build it. We'll
say more about this later...
And once again: happy 2016!
--
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+***@googlegroups.com.
To post to this group, send email to urbit-***@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+***@googlegroups.com.
To post to this group, send email to urbit-***@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.