Special-case `else`?

8 views
Skip to first unread message

Ram Rachum

unread,
Jan 24, 2014, 7:48:37 AM1/24/14
to shp...@googlegroups.com
One ugliness occurred to me regarding Shpaml. When using Django's if-else in Shpaml, the else tag will have to not really contain the text below it, despite how logical it is, because it's not a tag that has an end tag, but is rather ended by {% endif %}.

I suggest we special-case `else` to allow putting code indented after it without creating a nonsensical {% endelse %} tag.

Do you agree? 


Thanks,
Ram.

James Robert

unread,
Jan 24, 2014, 3:25:52 PM1/24/14
to shp...@googlegroups.com
I do agree that it would be nicer, and I did look into it when I implemented the django integration. However, I opted not to build the special case at the time in order to save on complexity.

however, I'm definitely willing to give it a second look (pull requests welcome ;P)


--
You received this message because you are subscribed to the Google Groups "shpaml" group.
To unsubscribe from this group and stop receiving emails from it, send an email to shpaml+un...@googlegroups.com.
For more options, visit https://groups.google.com/groups/opt_out.

Ram Rachum

unread,
Jan 24, 2014, 6:44:47 PM1/24/14
to shp...@googlegroups.com
I understand the complexity concern, and I'm +1 to have cool else tags at the price of this complexity.

For me to implement this feature will require me to dive into and familiarize myself with the Shpaml codebase. I'm willing to do that, but only if we reach a decision that we want to have it in the language. (I don't want to spend 1-2 hours on this only to have it rejected.)


--
You received this message because you are subscribed to a topic in the Google Groups "shpaml" group.
To unsubscribe from this topic, visit https://groups.google.com/d/topic/shpaml/OAcrkmWaf28/unsubscribe.
To unsubscribe from this group and all its topics, send an email to shpaml+un...@googlegroups.com.

James Robert

unread,
Jan 24, 2014, 6:46:21 PM1/24/14
to shp...@googlegroups.com
I'm for it. What do you think Steve?

Steve Howell

unread,
Jan 24, 2014, 6:56:11 PM1/24/14
to shp...@googlegroups.com
I don't really control the main shpaml implementation any more, so there is no longer danger of me rejecting any changes.  My memory is foggy on how invasive "else" would be to the code, but it certainly seems like a useful thing to have.

James Robert

unread,
Jan 24, 2014, 6:57:49 PM1/24/14
to shp...@googlegroups.com
Ok let's do it then =D

I'll merge and sane pull request that implements this feature :)

Ram Rachum

unread,
Feb 13, 2014, 5:18:11 PM2/13/14
to shp...@googlegroups.com
I've tried doing this now. It's difficult.

It might require me to change how the Shpaml parser is structured. I'd really hate to do that, because I didn't write it so I don't understand the way it's build so I'll probably suck at modifying it.

If it was implemented as a grammar then maybe it would have been easy... But right now I have no idea how I'd do this. 

Steve Howell

unread,
Feb 13, 2014, 5:47:43 PM2/13/14
to shp...@googlegroups.com
Can you describe the problems you are encountering in a little more detail?

Steve Howell

unread,
Feb 13, 2014, 7:12:32 PM2/13/14
to shp...@googlegroups.com
So I looked at the code a bit, and I'm guessing Ram's issue is that Django blocks starting with "if" automatically close with "end", which is great when you don't have "else" blocks, but unfortunate when you do have "else" blocks.  Perhaps naively, I don't think it should be too much trouble to just have the "else" blocks pop the last "end" off of output.

Shpaml is intended to be basically semantic-free; i.e. it's totally a syntax layer.  So I don't think it's necessarily in the scope of the problem to enforce that else lines actually correctly follow the right if lines.  But I agree that if you did want to enforce those semantics, things would get kind of tricky.

It would be really interesting to see a grammar-based approach to this, but from a pragmatic standpoint, I also think it's worth trying the pop-the-last-line-off approach within the current paradigm.

Ram Rachum

unread,
Feb 14, 2014, 8:07:55 AM2/14/14
to shp...@googlegroups.com
Those are pretty much my thoughts. But:

1. To pop off the end, you need to know that the last action was an if... I don't see a mechanism in the code to get that information. I could add one but then I'm making structural changes.

2. You also need to replace {% endelse %} with {% endif %}

Steve Howell

unread,
Feb 15, 2014, 6:34:52 AM2/15/14
to shp...@googlegroups.com
Maybe the solution here is to change the block detection logic so that when it sees the next line at the same indentation (which might be the "else" line), it not only terminates the block, but it also passes the line into the code that reformats the block.  This would allow you to then look at the "if" and know that you don't generate an end tag for it yet.
Reply all
Reply to author
Forward
0 new messages