RE: include paths
-------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
|
Not Categorized, Please Help
|
|