Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

3.0 Feature List #115

Open
AnEmortalKid opened this issue Oct 11, 2017 · 16 comments

Comments

Projects
None yet
2 participants
@AnEmortalKid
Copy link
Member

commented Oct 11, 2017

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 (#88)
  • Native DSON support (spec may need to change, need to investigate potential ambiguities) #68
  • Investigate feasibility of swapping with keyword around #15
  • precedence fixes (#71)
  • Comparison operator sanitization, from #45 and #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 #189
@vpzomtrrfrt

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

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

@AnEmortalKid

This comment has been minimized.

Copy link
Member Author

commented Dec 10, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 10, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Dec 10, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Dec 10, 2018

@Pholey might be interested in the parser as well.

@vpzomtrrfrt

This comment has been minimized.

Copy link
Member

commented Dec 11, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Dec 11, 2018

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 &.

@AnEmortalKid AnEmortalKid pinned this issue Dec 14, 2018

@vpzomtrrfrt

This comment has been minimized.

Copy link
Member

commented Dec 21, 2018

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

@vpzomtrrfrt

This comment has been minimized.

Copy link
Member

commented Dec 21, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2018

@vpzomtrrfrt

This comment has been minimized.

Copy link
Member

commented Dec 21, 2018

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

This comment has been minimized.

Copy link
Member Author

commented Dec 21, 2018

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

This comment has been minimized.

Copy link
Member

commented Dec 22, 2018

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

@AnEmortalKid AnEmortalKid added this to the 3.0.0 milestone Dec 23, 2018

@AnEmortalKid

This comment has been minimized.

Copy link
Member Author

commented Dec 23, 2018

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

This comment has been minimized.

Copy link
Member

commented Jun 14, 2019

Is this supposed to be closed?

@AnEmortalKid

This comment has been minimized.

Copy link
Member Author

commented Jun 14, 2019

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

@AnEmortalKid AnEmortalKid reopened this Jun 14, 2019

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
You can’t perform that action at this time.