You might consider requiring that includes appear at the start of the file,
to avoid others getting bitten as well.
On Mon, Feb 18, 2013 at 5:50 PM, john skaller <skal...@users.sourceforge.net
> wrote:
> Oops. I got bitten so I'd better warn:
>
> When you include a file like this:
>
> println$ "Before";
> include "./myfile1";
> include "./myfile2";
> println "After";
>
> The output is:
>
> myfile2
> myfile1
> Before
> After
>
> That's not what I expected being too used to C #include. There's a reason
> of course.
>
> Felix automatically includes a file only once. This is so you can
> include a file safely if you need it, even if some other file you include
> also includes it.
>
> In that scenario, you cannot do stuff like this:
>
> class X { include "a"; }
> class Y { include "a"; }
>
> Given the option of including things from multiple places
> with automatic removal of duplications, its clear that you also
> cannot depend on the order of inclusion either. In fact
> inclusions can be mutually recursive. No problem!
>
> This is necessary in a library if you write two modules
> that depend on each other: each must include the other.
> For function definitions, this is just fine because of setwise lookup.
> So the order doesn't matter.
>
> So what Felix *actually* does is pack included files BEFORE
> the including file. So what you can rely on is that if you include
> a file any variables initialised in it will be initialised FIRST,
> before anything in the including file IF and ONLY IF the
> including file is not in a cycle with the included file.
>
> The rule is quite specific. Given a set of library files
> you can include them and depend on any variables in them
> being initialised. It doesn't matter where you write the include
> directive. The order of inclusion matters but you must not
> depend on it.
>
> If you're writing mutually dependent files you must NOT
> depend on the order of variable initialisation (if you
> need variables you must initialise them with functions).
>
> SO this is all logical but it is contrary to my "Good bits" claim that
> you can just throw code out into a file. You cant. You can only
> throw functions out into a file.
>
> A #include facility could be useful. Unfortunately Dypgen is not
> capable of recursion, and it provides no simple way to "stack"
> lexbufs. It has been pointed out to me it CAN be done by using
> a suitable supplier callback for the lexbuf though.
>
> [The moral of the story is: don't use global variables :]
>
> --
> john skaller
> skal...@users.sourceforge.net
> http://felix-lang.org
>
>
>
> --
> You received this message because you are subscribed to the Google Groups
> "Felix Language" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to felix-language+unsubscr...@googlegroups.com.
> To post to this group, send email to felix-langu...@googlegroups.com.
> Visit this group at http://groups.google.com/group/felix-language?hl=en.
> For more options, visit https://groups.google.com/groups/opt_out.
>
>
>
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_feb
_______________________________________________
Felix-language mailing list
Felix-language@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/felix-language
