On 7/16/22 03:09, secretsnail9 via agora-discussion wrote:
> On Sat, Jul 16, 2022 at 12:50 AM ais523 via agora-discussion <
> agora-discussion@agoranomic.org> wrote:
>
>>> It discusses shorthand which I almost used exactly and discusses what the
>>> shorthand could mean,
>> No it doesn't. It discusses a couple of possible wordings, but the
>> shorthand wording it discusses is specifically "Proposal:",
>
> It discusses one shorthand specifically:
>
> Proposals (including this one), are usually styled as follows
> "Title:
> Coauthors
> AI
> Text"
>
> and that's pretty much exactly the shorthand I used. Not "Proposal:" which
> I have no idea where you even found. It is this shorthand the judge
> discusses.
It found that the words prefixing the shorthand matter and take
precedence over what the shorthand would mean standing alone.
>> The judge of CFJ 3744 specifically found that "I
>> create this proposal" has a different meaning from "I create a proposal
>> with the following attributes and text" (in the case of CFJ 3744, the
>> latter wording was used, and the creation failed because it was
>> impossible for a proposal to have the stated attributes).
>>
> Not exactly that it has a "different meaning" but a more precise meaning:
> while "I create this proposal" could be either of the two mentioned
> possibilities, "I create a proposal with the following attributes and text"
> is definitively one of those possibilities. But this is a special case
> because of the incorrect attribute: if it had been correct, both phrases
> would have the same effect, as the two possibilities would be essentially
> the same.
If they have different meanings in certain edge cases, then they have
different meanings.
>
>>> "I create this proposal" and "I submit the following proposal"
>>> would be basically the same if create and submit are synonyms, and the
>>> judge interterpetted "I create this proposal: {Shorthand}" as having two
>>> possible meanings, both of which would mean my creations of proposals
>>> succeeded, as they were essentially the same as Jason's.
>> Neither of those wordings could succeed in creating multiple proposals,
>> because they both use language that can only be used to apply to a
>> single proposal.
>
> "I create this proposal: {shortand}" actually means "I create a proposal
> with the following Title, Coauthors, AI, and Text properties" or the other
> similar meaning, which can be used to apply to multiple identical proposals.
Expanding shorthand generally can't remove ambiguity where it exists.
>
>> Are you seriously trying to argue that "Twice, I create this proposal:
>> {proposal}" is capable of creating two different proposals?
>
> Yes. That's how I read it naturally, and it isn't contradicted by the
> rules. The CFJ implies "I create this proposal" can mean it's talking about
> the attributes in {proposal}, not an actual proposal entity. So of course,
> this would make two proposals, one created slightly after the other, that
> are identical. The same proposal created twice, once and then again
> slightly after, so there are two of them.
If there are two proposals, they are by definition not "the same
proposal". They might have certain equal attributes, but they aren't the
same.
If the rule admitting the reading of permitting "creating"an existing
proposal, then it would also have to necessarily not permit creating a
new proposal. That clearly fails on an R217 test. Additionally, if the
text were designed to allow "creating" an existing proposal, it would
say "specified proposal", rather than requiring specification of
attributes. An author that wanted to allow only creating new proposals
would write _exactly_ this text.
>
>> (whether two proposals are the same
>> entity is important because, e.g., putting a proposal into the proposal
>> pool, then putting the same proposal into the proposal pool, won't lead
>> to it being in there twice, just like transferring the same nonfungible
>> asset to someone twice won't lead to them having two copies of it).
>>
> The latter example, you could totally do that if you created the
> nonfungible asset again first, which is basically what happens when you
> create a new proposal to be added to the pool. Then they'd have two copies
> of the same entity. (Side note, we really ought to have some kind of vague
> definition for an entity, even if it doesn't cover everything, just so we
> can have some agreement. There's probably plenty of precedent about the
> nature of entities that could be used. This case could be an example.)
You can't "create" an already existing coin. You can create a new coin,
and, if it's owned by the same person as an existing coin, not have to
keep track of which is which (this is where fungibility matters), but
there are still two coin entities.
A vague definition is worse than no definition. If it's vague enough
that the goals is for it to come down to "what a judge thinks" anyway,
then all it can do is
--
Jason
