On Fri, 2006-11-17 at 01:10 -0800, Erick Tryzelaar wrote: > Looks like there may be a bug with diamond includes. Consider this: > > file1.flx > #include <flx.flxh> > > print "file1"; endl; > val x = 1; > > file2.flx: > #include <flx.flxh> > #include "file1.flx" > > print "file2"; endl; > > > file3.flx: > #include <flx.flxh> > #include "file1.flx" > > print "file3"; endl; > > file4.flx: > #include <flx.flxh> > #include "file2.flx" > #include "file3.flx" > > print print "file4"; endl; > > > Is erroring out with this: > CLIENT ERROR > [build_tables] Duplicate non-function x<4621> > In ./file1.flx: line 4, cols 1 to 10 > 3: print "file1"; endl; > 4: val x = 1; > ********** > 5: <eof> > > See also ./file1.flx: line 4, cols 1 to 10 > 3: print "file1"; endl; > 4: val x = 1; > ********** > 5: <eof> >
This isn't an implementation bug, it's a design bug. The file is included twice, causing the error. Now here's the problem. Felix used to check, and only include a file once, globally. The problem is, #import MUST be done in every file that requires definitions. So there is a design problem here. On the one hand multiple inclusions at the global level are required for definitions, one in each file requiring to import them, and on the other hand token streams should typically only be included once globally. This cannot be fixed with guard macros .. because they're local to #included files: they're imported with #imported files. import is transitive, include is not. So you can actually stop multiple gratuitous imports, but not includes .. the reverse of what we want. So we need a design that works. The design concept was basically that 'in general' macros are local to the file they're defined in, they do not affect files included BY that file, nor do they affect files which include that file. The localisation guarantees the value of every conditional execution is lexically manifest, that is, visible in the physical file. However that excludes 'macro packages' .. so #import was invented. The preserves a modified guarantee -- the macros affecting a file are either directly manifest, or they're in the transitive closure of #imports. The key thing here is that user defined syntax and conditional compilation, etc, can't be hidden away in some hard to find place. In particular, in absence of #import, a file can be lexed entirely independently of its clients, and of the files of which it is a client. That is .. the lexicology is fully decoupled. With #import this rule is broken, a file using an imported file can depend on the imported file lexically and syntactically. In summary .. its a mess. I want clean decoupling, explicit interfaces, etc, even for #macro stuff. Maybe #macro packages should be entirely distinct kinds of files. -- John Skaller <skaller at users dot sf dot net> Felix, successor to C++: http://felix.sf.net ------------------------------------------------------------------------- Take Surveys. Earn Cash. Influence the Future of IT Join SourceForge.net's Techsay panel and you'll get the chance to share your opinions on IT & business topics through brief surveys - and earn cash http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV _______________________________________________ Felix-language mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/felix-language
