Add @q, phonetic data representation

[Fang-]

It's @p, except never scrambles, doesn't care about even number of bytes, and doesn't use -- in large values.
This is needed for tickets, and useful for anything else that may want to use the @p look-and-feel to display data.

Syntax for literals is .~. A .~ by itself is invalid, you need at least one syllable. They follow byte ordering as in the @ux case, so:

@ux       @q
0x1       .~nec
0x201     .~binnec
0x3.0201  .~wes-binnec

Note that leading zeroes are valid, but won't change the value. .~dozzod-dozzod is equivalent to .~zod.

I have included some tests! Pretty sure this is how you test auras: just using them.

[ohAitch]

What is the use case for diverging on scrambling, saving on a syllable of zero padding for odd numbers of bytes(>1), non-roundtripping "valid" inputs, or removing the long value visual chunking? Can't tickets have the @p look and feel, by being literally @p?

[Fang-]

They could, but it wouldn't be right. @p is strictly about ship names, and as far as I'm concerned all existing usage of it that isn't literally about representing/storing ship names is incorrect. From a data representation point of view, having ~palfun-foslup and ~palfun-fosnup differ in more than just a single byte is super weird.

I'm not yet 100% set on the removal of visual chunking for longer values by the way, waiting to hear @cgyarvin's thoughts.

[ohAitch]

I don't think that matches up with historical usage? Ship names are @p yes, but so are like all currently issued tickets, various hashes that get printed throughout the system, eyre one-time codes, etc.
@p was very much designed to be a generic phonetic representation, with address space merely as the driving central use case

[Fang-]

Most of the things you listed are going away in the near term anyway. (^:
History was maybe wrong here. @cgyarvin and I agree that @q is more correct for such uses moving forward.

[vvisigoth]

"history was wrong" -- fang — ~poldec-tonteg http://urbit.org

…

On Thu, Oct 4, 2018 at 3:35 PM Fang ***@***.***> wrote: Most of the things you listed are going away in the near term anyway. (^: History was maybe wrong here. @cgyarvin <https://github.com/cgyarvin> and I agree that @q is more correct for such uses moving forward. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub <#824 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ABiQ43GFUDPA3-HoKGso3vSACd9iRrUzks5uho0YgaJpZM4W9040> .

[Fang-]

@cgyarvin ping!

[mikolajpp]

Also pinging. The new parser wants to know whether or not we are supporting this ;-)

[cgyarvin]

Yes, we must support!

…

Sent from my iPhone

On Nov 11, 2018, at 4:51 AM, mikolajpp ***@***.***> wrote: Also pinging. The new parser wants to know whether or not we are supporting this ;-) — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub, or mute the thread.

[Fang-]

fyi, @cgyarvin, I will just like merge this sometime during the coming week and assume this is as clean and correct as it gets.

[cgyarvin]

Yes, yes, yes! This all looks fine.