4 ms·

I'd love to see the exclamation mark requirement removed from the rust spec. It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a l

I'd love to see the exclamation mark requirement removed from the rust spec. It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a lack of confidence in the macro system. I'd rather the language designers assume that future tooling for IDEs and editors will syntax highlight macros.

rayiner 12y ago
It makes me thing it signals mutation.
- Dewie 12y ago
  Because that's the convention in lisp?
  - deleted 12y ago
    [deleted]
  - zzalpha 12y ago
    Both Lisp and Ruby all follow that convention. Probably other languages, too, but I'm too lazy to look... :)
    - steveklabnik 12y ago
      In Ruby, it does _not_ mean mutation. It means 'danger.' Sometimes that's mutation, sometimes its other things, like throwing an exception rather than returning nil on error.
  - rayiner 12y ago
    Technically, it's not the convention in Common Lisp, but rather Scheme and Dylan. But yes.
the_mitsuhiko 12y ago
> It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a lack of confidence in the macro system But a macro invocation is special. The syntax within a macro does not follow Rust rules, so if macros would not be marked properly it would be incredibly confusing for a user. Let alone that macro imports are different by the very nature of their behavior.
- eddyb 12y ago
  Not to mention it would be difficult, if not impossible, to parse in the first place (the contents of a macro invocation are stored as token trees within macro AST nodes, within the regular AST).
- kybernetikos 12y ago
  I think that the 'call-by-name' behaviour in Scala is confusing, because you can write something that you think will execute once but actually, it might execute multiple times and there's no obvious marker that it's special. When you have something that is potentially major, you generally don't want it to be invisible.
AndyKelley 12y ago
Macro invocation is special. It's significantly more readable to know whether you're calling a function or invoking a macro.
kibwen 12y ago
Macros have a freeform syntax, with the only restriction being that delimiters within have to be balanced. I don't see how an IDE could provide general syntax highlighting for them.
- whyever 12y ago
  The IDE could parse the macro definition and highlight accordingly. (It would know where to expect an identifier and where to expect an expression etc.)
  - steveklabnik 12y ago
    > (It would know where to expect an identifier and where to expect an expression etc.) But that doesn't mean that what's in the macro should be highlighted like Rust: sql!("SELECT * FROM users WHERE name = $1"); is a macro provided by https://github.com/sfackler/rust-postgres-macros https://github.com/sfackler/rust-postgres-macros , and should be highlighted like SQL, not like a Rust string. sql!("SELECT * FORM users WHERE name = $1"); throws an error, because it's malformed.
JoshTriplett 12y ago
That's actually a feature of Rust that I liked the moment I saw it. In particular, the forced '!' suffix makes macros stand out as something that might potentially introduce non-trivial control flow; for instance, the try! macro does an early-return of the containing function on failure. In C, putting control flow in a macro is generally considered poor form; in Rust, it becomes much more sensible precisely because of the macro naming convention.
- stormbrew 12y ago
  I'm not sure I agree with this. Or at least, I'm not sure I think this will hold true once macros are used for more than control flow mechanisms, which are approximately half of the uses of the macros in the stdlib right now as far as I can see. After all, most C style guidelines do insist on some way of differentiating macros, commonly making them all-caps, but it makes it no less sketchy to throw a return into a macro.
frowaway001 12y ago
+1. ! is the worst part of Rust macros. There is just a terrible mismatch between the use-case macros were originally intended for (embedding different languages) and how they are mainly used now (emulating varargs). The current arguments from Rust people are mainly defensive in that area, but maybe they will revisit this as the community matures.
- kibwen 12y ago
  > There is just a terrible mismatch between the use-case > macros were originally intended for (embedding > different languages) and how they are mainly used now > (emulating varargs). This is incorrect. I can't think of any macros that are used to paper over the lack varargs (`println!` certainly doesn't count, because even if Rust had varargs you'd still need a macro here to do typesafe compile-time string parsing). In any case, varargs can already be trivially emulated using vectors (which afaict is essentially what Go does, but Go has sugar for it). Macros would be overkill for this use case.
  - frowaway001 12y ago
    > This is incorrect. Eh ... did you have a look at the "standard" library? > `println!` certainly doesn't count, because even if Rust > had varargs you'd still need a macro here to do typesafe > compile-time string parsing Yeah, but you could do it without exposing all the horrible mess to users. The usual "OMG!!! Look at that random `!`. Stand back, I'm using a macro here and would like to warn you that semantics will be totally different!!!"-dance is just embarrassing, especially given the fact that you can design printf-like functionality without needing varargs in the first place. With or without macros, if your API requires warning signs it just sucks, and you should fix it instead of using "hey, but I warned people!" as an excuse. > varargs can already be trivially emulated using vectors Oh right! So how do we create a vector? vec![1, 2, 3, 4] Oh well ...
pornel 12y ago
I used to think so too, especially because very basic examples with `printf!()` look "odd", but I started to like it: it gives me confidence that regular function calls won't do anything bizarre. It's a warning that there's "magic" going on. It makes it clear that there's a lot of quirky compile-time type checking trickery behind printf, it tells that regex is going to be precompiled, etc.
malkia 12y ago
It was peculiar at first with me, but I think I like it now. Felt nearly the same way with "recur" in "clojure", instead of calling the function name recursively and pray the compiler would do the proper tail call optimization (elimination), but recur forces you to always get it right.

rayiner 12y ago

It makes me thing it signals mutation.

Dewie 12y ago
Because that's the convention in lisp?
- deleted 12y ago
  [deleted]
- zzalpha 12y ago
  Both Lisp and Ruby all follow that convention. Probably other languages, too, but I'm too lazy to look... :)
  - steveklabnik 12y ago
    In Ruby, it does _not_ mean mutation. It means 'danger.' Sometimes that's mutation, sometimes its other things, like throwing an exception rather than returning nil on error.
- rayiner 12y ago
  Technically, it's not the convention in Common Lisp, but rather Scheme and Dylan. But yes.

the_mitsuhiko 12y ago

> It makes macro invocation feel "wrong" or "special" in a subtle way and betrays a lack of confidence in the macro system But a macro invocation is special. The syntax within a macro does not follow Rust rules, so if macros would not be marked properly it would be incredibly confusing for a user. Let alone that macro imports are different by the very nature of their behavior.

eddyb 12y ago
Not to mention it would be difficult, if not impossible, to parse in the first place (the contents of a macro invocation are stored as token trees within macro AST nodes, within the regular AST).
kybernetikos 12y ago
I think that the 'call-by-name' behaviour in Scala is confusing, because you can write something that you think will execute once but actually, it might execute multiple times and there's no obvious marker that it's special. When you have something that is potentially major, you generally don't want it to be invisible.

AndyKelley 12y ago

Macro invocation is special. It's significantly more readable to know whether you're calling a function or invoking a macro.

kibwen 12y ago

Macros have a freeform syntax, with the only restriction being that delimiters within have to be balanced. I don't see how an IDE could provide general syntax highlighting for them.

whyever 12y ago
The IDE could parse the macro definition and highlight accordingly. (It would know where to expect an identifier and where to expect an expression etc.)
- steveklabnik 12y ago
  > (It would know where to expect an identifier and where to expect an expression etc.) But that doesn't mean that what's in the macro should be highlighted like Rust: sql!("SELECT * FROM users WHERE name = $1"); is a macro provided by https://github.com/sfackler/rust-postgres-macros https://github.com/sfackler/rust-postgres-macros , and should be highlighted like SQL, not like a Rust string. sql!("SELECT * FORM users WHERE name = $1"); throws an error, because it's malformed.

JoshTriplett 12y ago

That's actually a feature of Rust that I liked the moment I saw it. In particular, the forced '!' suffix makes macros stand out as something that might potentially introduce non-trivial control flow; for instance, the try! macro does an early-return of the containing function on failure. In C, putting control flow in a macro is generally considered poor form; in Rust, it becomes much more sensible precisely because of the macro naming convention.

stormbrew 12y ago
I'm not sure I agree with this. Or at least, I'm not sure I think this will hold true once macros are used for more than control flow mechanisms, which are approximately half of the uses of the macros in the stdlib right now as far as I can see. After all, most C style guidelines do insist on some way of differentiating macros, commonly making them all-caps, but it makes it no less sketchy to throw a return into a macro.

frowaway001 12y ago

+1. ! is the worst part of Rust macros. There is just a terrible mismatch between the use-case macros were originally intended for (embedding different languages) and how they are mainly used now (emulating varargs). The current arguments from Rust people are mainly defensive in that area, but maybe they will revisit this as the community matures.

kibwen 12y ago
> There is just a terrible mismatch between the use-case > macros were originally intended for (embedding > different languages) and how they are mainly used now > (emulating varargs). This is incorrect. I can't think of any macros that are used to paper over the lack varargs (`println!` certainly doesn't count, because even if Rust had varargs you'd still need a macro here to do typesafe compile-time string parsing). In any case, varargs can already be trivially emulated using vectors (which afaict is essentially what Go does, but Go has sugar for it). Macros would be overkill for this use case.
- frowaway001 12y ago
  > This is incorrect. Eh ... did you have a look at the "standard" library? > `println!` certainly doesn't count, because even if Rust > had varargs you'd still need a macro here to do typesafe > compile-time string parsing Yeah, but you could do it without exposing all the horrible mess to users. The usual "OMG!!! Look at that random `!`. Stand back, I'm using a macro here and would like to warn you that semantics will be totally different!!!"-dance is just embarrassing, especially given the fact that you can design printf-like functionality without needing varargs in the first place. With or without macros, if your API requires warning signs it just sucks, and you should fix it instead of using "hey, but I warned people!" as an excuse. > varargs can already be trivially emulated using vectors Oh right! So how do we create a vector? vec![1, 2, 3, 4] Oh well ...

pornel 12y ago

I used to think so too, especially because very basic examples with `printf!()` look "odd", but I started to like it: it gives me confidence that regular function calls won't do anything bizarre. It's a warning that there's "magic" going on. It makes it clear that there's a lot of quirky compile-time type checking trickery behind printf, it tells that regex is going to be precompiled, etc.

malkia 12y ago

It was peculiar at first with me, but I think I like it now. Felt nearly the same way with "recur" in "clojure", instead of calling the function name recursively and pray the compiler would do the proper tail call optimization (elimination), but recur forces you to always get it right.