Why begin/end instead of { } for block delimiter

Internals & Design
21

Not the right thread for this…

but seems to me this isn’t a compiling issue, but rather before that, at typeinfer. Typeinfer is just a (mind-numbingly complicated) julia function, can’t it just evaluate some regular code now and again and append the results to the type parameters? Closer to the macro level than the compilation level I think but not sure.

22

Sure it could do that, but then compile times not only depend on the optimization level of the compiler, but also on the optimization level of every function you want to call while doing type inference on them. Which can potentially result in those functions needing type inference as well, suddenly resulting in a large increase in type inference time, which some people already complain about being too slow :person_shrugging:

I agree that this is not the right thread for yet another staticint/traits/better type system discussion, so let’s leave it at that :slight_smile:

23

Well, for those who think curly braces should be used to delimit blocks, I’ve made Curly.jl

using Curly

@let good_idea = missing msg="Is this a good idea?" {
    println(msg)
    @if good_idea === true {
        println("Yes!")
    } {
        println("Not really, no. I had fun writing it though.")
    }
}

Is this a good idea?
Not really, no. I had fun writing it though.
8 Likes
24

I sort of like that you did this… except people might use it. I can use it to shut up people that want a curly-braced language or complain Julia isn’t. Same as with LispSyntax.jl (and outdated PythonSyntax.jl), and APL.jl and JJ.jl for J.

I don’t really want anyone to use those, but with macros Julia is powerful enough that you can’t stop people doing this. Since the macros work on the syntax tree, can they be used to output equivalent Julia code? They’re not meant for that, so I’m not sure, maybe with some ENV to instruct the package to output Julia code?

I kind of want a C to Julia translator (for some things, also Julia-to-C for the restricted subset where that’s possible), and maybe this package could help with that (for a limited subset after some sed hacking).

1 Like
25

No, that’s exactly what macros are for - syntax transforms. Whether the transform is something you personally like is a different matter :person_shrugging:

3 Likes
26

Sorry, yes they are meant for syntax transforms, but then the “generated” code is just used. I meant macros are not meant (for a user) to output that code as text (and even keep comments), like a (C) preprocessor, or is that possible and I just don’t know it? How then?

I mean in a usable form I could just use, copy-paste verbatim, not same as/though similar to what this gets me:

julia> @code_lowered @fastmath 1+1
27

Well you can certainly output the code of the expression as a string object, but that’s not the same thing. The current parsers doesn’t emit anything about comments and there’s nothing keeping them in the pipeline, so no, you don’t get to keep comments. I wouldn’t want it to, since a macro transform on the expression parsed from that text doesn’t necessarily have a clear place to put the comment (that’s not relevant for the code itself anyway) in the transformed AST to.

They’re very intentionally not like the C preprocessor.

1 Like
28

Why are you using @code_lowered here though? I think you want to use @macroexpand.

julia> @macroexpand @let good_idea = missing msg="Is this a good idea?" {
           println(msg)
           @if good_idea === true {
               println("Yes!")
           } {
               println("Not really, no. I had fun writing it though.")
           }
       }
:(let good_idea = missing, msg = "Is this a good idea?"
      println(msg)
      if good_idea === true
          println("Yes!")
      else
          println("Not really, no. I had fun writing it though.")
      end
  end)
2 Likes