3.0 Feature List

[AnEmortalKid]

Placeholder to link all the other currently open issues planned for 3.0 that existed pre-revive.

The 3.0 parser should be written in dogescript (#96)

• const => 5evar
• , => also (Check for operators in whitespace sensitive parameters #88)
• Native DSON support (spec may need to change, need to investigate potential ambiguities) DSON + Dogescript #68
• Investigate feasibility of swapping with keyword around more natural dogespeak possible? #15
• precedence fixes (functions as variable for other functions #71)
• Comparison operator sanitization, from is conflict #45 and wow. such ideas #35. We have a === and !== but no == or !=. Since this would be 3.0, here's where we can possibly make the breaking changes to keywords. Though not many people probably will use 2.4.x
• repl rewrite R.E.P.L rewrite #189

[vpzomtrrfrt]

I've starting working on a possible new parser: https://git.vpzom.click/vpzom/doge3

[AnEmortalKid]

Neat! I see you have to assign a lot of function calls to variables before using them. I’m hoping the work in 2.4 will let us get around that!

Are there any missing features not in 2.4 that you noticed?

[vpzomtrrfrt]

The biggest issue I had was that function calls don't work in rly statements. I also had to use JS for concatenation, since we don't seem to have any doge operators for that.

[AnEmortalKid]

Yeah, I’m still trying to work out in my head how to recurse parse plz and stuff on those rly/notrly sections with the ‘is’ ambiguity and also with plz and dose consuming all tokens to the right. Might have to fix the hungry hungry parsing for those functions to support stuff like:

rly plz foo with bar and plz baz with wbz

EDIT

We might get around it by either adding thx to denote the end of a plz OR we could search for any of the current tokens (with lookahead), like and , or, bigger and stop consuming arguments to plz/dose which would let us have:

rly plz foo with bar
rly bar bigger plz foo with baz

[AnEmortalKid]

@pholey might be interested in the parser as well.

[vpzomtrrfrt]

Regarding function call termination:
I don't think searching for tokens like that is a good idea, since it would add additional ambiguity and make it difficult to nest calls with conditions. I think the existing answer is the & token, but thx sounds good as a complement to plz

[AnEmortalKid]

What would you suggest as a complement for dose? I think thx might also work here. I forgot about the option to use & on the last argument.

I guess

rly plz foo with bar& bigger plz baz with qwz

Could also be:

rly plz foo with bar thx bigger plz baz with qwz

thx seems a bit more obvious, perhaps we can keep it to facilitate chained calls more than relying on checking if the last char is &.

[vpzomtrrfrt]

thx is probably fine for dose as well. For now, I've implemented both in doge3.

[vpzomtrrfrt]

There are a few ambiguities that I'd like to solve in 3.0.

1. wow returns

plz doThing with 'doge' much result
    console dose loge with result
wow 'another value'

Could be interpreted as either:

doThing('doge', function(result) {
    console.log(result);
}, 'another value');

or:

doThing('doge', function(result) {
    console.log(result);
    return 'another value';
});

In 2.x, we also require wow& before the return value, which adds another possible interpretation if used that way.

This also adds additional complexity to the parser, as nothing I've done so far has involved optional expressions.

To solve this, we could:

• Disallow wow-returns for anonymous functions, and determine intent based on the presence of a newline after the closing wow
• Add a required token between wow and the return value, maybe with?
• Define precedence so at least there is an answer, even if unclear to the reader
• Remove the feature altogether, and use regular return statements (I don't think these exist yet, but I think they should for early returns anyway)
• Anything else?

2. bigify/smallify

These operators are allowed to appear either before or after their operand. However, due to our lack of separation between values, this introduces an ambiguity, since plz foo with bar bigify baz could be parsed as either foo(bar++, baz) or foo(bar, ++baz).

Perhaps we should drop the postfix option. That would clear up this issue, and I feel that the prefix option is more doge-like. The functional difference between them only matters when using them as expressions, which tends to result in confusing code.

These are the issues I've come up with so far, but there are probably others

[AnEmortalKid]

Let me mull over 1 for a bit. For two, could we make a distinction between postfix and prefix with bigify (identifier) - prefix (Identifier) bigified - postfix Ify applies to next , ified applies to previous?

…

On Fri, Dec 21, 2018 at 09:56 vpzomtrrfrt ***@***.***> wrote: There are a few ambiguities that I'd like to solve in 3.0. 1. wow returns plz doThing with 'doge' much result console dose loge with result wow 'another value' Could be interpreted as either: doThing('doge', function(result) { console.log(result); }, 'another value'); or: doThing('doge', function(result) { console.log(result); return 'another value'; }); In 2.x, we also require wow& *before* the return value, which adds another possible interpretation if used that way. This also adds additional complexity to the parser, as nothing I've done so far has involved optional expressions. To solve this, we could: - Disallow wow-returns for anonymous functions, and determine intent based on the presence of a newline after the closing wow - Add a required token between wow and the return value, maybe with? - Define precedence so at least there *is* an answer, even if unclear to the reader - Remove the feature altogether, and use regular return statements (I don't think these exist yet, but I think they should for early returns anyway) - Anything else? 2. bigify/smallify These operators are allowed to appear either before or after their operand. However, due to our lack of separation between values, this introduces an ambiguity, since plz foo with bar bigify baz could be parsed as either foo(bar++, baz) or foo(bar, ++baz). Perhaps we should drop the postfix option. That would clear up this issue, and I feel that the prefix option is more doge-like. The functional difference between them only matters when using them as expressions, which tends to result in confusing code. These are the issues I've come up with so far, but there are probably others — You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub <#115 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/ADUDwSRsqYmyUtFTFALJXIwlegpZY6n2ks5u7QTIgaJpZM4P0yCm> .

[vpzomtrrfrt]

That would work, though I wonder if that sounds more like foo + 1 than foo++. Another answer would be to only allow assignments as statements or for-loop endings

[AnEmortalKid]

For wow

Remove the feature altogether, and use regular return statements (I don't think these exist yet, but I think they should for early returns anyway)
Add a required token between wow and the return value, maybe with?

I like the thought of having a clearer return and not mangling wow or having to do some guesswork with wow, wow&. Having the return keyword would let us be more explicit and have wow or wow& as the terminating token (nothing after it). With the introduction of thx , we could default to appending ); after all arguments to a function call are consumed and change it to ) when we see thx.

so:

plz doThing with 'doge' much result
    console dose loge with result
  gib|return|somethingelse 'another value'
wow

Would yield:

doThing('doge', function(result) {
    console.log(result);
    return 'another value';
});

And

plz doThing with 'doge' much result
    console dose loge with result
wow 'another value'

Creates:

doThing('doge', function(result) {
    console.log(result);
}, 'another value');

I guess another suggestion would be to use also to denote where arguments end? but that just makes things tricky yet again.

plz doThing with 'doge' much result
    console dose loge with result
wow 'another value'

vs

plz doThing with 'doge' much result
    console dose loge with result
wow also 'another value'

And even more confusing....

plz doThing with 'doge' much result
    console dose loge with result
wow 'result' also 'another value'

To produce:

doThing('doge', function(result) {
    console.log(result);
   return 'result';
}, 'another value');

[vpzomtrrfrt]

One thought I had was to reuse woof for returns, though that overlap may also be a drawback

[AnEmortalKid]

One thought I had was to reuse woof for returns, though that overlap may also be a drawback

Yeah, i'd like to not have overlap for 3.0, that much being a for-loop and a lambda is really messy too :(

If woof is good for return, maybe we can change the module exports.

[vpzomtrrfrt]

Is this supposed to be closed?

[AnEmortalKid]

No..... darn it i must have put Fixes ID in my PR :(

[vpzomtrrfrt]

5evar is now supported in the 3.x parser

[vpzomtrrfrt]

also can now be used as a separator in much, box, obj, and argument lists

[vpzomtrrfrt]

I don't think merging with DSON is viable, since all of the keywords are already doing wildly different things