=* tistar should allow for optional type annotation

[Fang-]

=* is a rune strictly used for code readability, and being able to add in a type annotation seems to be in line with that.

Should help with sanity checks for both the writer ("I expect this thing here to be of this type") and the reader ("what type is the data that p.q.r.s.dat refers to again?").

[cgyarvin]

It definitely should. It's one of those odds and ends I kept meaning to get around to. Actually a good little project for those who don't fear the compiler.

…

On Thu, Jan 18, 2018 at 11:44 AM, Fang ***@***.***> wrote: =* is a rune strictly used for code readability, and being able to add in a type annotation seems to be in line with that. Should help with sanity checks for both the writer ("I expect this thing here to be of this type") and the reader ("what type is the data that p.q.r.s.dat refers to again?"). — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#585>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AALyAWFyhnBjVUB9sbHsTb7JCALbglgYks5tL56igaJpZM4Rjde0> .

[mikolajpp]

Just signalling, ~palfun got me on this. We will see what happens.
Anyway, I always kind of liked compilers, especially to-nock ones ;-)

[cgyarvin]

Good luck! Probably not that hard :-)

…

Sent from my iPhone

On Jan 25, 2018, at 6:24 AM, mikolajpp ***@***.***> wrote: Just signalling, ~palfun got me on this. We will see what happens. Anyway, I always kind of liked compilers, especially to-nock ones ;-) — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[joemfb]

@mikolajpp, are you working this one? I'm looking for a target, so I'll take it if you're not.

[cgyarvin]

Lmk if you need help with compiler staging...

…

Sent from my iPhone

On Mar 26, 2018, at 4:57 PM, Joe Bryan ***@***.***> wrote: @mikolajpp, are you working this one? I'm looking for a target, so I'll take it if you're not. — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[mikolajpp]

@joemfb feel free. Working, but not in an immediate sense, as in I am reading through hoon.hoon for the first time...

[joemfb]

So, it appears I do need help with staging...

I've added a %tstc hoon to demonstrate what %tstr should become:
arvo and vere.

I can sync those changes, |reset or +solid, and everything works as expected:

> =`(a our a)
~zod
> =`(a=@ our a)
0
> =`(a=@ our =`(b=@p (mix (lsh 5 1 (end 5 1 eny)) a) [a b]))
[0 ~danweg-bosrym-dozzod-dozzod]

However, when I update the %tstr implementation to match %tstc in hoon.hoon
(and remove %tstc), I can no longer |reset or +solid. Specifically, I get
%find errors compiling zuse and the vanes -- the same errors regardless of
whether the changes are in vere, surprisingly enough (at least to me). I'm sure
we've discussed the staging procedure before (and I thought I had successfully
done it before), but I'm at a bit of a loss.

For the sake of clarity, here were my steps:

• boot a fresh fake-zod from master
• additive changes to vere
• additive changes to hoon.hoon, |reset, success
• mutative changes to hoon.hoon, no |reset, +solid fails
• various failed attempts with and without mutative changes to vere
• feel stupid

Separately, what do you think of bunting the model in +bust (the placeholder
which is to replace +buss:ut)? I'd prefer to do it in +open:ap, but it seems
like that would require an additional hoon to separate pre and post macro
expansion (due to the convention of calling +open:ap in a default case).

[cgyarvin]

Add the new form in one stage, and make anything that generates a hoon generate it. In the next stage, remove the old form.

…

Sent from my iPhone

On Mar 27, 2018, at 3:49 PM, Joe Bryan ***@***.***> wrote: So, it appears I do need help with staging... I've added a %tstc hoon to demonstrate what %tstr should become: arvo and vere. I can sync those changes, |reset or +solid, and everything works as expected: > =`(a our a) ~zod > =`(a=@ our a) 0 > =`(a=@ our ***@***.*** (mix (lsh 5 1 (end 5 1 eny)) a) [a b])) [0 ~danweg-bosrym-dozzod-dozzod] However, when I update the %tstr implementation to match %tstc in hoon.hoon (and remove %tstc), I can no longer |reset or +solid. Specifically, I get %find errors compiling zuse and the vanes -- the same errors regardless of whether the changes are in vere, surprisingly enough (at least to me). I'm sure we've discussed the staging procedure before (and I thought I had successfully done it before), but I'm at a bit of a loss. For the sake of clarity, here were my steps: boot a fresh fake-zod from master additive changes to vere additive changes to hoon.hoon, |reset, success mutative changes to hoon.hoon, no |reset, +solid fails various failed attempts with and without mutative changes to vere feel stupid Separately, what do you think of bunting the model in +bust (the placeholder which is to replace +buss:ut)? I'd prefer to do it in +open:ap, but it seems like that would require an additional hoon to separate pre and post macro expansion (due to the convention of calling +open:ap in a default case). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[cgyarvin]

Sorry, I mean: rather than removing the old form, replace it with the semantics of the new form under the original name. Then remove the temporary standin.

…

Sent from my iPhone

On Mar 27, 2018, at 3:49 PM, Joe Bryan ***@***.***> wrote: So, it appears I do need help with staging... I've added a %tstc hoon to demonstrate what %tstr should become: arvo and vere. I can sync those changes, |reset or +solid, and everything works as expected: > =`(a our a) ~zod > =`(a=@ our a) 0 > =`(a=@ our ***@***.*** (mix (lsh 5 1 (end 5 1 eny)) a) [a b])) [0 ~danweg-bosrym-dozzod-dozzod] However, when I update the %tstr implementation to match %tstc in hoon.hoon (and remove %tstc), I can no longer |reset or +solid. Specifically, I get %find errors compiling zuse and the vanes -- the same errors regardless of whether the changes are in vere, surprisingly enough (at least to me). I'm sure we've discussed the staging procedure before (and I thought I had successfully done it before), but I'm at a bit of a loss. For the sake of clarity, here were my steps: boot a fresh fake-zod from master additive changes to vere additive changes to hoon.hoon, |reset, success mutative changes to hoon.hoon, no |reset, +solid fails various failed attempts with and without mutative changes to vere feel stupid Separately, what do you think of bunting the model in +bust (the placeholder which is to replace +buss:ut)? I'd prefer to do it in +open:ap, but it seems like that would require an additional hoon to separate pre and post macro expansion (due to the convention of calling +open:ap in a default case). — You are receiving this because you commented. Reply to this email directly, view it on GitHub, or mute the thread.

[joemfb]

Thanks! I was clearly rusty...

[joemfb]

This feature was added in the language changes.