Thanks, this makes sense. Just for clarification: > It strongly depend on what you want to do and whether you care about what > they represent. >
I want to apply transformations (mostly) to algebraic expressions and function calls in order to simplify them, replace argument names, find derivatives, etc. Thus I don't really care about the difference between GlobalRef and dot notation as long as they contain the same amount of information and I can evaluate them to actual function objects. But since there's a choice between 2 options I was trying to understand which one is more suitable for me and whether I can cast one to another (again, in the context of my simple transformations). Now based on what you've told about optimization and `Base.uncompressed_ast()` I believe these 2 options - GloablRef and dot notation - are interchangeable for my use case. > The devdoc should have fairly complete description of what these nodes > are. > What they are - yes, but not when to use which one. Anyway, I didn't intend to abuse anyone, just tried to get my head around AST internals. > > >> >> >> >> On Monday, August 8, 2016 at 1:55:51 AM UTC+3, Yichao Yu wrote: >>> >>> >>> >>> On Mon, Aug 8, 2016 at 3:57 AM, Andrei Zh <[email protected]> wrote: >>> >>>> While parsing Julia expressions, I noticed that sometimes calls to >>>> >>> >>> This shouldn't happen. >>> >>> >>>> global functions resolve to `GloablRef` and sometimes to >>>> >>> >>> and GlobalRef should only happen during lowering. >>> >>> >>>> getfield(Module, func). Could somebody please clarify: >>>> >>>> 1. Why do we need both? >>>> >>> >>> GlobalRef is essentially an optimization. It's more restricted and >>> easier to interpret/codegen and is emitted by lowering/type inference when >>> it is legal to do so. >>> >>> >>>> 2. Is it safe to replace one by the other (assuming only modules and >>>> functions are involved)? >>>> >>> >>> Not always. There are certainly cases where a GlobalRef currently can't >>> be used (method definition for example) I'm not sure if there's cases the >>> other way around. >>> >>> >
