RE: include paths
- Posted by kbochert at ix.netcom.com Mar 17, 2002
- 368 views
-------Phoenix-Boundary-07081998- You wrote on 3/17/02 10:32:00 AM: >A solution to the second problem, is to have a different form of include >syntax. The original syntax would still be valid, but a dynamic >definition would require enclosing braces. > >IE >include c:\\dev_libs\\mylib.e -- original syntax > >constant lib_path="c:\\dev_libs\\" >include( lib_path&"mylib.e" ) -- dynamic syntax > >include( 12*14/etc+blah ) -- fails, string expected I implemented this easily (with a slightly different syntax). >The complete solution would also incorporate relative paths. It just >seems odd not to have them. It's the same as the syntax we have now, but >using relative path notation. Example? > >IE. >constant > ,one=1 > ,two=2 > ,three=3 > ,etc=etc > >You could then add/remove any item from the list without extra >modification. > >This would apply to constants, variable defines and routine parameters. > Also dead simple. > >Assignment on declaration. > One of my favorites. > >If anyone else agrees with this stuff, speak up or forever hold your >peace. I can make endless suggestions, but Rob is not going to do >anything solely on my recommendations. > >If I'm off base on any of these things, just tell me to shut up :P > I agree whole-heartedly that a language should have convenience features. On the other hand, a language like Perl includes so many 'conveniences' that it becomes write-only. Already, the few changes I have made allows code like: ----------- constant ,home = "E:" ,fname = "foo.txt" include (home) \src\ (fname) function foo (,sequence s) sequence ,t = "abc" ,u = append (t, s[2..]) .. end function ---------- While I like it, it does begin to look like a different language. For what it's worth, I have attached is my enhancement list from the middle of last year. Karl Bochert -------Phoenix-Boundary-07081998- Content-type: application/octet-stream; Name=enhancements