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

"Truthy pipe" syntax proposition #197

Closed
akx opened this issue Jan 2, 2013 · 9 comments
Closed

"Truthy pipe" syntax proposition #197

akx opened this issue Jan 2, 2013 · 9 comments

Comments

@akx
Copy link

akx commented Jan 2, 2013

For a lark, I wanted to see what some Django ORM code might look like in Coco and ended up with

object-list =
  Category.objects.language instance.language
  |> if category = instance.category then &filter {category} else &
  |> &slice instance.count

-- this works alright, but the second line of the chain is kinda ugly because of the else branch.

So I'd propose a "truthy pipe" syntax, perhaps ?>, so any falsy values in that block would be emitted as & instead.

object-list =
  Category.objects.language instance.language
  ?> (&filter {category} if category = instance.category)
  |> &slice instance.count

Currently, with Coco 0.9, with |> instead of ?> the following JS is emitted (I've added some linebreaks for readability), and obviously the "void 8" emitted as the implicit "else" breaks the chaining.

var objectList, x$, category;
objectList = (
  x$ = Category.objects.language(instance.language),
  x$ = (category = instance.category) ?
    x$.filter({category: category}) :
    void 8,
  x$.slice(instance.count)
);

In addition I wouldn't mind it if ?> had a slightly different precedence so the parentheses in the post-if wouldn't be necessary...

@satyr
Copy link
Owner

satyr commented Jan 2, 2013

A new operator solely for omitting at most 7 bytes in a narrow situation sounds overkill.

@satyr
Copy link
Owner

satyr commented Jan 9, 2013

Closing for the reason above.

I wouldn't mind it if ?> had a slightly different precedence so the parentheses in the post-if wouldn't be necessary...

As for this issue, |> is given the lowest precedence present (as I didn't want to create yet another level) which happens to be the same as post-if. May have been a mistake considering expressions like a |> b if c |> d unintuitively evaluates as ((a |> b) if c) |> d.

@vendethiel
Copy link
Contributor

On a single line, isn't it going to conflict with post-if specialcase ?

@satyr
Copy link
Owner

satyr commented Jan 9, 2013

What specialcase exactly?

@vendethiel
Copy link
Contributor

I'm talking about inline implicit object rule (something like that), 140c648.

@satyr
Copy link
Owner

satyr commented Jan 9, 2013

The brace-insertion for implicit objects kicks in before the parser job. They may seem to interact oddly, but not in a conflicting way.

@vendethiel
Copy link
Contributor

I don't really get what happens in cases like a |> b c: d |> foo if bar.

@satyr
Copy link
Owner

satyr commented Jan 9, 2013

It goes:

a |> b {c: d |> foo} if bar

a |> b({c: d |> foo}) if bar

a |> (b({c: d |> foo}) if bar)

Hm. Probably |> should also close inline implicit objects.

@vendethiel
Copy link
Contributor

Yeah, that's what I thought.

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

No branches or pull requests

3 participants