Comments (17)
Cut is not meant to replace fun abstractions in anything but the simplest of cases. IMO, the more powerful things that you're requesting really need full funs to deal with them. Note that the scheme implementation also takes the same stance: the holes created by <>
have to appear in a cut(...)
immediately wrapping it (i.e. they can't go deep). This is basically a rabbit hole: if you allow them to go deep then why wouldn't you permit something like:
foo() ->
1 + _.
bar() ->
3 = (cut(foo()))(2).
or some such craziness? funs have their place, and cut should IMO be a very lightweight and simple shorthand.
The question of whether or not do have a cut(...)
wrapper is less clear cut (HONK!). Certainly, yes, scheme's cut does, but that's at least partly so that you can distinguish cut
from cute
. Legibility is very important and I'm not yet sure in my own mind whether or not the cut(...)
wrapper would aid comprehension: you'd probably want your syntax highlighter to colour it differently. I think that being able to write
F = case _ of
...
is extremely elegant and clear, whereas
F = cut(case _ of
...
)
is less so. I think time will tell on this one: just because an expression is prefixed with cut(
does not make it any more obvious where the _
are. From a technical pov of writing the code, it makes next to no difference in complexity.
from erlando.
There is another problem that can be solved with an explicit cuts. Look at this:
Loop_F = fun(X) -> handle_http(#http_state{req=X}) end
At first glance it can be rewritten as
Loop_F = handle_http(#http_state{req=_})
but in fact this one is
Loop_F = handle_http(fun(X) -> #http_state{req=X} end)
from erlando.
Another issue. What is the actual result of an expression like
{A,B,C} = {X, _, Z} = Exp
Does the middle expression {X, _, Z} get a cut as the right hand-side expression of {A,B,C}, or is it a regular pattern matching given it's on the left hand-side of Exp?
from erlando.
Why can't anyone see this is a stupid idea?
https://github.com/rabbitmq/erlando/blob/master/test/src/test_cut.erl
This code requires all these comments just to make heads or tails of it...
All of the benefits gained from brevity are instantly lost to obfuscation and incompatibilities with the existing meaning of _
from erlando.
That sounds like a problem on the part of the reader, more than the parse transform.
Once you understand what they do, the only problem I see is visual ambiguity with _'s conventional usage. Having to figure out whether it's on the left or right side of an equals sign is a bit annoying.
from erlando.
{A,B,C} = {X, _, Z} = Exp
The _
is in a pattern position - you are matching against it. Thus there is no cut there.
from erlando.
I agree - if the erlang parser was far less picky about syntax, another token, one which is unused, would have been a better choice, to avoid the overloading. Writing a few parse transforms is one thing. Rewriting the erlang parser is another ;)
from erlando.
I thought I could reply to your first arguments, msackman. Sorry for the delay on that.
foo() ->
1 + _.
bar() ->
3 = (cut(foo()))(2).
It wouldn't make sense to allow the cut in this case because
- the way function calls work in Erlang doesn't allow that,
- there is no closure to be built with such a form no matter what the existing semantics are
- I can't see how this would parse with mandatory and wrapped cuts given you'd have no access to the syntax inside
- it would not work with funs anyway
If you look at my suggestions, there is no ambiguity, only a shorthand for funs, basically.
funs have their place, and cut should IMO be a very lightweight and simple shorthand.
This is a fairly good point. While my approach is still shorter and more lightweight than funs, yours is even more so. I still think that being able to clearly identify a cut from afar (and even look them up with a quick search) would be beneficial, also given the ability to nest them.
I'm obviously not in charge of the lib and likely won't take the time to fork and fix, so I'll wish you a nice day and carry on :)
from erlando.
Erlang variables can be [A-Z_][a-Z0-9_@]* so it's possible to easily change cut syntax to __, or @, or _@, or something like that.
from erlando.
Indeed. However, _
has the advantage that it can't be bound to, unlike those others. By overloading _
as cut does, I can guarantee that I don't break anyone's existing code. The same couldn't be said by using something like _@
etc. The ideal would be to be able to use some token that is not a variable. Eg. &
, or even better, <>
from erlando.
@msackman
Maybe it would be good idea to make both cut() and cut()-less versions of cuts available? You are right in your arguments, but there are at least 2 reasons to make cut() available:
-making not-so-easy cases more clear;
-making possible nested cuts (like Loop_F = fun(X) -> handle_http(#http_state{req=X}) end
).
from erlando.
@si14 Sure - I'm not claiming that the arguments I'm putting forward out-weigh the gains of the phantom cut marker, but it's probably something I'd have to do on my own time... not sure. I'll see when I can get around to it. Obviously, the more I actually get to use this stuff, the more I can get a feeling of how urgent this addition would be.
from erlando.
As I was saying on IRC, and you probably weren't there, don't overuse the < and > characters. They're already used for <<, >>, =<, >=, and it's already annoying that =<< causes errors. & is much better choice which is what I proposed on IRC last night. Of course I don't think either can be used because it prevents compilation of the file as they're not defined to begin with.
from erlando.
@essen, yeah good point about < and > already being problematic. Again, the issue is the parser... someone really needs to rewrite that thing.
from erlando.
While on the subject of tagged cuts, does anyone have thoughts on the "cute" variant?
It evaluates arguments when the fun is created, rather than when the fun is called. A concise way to lift invariant work out of loops.
from erlando.
For anybody else who stumbles on this issue, here's my attempt at implementing a cut/cute wrapper in order to resolve the above: https://github.com/jkrukoff/partial
from erlando.
Team RabbitMQ considers this project abandoned and will archive this repository. Anyone can feel free to push the code to a new repo and continue maintenance. Thanks!
from erlando.
Related Issues (11)
- eunit test run does not detect test failures HOT 1
- R16B support HOT 7
- Can't run make HOT 1
- use of parameterized modules? HOT 3
- Time to tag new release? HOT 4
- Publish to hex.pm HOT 1
- parameterized modules are no longer supported HOT 1
- Haskell in Erlang? HOT 1
- monad:sequence/2 evaluates 'Xs' from right to left? HOT 6
- Unused variable compiler warnings HOT 3
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from erlando.