On Tue, 2016-08-16 at 10:29, Adrian Salceanu <[email protected]> wrote: > Oh, I see - I thought "global" meant "not explicitly enclosed in a module". > But then yes, I get your point since that's automatically included in > "Main" which is just a module like any other.
Maybe have another read of http://docs.julialang.org/en/release-0.4/manual/variables-and-scoping/ which was overhauled half a year ago. > marți, 16 august 2016, 10:18:57 UTC+2, Mauro a scris: >> >> On Tue, 2016-08-16 at 09:00, Adrian Salceanu <[email protected] >> <javascript:>> wrote: >> > Yichao, many thanks for taking so much time to help me through this, >> that's >> > very kind. >> > >> >> It has nothing to do with "compiling" a module. I'm just saying it's >> not >> > the right API. >> > I understand your point now, it makes sense. >> > >> > >> > would that still be in the global scope? >> >> >> > >> >> Yes. >> > Bummer! Then it appears that despite reading all the books on Julia and >> the >> > docs a few times, I still don't have a good understanding of how things >> > should be approached. I expected that if I shove variables inside >> modules >> > and functions and sprinkle a good measure of type annotations and >> "const" >> > I'll be 80% good. >> > >> >> You can see what the expression object is with >> > Yes, I was thinking about the same approach, thanks. >> > >> >> It's always global scope, if that's what you mean by OK. >> > Yes, that's what I meant - and I was hoping it would not be. I still >> don't >> > get this: if in the middle of the parsing function I output >> > "current_module()" and I get "Render", why is it global? >> >> Just checking: Are you aware that each module has its own global scope? >> I.e. the top-level scope of each module is "global" (but separate from >> the "global" scope of other modules). >> >> > Thanks >> > Adrian, more confused about Julia than ever before >> > >> > >> > marți, 16 august 2016, 01:19:14 UTC+2, Yichao Yu a scris: >> >> >> >> >> >> >> >> On Tue, Aug 16, 2016 at 4:37 AM, Adrian Salceanu <[email protected] >> >> <javascript:>> wrote: >> >> >> >>> >> >>> I was thinking about having the module itself defined in the >> controller >> >>> for example (or some other standalone .jl source file), completely >> outside >> >>> the templating engine itself, and then referencing the variables >> defined >> >>> within this module. Are you saying that in this case, the module >> itself >> >>> would not be compiled? >> >>> >> >> >> >> >> >> It has nothing to do with "compiling" a module. I'm just saying it's >> not >> >> the right API. A sane interface should allow the user to pass in >> parameters >> >> as arguments. Using a single module like this will also block any kind >> of >> >> concurrency since calling the template with different parameters will >> >> either be impossible or have to modify globals. >> >> >> >> > In the module, and `include_string()` reference those globals. >> >>> >> >>> If I have >> >>> >> >>> module TplVars >> >>> const var1 = "foo" >> >>> const var2 = "bar" >> >>> const var3 = 42 >> >>> end >> >>> >> >>> and then from the template file I reference them >> >>> >> >>> ejl""" >> >>> <html>... >> >>> <p> >> >>> $(TplVars.var1) >> >>> </p> >> >>> </html> >> >>> """ >> >>> >> >>> would that still be in the global scope? >> >>> >> >> >> >> Yes. >> >> >> >> > How would I know that "lang" is the name of one of the vars, without >> >> rolling my own julia-like parser? >> >> >> >> (At template compilation time) Parse the expression using the julia >> >> parser, iterate through the result object, check if the type of >> expression >> >> is supported and pull out the external references. >> >> >> >> You can see what the expression object is with >> >> >> >> ``` >> >> julia> dump(:(lang == "en")) >> >> Expr >> >> head: Symbol call >> >> args: Array{Any}((3,)) >> >> 1: Symbol == >> >> 2: Symbol lang >> >> 3: String "en" >> >> typ: Any >> >> ``` >> >> >> >> FWIW, what you want to implement is a julia-like parser anyway. >> >> >> >> > Right. So if I execute "eval()" and "include_string()" within a >> module >> >> other than Main (currently doing this into a dedicated Render module) >> would >> >> that be ok? >> >> >> >> It's always global scope, if that's what you mean by OK. >> >> >> >> >>
