Hah! I’m aware of the short hand, but I’m not a big fan. I find that it makes code less readable, unless its very obvious.
abitdodgy
mmport80
Shouldn’t for just be map?
As for |> perhaps being able to define infix operaters would avoid the need for that macro..
e.g. something like (|>) x f = f x
Which uses a far, far less powerful language construct to achieve the same thing..
Structs should probably just be a first class part of Elixir. I don’t seem why they need to be a macro.
The problem with compile time DSL’s is that most of the time they seem more of a hindrance than a feature.
I like Ecto for example, but my colleagues complain about it or avoid using it completely - mainly I reckon, because of the macro interface.
Functional programming is about simplicity.
Macros seem to obfuscate mostly when obfuscation isn’t perhaps necessary.
Sure functional composition can be overly verbose now and then, but at least it’s explicit..
0
hauleth
for is much more than Enum.map. It is list comprehension so you can filter there, do multiple iterations at once, etc. For example this is example with map:
Enum.flat_map(1..10, fn a ->
Enum.map(1..10, fn b ->
{a, b, a * b}
end)
end)
And this is example with for:
for a <- 1..10,
b <- 1..10,
do: {a, b, a * b}
Elixir has bound set of possible infix operators. Maybe that could be lifted, but I think it would greatly complicate the parser.
Because BEAM do not have structs at all, only maps (since OTP 18). All structures are in fact just special examples of maps, and macros are needed to handle all Elixir’s magic around them.
Unfortunately there are things you cannot do without macros, or things that looks ugly when macros aren’t available. As impossible things let’s see at the Ecto example: within “pure” Elixir fragment is impossible in current form, you would need to pass an list as a second argument. While we can argue that it could simplify some things it would make one thing impossible - compile time errors for missing arguments.
About ugly things. Do you remember using nested case when there were no with available? It was super ugly. Or how about our nice friend in? def foo(a) when a in 1..10 is quite simple, but how about def bar(a) when a in ~w[a b c d e f]a? You would need to write def bar(a) when a == :a or a == :b or a == :c or a == :d or a == :e or a == :f. Super nice. Also remember that Elixir is built on macros, if is a macro, in is a macro, use is a macro, alias is a macro, def is a macro, defmodule is a macro… almost everything is a macro, so writing code without macros would be terrible experience.
1
mmport80
I suppose I would argue that there’s a bunch of macro stuff which is great for language designers but prob not good for library designers.
I and many ppl using Elixir have 2 responses when using macro based libraries:
At first → cool, this looks appealing
Sometime later →
this API isn’t v clear to me
this error message is pretty cryptic
I love with etc.
But agree strongly with the beginner’s guide caution about macros: i.e. “use with caution”.
So much so, that they should be seen as bad practice unless you are Mr. Valim (a little extreme, but not far from it… ; ))
0
hauleth
That is different thing. In general I would also advise to not use macros unless you know what you are doing and that you know you can handle that. I have written some libraries that heavily utilise macros (ecto_function) but also I have removed a lot of macros from libraries that didn’t needed that (prometheus_ex). So macros are great, but you shouldn’t write one yourself.
1
peerreynders
OvermindDL1
No, it’s closer to reduce but more succinct.
I agree, but Elixir prepends arguments instead of post-pends and it doesn’t handle anonymous functions cleanly like that.
I personally don’t know why they are maps, they should be tagged tuples on the beam, that is the usual ‘structural’ type after all… >.>
They should instead be called row-typed records or ‘objects’ (not OOP objects).
They should really look closer at it, that interfaces gains you a lot of safety and features that is not otherwise possible via a lower level SQL interface.
Not always, macro’s allow you to add to the language that which it is not otherwise capable of as efficiently or at all.
No, it already can be that, the issue is that using it would then require doing 42 |> &someFunction(&1, 1, 2). |> is a normal infix operator, you can implement it as a normal function or as an operator, it works fine either way, but by using a macro it allows a more ‘normal’ function call syntax, even though honestly I would rather kind of prefer the currying syntax, but you’d have to hope it gets optimized out, and honestly it probably wouldn’t (though a macro could fix that).
Structs and Records should have just been the same thing, a set of tagged tuples with information compiled into a module for introspection about it.
Eh technically some of those are special forms, although with could have been implemented with a better syntax as a macro in my opinion… >.>
I don’t, the comma-turds (erlang’ism) littering it’s expressions and the formatter making it look horrid are two big issues I have with it, both of which significantly harm readability for me (maybe not others, but for me, the formatter is just so bad on it…). I only use it to not pull in other libraries (that do it better) to reduce the dependencies I use.
1
mmport80
everything is just a reduce ; ) but i was messing around with maps with a colleague, and saw the map is a much closer analogy
agreed!
thing is, random_library_authors think they knew some new language feature that will solve our woes - mostly not the case : (
The semantics are good, the syntax is indeed in need of a spring clean : )
0
Qqwy
TypeCheck Core Team
Finally I thought of something!
I would remove the current Enum.map and similar functions, and replace them by ones that make more clear that we are destroying the structure and returning a list while mapping. And I would like to introduce a new built-in Protocol that allows you to iterate over things while keeping their structure. (So a transforming map rather than a destructive one)
2
LostKobrakai
This might not be the most obvious place, but the reasoning behind that behaviour by the Enumberable protocol is explained in the docs for the Collectable protocol. So using the Enum module does already imply you might loose shape as it’s working with a protocol build on that premise.
1