This repository has been archived by the owner on Aug 14, 2019. It is now read-only.
-
Notifications
You must be signed in to change notification settings - Fork 58
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
"aapp" |
joemfb
approved these changes
May 31, 2019
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM
"asap" -- ASynchronous APp |
The problem is that all apps are asynchronous. Some just make blocking asynchronous requests. |
I support this. |
Obviously Phil should choose the names since he did the work. That said, I
think "async" is a good name.
But that also said, "app" is one of the Earth words I most regret smuggling
into Urbit. There are many good ideas in the conceptual dumpster marked
"app," but it is also a very good way to import unexamined assumptions and
other terrestrial biohazards.
One of the many definitional issues with the word "app" is that "app"
conflates the code of an application with its data. In a programming
environment which is genuinely imperative there is some cause for this.
But the state of an asynchronous transaction, though it contains cores, is
still a noun.
I also hate all allusive, poetic, and short terminology. Galen converted
me completely to normcore. I would call the state of an asynchronous
transaction a *conversation*. I would call the code which manages the
transaction a "driver". Phil has suggested *verse* for *conversation* -- I
also hate abbreviations, but I am ok with *convo* because it is normal SMS
slang. Replace "driver" and "conversation" below with whatever names are
chosen.
In my mind the basic function of a driver is to control a non-Urbit, or
non-Urbity, service from Urbit. A driver is a client for any foreign, or
otherwise weird or gnarly, service. The top-end case could be Let's
Encrypt -- because nothing could be gnarlier than ACME.
A normal Urbit service -- an "agent" (or "%gall app") should be
declarative, not imperative. Communication between agents is peer-to-peer
CQRS. One message is one command is one transaction. This is the way
Urbit should work, but it's not the way the world works -- which is why
Urbit needs tapps/drivers.
Declarative agents are generally more manageable and just plain better than
imperative drivers. But solving an imperative problem declaratively is an
exercise in masochism. It is theoretically possible to build either form
within the other, but agents' clean, coreless state is more fundamental.
However, there may be execution layers which execute the imperative form
directly -- for example, the dojo could really do fun things with drivers.
Another unexamined assumption that can flow from the use of the word "app"
is the expectation that an agent, if it has to talk with Earth and thus has
to resort to a driver, has to contain only one driver, or only one
conversation per driver.
Unfortunately, present-day %gall apps are absolutely terrible at being
declarative agents. Things the programmer doesn't declare: outgoing
subscriptions; inbound subscription routes; card protocols; hierarchical
sub-agent structure; other external resource requests... not being
declared, this is not visible to the execution engine (%gall), and the
programmer has to work it all by hand.
Until complex agents -- of the complexity of %talk -- can be written
without any of this manual nonsense, the simplicity of an imperative client
may draw too much functionality out of agents and into drivers. If this
threat is productive, it will inspire some improvement in agents.
Another important case for drivers is providing a gateway to weird, gnarly,
foreign services, so that Urbit can command and subscribe to them as if
they were nice Urbity native services. Many of these drivers already
exist, implemented as declarative state machines -- which is just wrong.
Here again the engine perhaps can and should understand drivers and
conversations directly, not wrapped in a declarative agent at all.
…On Sat, Jun 1, 2019 at 3:41 AM Jared Tobin ***@***.***> wrote:
Merged #1185 <#1185> into master.
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#1185?email_source=notifications&email_token=AABPEAI5VN7OOPOOA4KX2WLPYJG5XA5CNFSM4HR6GX62YY3PNVWWK3TUL52HS4DFWZEXG43VMVCXMZLOORHG65DJMZUWGYLUNFXW5KTDN5WW2ZLOORPWSZGORYCEFTI#event-2382643917>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AABPEAKWLWCUO4GEMCORA7LPYJG5XANCNFSM4HR6GX6Q>
.
|
Sign up for free
to subscribe to this conversation on GitHub.
Already have an account?
Sign in.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I really feel like "async" is exactly the right name for the "trad" monad. It's an "asynchronous computation" or an "asynchronous transaction".
I'm not super happy with "tapp" for "transacting app", but I haven't come up with anything better. "Blocking app" is more descriptive but long. "Block" is cute and suggests LEGO blocks that can be combined easily and safely, but it's a very generic word.