Skip to content

Standard stymbol for as-> #164

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

Closed
garrett-hopper opened this issue Mar 26, 2018 · 7 comments
Closed

Standard stymbol for as-> #164

garrett-hopper opened this issue Mar 26, 2018 · 7 comments

Comments

@garrett-hopper
Copy link

I think it would be worthwhile to choose a standard symbol for use with as->.

Sometimes there's an actual name that makes sense in the context, but often an arbitrary symbol is needed for values that change dramatically throughout the macro.

_

(as-> VAL _
  (do-stuff nil _ nil)
  (do-other-stuff _ nil)
  (do-more-stuff _))

This could lead to confusion with the convention of using _ for ignored values.

<>

(as-> VAL <>
  (do-stuff nil <> nil)
  (do-other-stuff <> nil)
  (do-more-stuff <>))

%

(as-> VAL %
  (do-stuff nil % nil)
  (do-other-stuff % nil)
  (do-more-stuff %))
@daveliepmann
Copy link
Contributor

I am not sure I would be comfortable with that degree of prescriptivism in this resource. One of the reasons that this style guide is so widely used and respected is that it generally refrains from making up its own rules, but instead describes and codifies existing standards. If there isn't a strong existing pattern in the wild, then I don't think it's appropriate to pick a winner here and try to make it a standard.

If that argument ends up losing and some symbol is established, _ should be an absolute non-starter because of the firmly established convention for ignoring it, as you acknowledge. Confusing an existing, widespread, core-team-endorsed idiom would be a serious faux pas. Let us please never speak of this possibility again.

@garrett-hopper
Copy link
Author

I agree that this guide shouldn't be making up arbitrary rules that aren't already in practice.

My goal here is to identify an existing standard, if it exists and document it. If there are a few different standards in place, I think it's worthwhile to consider the pros and cons of different options and document the most common ones without necessarily picking a winner.

Especially when I was starting, I would run into a decision like this and freeze, because I wasn't sure what the common practice was. @daveliepmann Do you think there's room in this guide for suggestions for those that are looking for them and not merely specifications?

If I was starting a new project now and bringing in new-to-Clojure developers, I would rather have a standard to point them to instead of having each of them choose their own arbitrary symbol for this purpose. This standard would be at the project level and not at the style guide level.

I've had a number of people reiterate the _ issue, so I think that's dead in the water, though I think the same applies to % shadowing anonymous functions.
<> lines up with https://github.com/rplevy/swiss-arrows -<> macro, though it still doesn't feel quite right to me.

Again, I'm not trying to pick a winner and establish a standard to enforce on people. I just want an open discussion about this to see what the options are.

@eigenhombre
Copy link

The symbol used in as-> has the potential to explain or reinforce understanding of the intent of the code, so specifying it in the style guide seems overly prescriptive to me.

@garrett-hopper
Copy link
Author

It has the potential to, but often a generic symbol is needed for times when there just isn't a name that can be given to what's being threaded through the macro.

@garrett-hopper
Copy link
Author

@arrdem mentioned $ on the slack channel.

@arrdem
Copy link
Contributor

arrdem commented Mar 26, 2018

I don't support putting a prescription for choice of as local in the style guide. It's called as-> so you can choose your own local as opposed to -<> which dictated <>. Sometimes the value you're threading has a meaningful name (eg. the type is consistent), sometimes it doesn't because you're going through a bunch of intermediary values. Trying to prescribe something goes well beyond the scope of this document.

@garrett-hopper
Copy link
Author

That's fair. I figured this wasn't the best place for it, though I couldn't think of anywhere else it might make sense to talk about—perhaps some more examples at clojuredocs.
Thanks, everyone, I'll close this, since it's clear this isn't the right place for this.

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

4 participants