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

Using anon functions in a nested @. function #44

Open
max-sixty opened this issue Dec 8, 2021 · 2 comments
Open

Using anon functions in a nested @. function #44

max-sixty opened this issue Dec 8, 2021 · 2 comments

Comments

@max-sixty
Copy link

max-sixty commented Dec 8, 2021

Another one from me — I'm adding these because I think this library is superb and I'm exploring how far it can go — I realize the past few issues have been corner cases.

Building on #42, this works:

s = "dbaf fag bdfgea ecbgfa dgbfe fa edacg agcfdbe cefdbg fdgea | fgbaed cdegbf dacfbge gdcfbe
abc acefbd gacedbf gbcde dgabf ca fgcedb cega dgbca cgeadb | ca bcged abgfd bca"

function inner(x)
    (x -> split(x, "|"))(x)
end

input = @chain s begin
    strip    

    split("\n")
    @. inner
end

But if we replace inner with the function, it fails:

input = @chain s begin
    strip    

    split("\n")
    @. (x -> split(x, "|")) # (or with (_) at the end)
end

# You can only use the @. macro and automatic first argument insertion if what follows is of the form `[Module.SubModule.]func`

My understanding from the docs is that that should be syntactic sugar for this, which also works:

input = @chain s begin
    strip    

    split("\n")
    (x -> split(x, "|")).(_)
end
@jkrumbiegel
Copy link
Owner

jkrumbiegel commented Dec 9, 2021

You could just do split.("|")? I'm not sure if adding the overhead for recognizing anonymous functions makes so much sense given all the other options to write this.

@max-sixty
Copy link
Author

For sure in this specific case there's no need, and I agree it's not important. It can be useful on the margin when debugging, or copying code from elsewhere. I was mostly surprised it wasn't consistent, rather than really needing it.

It's a corner case, and very reasonable to deprioritize. Thanks.

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

2 participants