On Fri, 2006-11-17 at 17:53 -0800, Erick Tryzelaar wrote: > 1. go to c-style guards and just export everything
Unfortunately this might be the best ;( > file1.flx > ////////////////////////////// > #ifndef __FILE1__ > #define __FILE1__ > > #local > macro val x = 1; > #endlocal .. just a note: this is a syntax macro, unrelated to preprocessor macros :) > 2. export only which files the source depends on > > Not sure if this would actually work. The basic idea is to have the > "file1.flx" to export only what's defined in the file, and nothing from > the files it imports/includes. This is the current situation if you #import file1, but file1 only #include other .. but this is ONLY macros, all of the tokens are streamed through. > 3. go the ocaml / camlp4 route with a AST preprocessor We already have precisely that: the syntax macros work directly on the AST. The problem is they can't parse -- they work on the already parsed code. The user syntax parser is part of the lexer. The ocamlp4 technique is probably right. But it means abandoning Ocamlyacc. The 'correct' way to do this in Felix is to use Felix GLR and dynamic loading to do the parsing .. in other words rewrite Felix in Felix .. :) > 4. explicitly export the interface > > this solves the difference between import and include. Mark everything > that's part of the file's public interface (or conversely, all the > private stuff), and only expose that stuff. I can't think of a really > good reason why in some cases you would want to "#import 'file1.flx'" > and in others "#include 'file1.flx'". Agree, I can't really either. The basic dichotomy is (a) macro packages (b) convenience splitting ordinary sources Felix standard library has (a) already flx_syntax.flxh flx_platform.flxh define user defined syntax and some configuration dependent macros with OS version information. In both cases we want to export the symbols, and in the second we really do want a separate file so it is easy to switch to another file for a different platform. The use of the file system here is mainly related to configuration, conditional compilation, and user customisation. I'm sure there are better ways, and indeed Felix implements some of them, such as the 'requires' facility, syntax macros, guaranteed constant folding so ordinary conditionals can be used for conditional compilation, etc. But the raw C style of doing this provides a fallback with known properties .. and that fallback is sometimes needed, if only to bootstrap the other features. > 5. explicitly import what we want > > Just the inverse of the previous example. Say we swaped requires for > import/include, we could specify adjectives to the requiring. So, we > could have "requires 'file1.flx'", "requires public 'file1.flx'", > "requires macro 'file1.flx'", and "requires syntax 'file1.flx'" and etc. importing by category like this doesn't really seem to make sense: the purpose of a file is manifest in the file itself, IMHO. > 6. make standard library implicitly imported Yeah, I will look at this again. At present, something like flxg --include=file --include=file ... or simply flxg file file file file which concatenated all those files would be possible. > A lot of the complication seems to be coming from the necessity to > #import flx.flxh, because we want all of that (for the most part) to be > exposed to the importer. On the flip side, we may not want macros to > exported by default. So, we could switch to importing flx.flxh by > default, and allowing the standard syntax extensions to be inlined by > default, as opposed to the user ones which require something special to > turn on. The thing is we want some parts of Felix to be implemented in a library, and we want end users to be able to create alternate libraries. The real issue here is the relation of Felix to file systems -- not the ability to extend it with meta-programming codes within files. > 7. split up everything > > We copy ocaml. We have the camlp4 syntax enhancement file, interface and > implementation files and only allow macros in implementation and syntax > enhancement files. First, this requires separate compilation facility. That has been on the plate for several years. It's one way to speed up the compiler .. pre-compiling libraries so the extremely slow 'lookup' phase of the compiler is skipped. Basically .. run everything, including the inliner, then Mashall the data structures out to cache file. Unfortunately non-trivial. Also one might argue actually going ALL the way .. to an actual binary shared library .. is more important. Secondly, I very specifically removed the need for separate interfaces. In scripting level languages they would be an extreme pain: they're quite annoying in Ocaml too, and in C++ they're a nightmare. Eiffel does this too. There is an interface -- but it is created by the system NOT specified by the user. > Are there any other options that don't require dropping features? Very hard to say. Dropping features isn't the problem: really the issue is "what role should the file system play in a programming language"? It isn't trivial. In my view things like syntax extensions have to be scoped too. The 'natural' scope of something that plays with syntax is the file of definition only, but that requires duplicating definitions. One would like it to work like modules: you enable an extension by explicitly importing it. The problem is modules themselves have to be parsed, and by the time the compiler has enough information to understand module like scopes .. it is too late to enable syntax extensions (parsing is already done). The file system provides an 'already parsed' scoping mechanism it is tempting to leverage. Really, a multi-stage compilation model would be better -- you define syntax extension IN FELIX and use them to create an augmented compiler which processes the next stage -- like Meta-Ocaml with Ocamlp4 merged in..:) The ultimate answer is that linear languages are screwed. interactive development with associative learning, using theta wave sensors for direct cyber-organic brain connection is the future .. in 100 years maybe :) -- 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
