31–40 of 49 posts
> Below, the code on the left is equivalent to the more verbose ML expression on the right: Wait a sec ... ML has the pipe of Elixir? Damn, I didn't know that! I like the brevity, but I don't like the (at least visual) need to indent or whitespace focus. I guess I am too much a sucker for S-expressions now. But a similar structure could probably be written as a macro in a lisp, avoiding any whitespace focus or even d…
This is really cool It reminds me a lot of the kind of flow you get in mathematics sometimes. I guess theorem prover languages may be keen to adopt it. I'd be less keen in a language with side effects, unless the language has a way to restrict it to pure functions
I don't understand how it's better than traditional pattern matching.
With traditional matching there are up to five different things: - if x then y else z. This is roughly like a match with a true and false case but it depends on the language how much that is - match e with { p -> e }. This is the classic pattern match case - if let p = e then x. This is roughly equivalent to (match e with p -> x | _ -> ()) - match e with { p when e -> e }. This is matching with a guard but I’ve count…
def agent(data, predicate, fns):
ps = map(predicate, data)
fs = map(lambda x:fns[x], ps)
return map(fs, data)
This is "agent" from J: https://code.jsoftware.com/wiki/Vocabulary/atdot#agent
if foo(args)
== 0 then "null"
|> abs
> 100 then "large"
The other one I want occassionally is "or". Imagine Left and Right contained data of compatible types, then I'd like to extract that data (regardless of tag) like so: if x is Left(y) or x is Right(y) then ... That way I only need to write the `...` part once. (This could be combined with the rest of the pattern matching machinery in interesting ways, and would probably need to have eager matching / short-circuiting s…
We definitely want to get into that! Unfortunately it's not completely straightforward. A simple desugaring doesn't work due to our support for intermediate bindings and computations, which we don't want to recompute.
if (x is Left(Foo(y)) or x is Right(Foo(y))) and (y2) then 5
Earlier quoted context omitted.
There's such a thing as too high an abstraction. Sometimes 4 different operations really are just 4 different operations and not cases of some mega-construct.
I totally agree that can be the case, but I’m not sure it applies that much to the OP.
Earlier quoted context omitted.
With traditional matching there are up to five different things: - if x then y else z. This is roughly like a match with a true and false case but it depends on the language how much that is - match e with { p -> e }. This is the classic pattern match case - if let p = e then x. This is roughly equivalent to (match e with p -> x | _ -> ()) - match e with { p when e -> e }. This is matching with a guard but I’ve count…
There's such a thing as too high an abstraction. Sometimes 4 different operations really are just 4 different operations and not cases of some mega-construct.
I didn't think of it this way at the time, but my current belief is that complicated pattern matching is an extremely tight coupling to what is being matched, and that's not a good thing.
I'm not convinced super powerful pattern matching is even a good idea. I think a lot of the love people have for it is precisely their joy at being about to introduce tight coupling with such syntactical convenience. Syntax affording tight coupling is not a good thing.
(Simple pattern matching, especially on branches of a sum type, is fine and useful, especially when you are doing it precisely because the code will need to be changed if the sum type adds or subtracts other branches, and this need comes from something "real" and not merely false coupling. But the deeper in you go with the pattern match the more whatever it is you are reaching in for should be abstracted out into a function.)
This is the ultimate conditional syntax: if (x === 1) console.log(“it’s 1”) The “if” bothers me though, be nice not to have it.
(x === 1) && console.log("it's 1") Note that you've saved exactly no keystrokes, although this is composable into expressions (if you are using some Javascript-derivative; in ML it would typically already be using the if-form).
Earlier quoted context omitted.
I don't think that this is `with` (which is really a series of nested `case` statements with exactly two paths per case). case is_email_address?(email) do true -> case String.length(code) == 6 do true -> case EmailConfirmations.get_email_confirmation(email) do %EmailConfirmation{} -> case EmailAddresses.get_email_address(email) do nil -> case Users.create_user(data) do {:ok, user} -> case EmailAddresses.create_email_…
My eyes! They burn!