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

Ellipsis #218

Closed
wants to merge 2 commits into from
Closed

Ellipsis #218

wants to merge 2 commits into from

Conversation

sfiera
Copy link
Contributor

@sfiera sfiera commented Jun 1, 2014

Not extensively tested. Here's the three Wizard levels from Heroes of Sokoban using the new rule:

https://gist.github.com/sfiera/38520b8a950bb8db2f47

Previously, ellipses were a special value, which meant that all of the
logic around them had to be special-cased every time.  Now, they are
represented as CellPattern objects with "hasEllipsis" set to true.
Ellipsis no longer needs to be alone; it just needs to be last.  The
ellipsis will only span over matching blocks.  This is useful for
line-of-sight sorts of things. For example, the rule for the Wizard in
Heroes of Sokoban can be simplified to:

    [ > Wizard | no Wall no Crate ... | Crate ] -> [ Crate | ... | Wizard ]

Heroes of Sokoban III uses this more complicated formulation:

    [ > Wizard ] -> [ Wizard > Warpball]
    [ > Warpball | no Crate no Wall] -> [ | > Warpball]
    [ > Warpball | Wall] [Wizard] -> [ | Wall ] [> Wizard]
    [ > Warpball | Crate ] [Wizard] -> [ | Wizard ] [Crate]
    [ > Warpball] [Wizard] -> [] [> Wizard]

This extension is backwards-compatible; an ellipsis pattern "A|B ...|C"
matches "A|C", "A|B|C", "A|B|B|C", etc., so if B is empty, the pattern
naturally matches "A|C", "A||C", "A|||C", etc.
@increpare
Copy link
Owner

Hi,

People have requested this before, and I've rejected it on simplicity grounds. It's pretty easy to read what's going on, I admit. BUT it is extra syntax to explain, and I find it (only) very slightly inelegant as notation goes.

I have to be crazy conservative about adding extra capabilities to the language, even where they might seem to be a no-brainer, because it will result in the engine becoming a fussy mess (I've made one or two mistakes already in this regard (cf the 'rigid' keyword). So I'm going to sit on this for a while. But I do appreciate you putting in the work, and recognise that it must've taken a fair bit of trouble to figure out the funky code :)

<3

S

@sfiera
Copy link
Contributor Author

sfiera commented Jun 1, 2014

OK, that's fine. How do you feel about just the first commit? No behavior change there, just less funky code.

@increpare
Copy link
Owner

In principle I think it might be good! I may integrate it for the next
update.

On Sun, Jun 1, 2014 at 10:40 PM, Chris Pickel notifications@github.com
wrote:

OK, that's fine. How do you feel about just the first commit? No behavior
change there, just less funky code.


Reply to this email directly or view it on GitHub
#218 (comment)
.

@increpare
Copy link
Owner

thanks :)

On Mon, Jun 2, 2014 at 12:00 AM, Stephen Lavelle analytic@gmail.com wrote:

In principle I think it might be good! I may integrate it for the next
update.

On Sun, Jun 1, 2014 at 10:40 PM, Chris Pickel notifications@github.com
wrote:

OK, that's fine. How do you feel about just the first commit? No behavior
change there, just less funky code.


Reply to this email directly or view it on GitHub
#218 (comment)
.

@increpare
Copy link
Owner

jonah gives this the thumbs up...

@increpare
Copy link
Owner

I still can't motivate myself to incorporate this, even while I'd use it myself sometimes I don't like the notation, and can't think of a better notation. I'm going to close this and maybe in the future I'll be struck by inspiration for a notation for this that's more pleasing to me ^^

Thanks again!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants