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.
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. > >> > >> >
