On Tue, 2016-08-16 at 09:00, Adrian Salceanu <[email protected]> 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. >> >>
