Fair enough, "just embed lisp" was a bit tounge-in-cheek. I suppose what I mean is that lisp macros, while powerful, don't need to add syntax that is jarringly different from other syntax (although they certainly can). I suppose I think that stuff like:

  fn parse_response<'a>(bytes: &'a [u8]) ->
    IResult<&'a [u8], TrackerResponse<'a>>
    {
      switch!(bytes, tuple!(be_u32, be_u32),
     (::CONNECT_ACTION_ID, tid) =>
       map!(be_u64, |cid|
         TrackerResponse::new(tid,
         ResponseType::Connect(cid))
      ) |  (...)

Appears to be very dense in very terse type and life-time information, compared to the variable names, function calls/macro expansions.

I get that it might be necessary at times, I just think it is a worthy goal to strive to make code look somewhat simple, even when doing complex things.

Example, in this case, with all the lifetimes(?) being the same(?) 'a, could perhaps the compiler infer that? Would it be more useful to make it explicit when they differ?

That kind of thing.

[ed: As or it being ironic, I see powerful constructs like macros more as a tool for making complex things simpler, not to complicate simple things.

That's what I mean when I say "macro-heavy" code being hard to read is ironic. It could of course be that this example really is complex, but it kind of strikes me as looking more "complected" than "complex".]

  > I just think it is a worthy goal to strive to make code
  > look somewhat simple,

To be clear, I do as well. Some things are just inherently complex, though.

  > could perhaps the compiler infer that? 

The only reason they're added here is that they're not able to be inferred, and the reason they're all the same is that you're explicitly connecting the lifetime of each of these things.

  > it kind of strikes me as looking more "complected" than "complex".

nom is for building extremely fast, extremely low-overhead parsers. When you're trying to do stuff like that, you can't always afford convenience stuff. Consider if you had to write all the code the macros generate by hand!

> The only reason they're added here is that they're not able to be inferred, and the reason they're all the same is that you're explicitly connecting the lifetime of each of these things.

Is the default of having them all be implicitly different, or unlinked, lifetimes very useful?

If you don't write anything at all, the "lifetime elision rules" kick in: http://doc.rust-lang.org/stable/book/lifetimes.html#lifetime...

We used to only have the first of those three rules. When we added the other two, almost 90% of lifetime annotations in function declarations were able to be removed from the compiler and standard library.