1. RE: include paths
- Posted by bensler at mail.com
Mar 17, 2002
I've mentioned the same thing a few times before, to no avail.
There is no way to use any form of equation to define an include.
You can have dynamic includes by calling your includes from a secondary
include file that was generated on the fly.
pseudo-code:
open include2.e for writing
add the include lines, using the custom path
close include2.e
include include2.e
Chris
gwalters at sc.rr.com wrote:
> Is there a way to use a variable as an argument of an include statement.
> It
> seems a little restricteive to have to hard code an absolute path or
> accept
> the default search relative path of EU.
>
> I would like to do something like
>
> Path = getenv("EUDIR") &"/MyInclude/stuff.e"
>
> include Path
>
> george
>
>
2. RE: include paths
- Posted by bensler at mail.com
Mar 17, 2002
On the fly includes is the only way I know of.
This one in particular has bugged me since about 1 week after I tried EU
for the 1st time.
I've offered multiple solutions that Rob could implement, but I don't
think he ever responded.
I don't understand why relative path support isn't already implemented.
It doesn't solve the entire dilemna, but it would certainly help, and
isn't detrimental to the language or syntax that I can see.
A complete solution requires more consideration, but there are a number
of possible implementations I can think of.
The best complete solution I can come up with, is to allow variables in
'include' definitions. Where the definition MUST equate to a string.
Hardcoded definitons would still be allowed
The only problem I see with this implementation, is the possibility for
conflicts between hardcoded include definitions, and dynamically defined
includes.
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
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.
Can anyone see any problems with this implementation?
Has there been any consideration for something like this Rob?
While I'm thinking of improvements for EU...
I remember David Cuny mentioning the inconvenience of comma separators.
EU already ignores commas. Why not allow a leading comma?
A trailing comma wouldn't work, because EU wouldn't be able to determine
when a list of constants or variables has closed. But a leading comma
can be ignored without any reprocussion. It's also dead simple to
incorporate into the language.
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.
Another one that has been mentioned before, but perhaps wasn't heard the
other times, so I'll say it again...
Assignment on declaration.
All of these suggestions provide no detriment to the existing language.
They are just conveniences, but for that matter, so is a 'for' loop.
I know EU can do what I want in these circumstances, but why would I
take a half hour to drive to the grocery store and buy a pack of gum,
when I can walk to the convenience store in 5 mins?
Rob, I would HIGHLY suggest making a list of the requests that people
have made, and your responses to them.
I know at least 2 of these 3 things has been directly addressed before.
This would also give people an indication of your intentions, and a
guide for new suggestions, instead of people repeating the same things
over again.
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
Chris
gwalters at sc.rr.com wrote:
> Chris, did you ever get a response on a solution?
>
> the problem I'm trying to solve is that of having a development lib and
> a
> production lib. I don't want to mix and dork up production programs with
> new
> development programs. as well as keep my stuff separate from EU stuff
> w/o
> having to change hardcoded paths.
>
> george
> ----- Original Message -----
> From: <bensler at mail.com>
> To: "EUforum" <EUforum at topica.com>
> Sent: Sunday, March 17, 2002 10:56 AM
> Subject: RE: include paths
>
>
> > I've mentioned the same thing a few times before, to no avail.
> > There is no way to use any form of equation to define an include.
> >
> > You can have dynamic includes by calling your includes from a secondary
> > include file that was generated on the fly.
> >
> > pseudo-code:
> > open include2.e for writing
> > add the include lines, using the custom path
> > close include2.e
> >
> > include include2.e
> >
> >
> > Chris
> >
> >
> > gwalters at sc.rr.com wrote:
> > > Is there a way to use a variable as an argument of an include statement.
> > > It
> > > seems a little restricteive to have to hard code an absolute path or
> > > accept
> > > the default search relative path of EU.
> > >
> > > I would like to do something like
> > >
> > > Path = getenv("EUDIR") &"/MyInclude/stuff.e"
> > >
> > > include Path
> > >
> > > george
> > >
> > >
3. RE: include paths
- Posted by bensler at mail.com
Mar 17, 2002
How do you change %EUINC% on the fly?
a batch file?
Chris
Robert Craig wrote:
> George Walters writes:
> > the problem I'm trying to solve is that of having a development lib and
> > a
> > production lib. I don't want to mix and dork up production programs with
> > new
> > development programs. as well as keep my stuff separate from EU stuff
> > w/o
> > having to change hardcoded paths.
>
> In Euphoria 2.3, you can define a new environment variable,
> called EUINC. You can set EUINC to a list of directories
> that Euphoria will search for included files. e.g.
>
> SET EUINC=C:\MYDEVELOPMENTLIB;C:\EUSTUFF\WIN32LIB
>
> Euphoria will search first in the same directory as
> the main .exw or .ex file, then it will search the directories
> listed in EUINC (left to right),
> then it will search your euphoria\include directory.
>
> I have a separate directory in EUINC for Win32lib.ew and friends
> for example. That way I don't have to mix them in with euphoria\include.
> If I want to try a new release of Win32Lib, I can change my EUINC
> to list the new release first. Later I can rename that new directory,
> or remove it from EUINC, and go back to using the original Win32Lib.
>
> Regards,
> Rob Craig
> Rapid Deployment Software
> http://www.RapidEuphoria.com
>
>
4. RE: include paths
On 17 Mar 2002, at 18:32, bensler at mail.com wrote:
<snip>
> 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.
Since you put it that way....
1) In my opinion, nearly anything done for compiling, to make life easier on
the programmer, is a plus for Eu.
2) Nearly anything done as a first-pass in the interpreter is equally a Good
Thing.
3) Language options that add to versatility are also a Good Thing. This
includes goto, classes, pointers, and some way to beat the 4-byte-per-
character thing. ("The english language is versatile, but rap music mangles it
so badly, i think it should be forbidden!"? "German is a fine language, but
Hitler used it for a Bad Thing, so it should be illegal too!"?) Of course, this
may mean a away to nameless assigns-while-declaring, like:
type sequence = x = repeat(type sequence={},500)
4) smart optimising is a Good Thing, even pulling in different code for the
same high-level keyword, as appropriate.
But as for include paths, have you tried the ole dos "subst"? Oops, can't do
neat things like that in windoze or *nix. I had inordinately long paths to some
files back in my pascal days, and would subst drive letters for them.
"E:\DCTDATA\DCTWORK\TESTCTRL.H13\084-KN.N13" would become
"X:\084-KN.N13"
Kat
5. 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
6. RE: include paths
- Posted by bensler at mail.com
Mar 17, 2002
> >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?
EG.
include .\libs\mylib.e
-- only search for mylib.e in libs\, which exists in the current
directory.
I could then ship ExoticaX with the library files in their own
directory, separating them from the examples.
> 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.
I am of the same mindset. While I like the conveniences, they aren't
priorities, and generally cause more clutter and loss of productivity
than they are worth. I have chosen those 2 as examples of, like you
said, "dead simple" features that could be implemented, and don't
detriment the simplicity and readability of the language.
Each of those features I mentioned, I have implemented in my current
version of EUPP. Along with vertical slicing, function slicing, OOP
style conversion (works with my custom OOP lib, and with objecteu),
namespacing (obsolete now), s[0] equates to length(s) (s[1-1] doesn't).
It will also rearrange code so that definitions appear at the top of
routine blocks. I was working on adding eval(), but that requires
writing an interpreter on top of my parser. I'd still like ot do that
one.
>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.
>
Keep up the good work Karl. I only wish I had the knowledge to be able
to implement my wishes into EU.
I think your syntax for dynamic inclusion is over complicated.
The form that I recommended cleary differentiates between an absolute
definition, and a dynamic definiton. There is no need to mingle the two
forms. In fact, there is no need for the original form, except backwards
compatability.
using my syntax, you would have
include( home &"\\src\\"& fname )
Chris
7. RE: include paths
-------Phoenix-Boundary-07081998-
You wrote on 3/17/02 10:44:12 PM:
>
>include .\libs\mylib.e
>-- only search for mylib.e in libs\, which exists in the current
>directory.
>
It never occurred to me that that wouldn't work! Straight-forward
though (14 lines of code - accepts '.\' '..\' '...\' etc.)
>Each of those features I mentioned, I have implemented in my current
>version of EUPP. Along with vertical slicing, function slicing, OOP
>style conversion (works with my custom OOP lib, and with objecteu),
>namespacing (obsolete now), s[0] equates to length(s) (s[1-1] doesn't).
>It will also rearrange code so that definitions appear at the top of
>routine blocks. I was working on adding eval(), but that requires
>writing an interpreter on top of my parser. I'd still like ot do that
>one.
>
>I think your syntax for dynamic inclusion is over complicated.
I like it because enclosing each variable in parens makes it
clear which parts of the line are not just text. Kind of like
macros in make.
Its' rarely used, so the syntax is comparitively unimportant,
and the bottom line is that it seemed to require a minimum
of changes to the existing code.
The ?final? improvement is to allow '<get.e>' to search EUDIR first
(like C).
Karl Bochert
-------Phoenix-Boundary-07081998---
8. RE: include paths
- Posted by bensler at mail.com
Mar 18, 2002
> >I think your syntax for dynamic inclusion is over complicated.
>
> I like it because enclosing each variable in parens makes it
> clear which parts of the line are not just text. Kind of like
> macros in make.
> Its' rarely used, so the syntax is comparitively unimportant,
> and the bottom line is that it seemed to require a minimum
> of changes to the existing code.
Using your version, you've added a new syntax to EU.
At first glance your syntax looks like it could be 2 statements on the
same line.
How do you figure that it would be rarely used?
I could see myself using it constantly.
EG.
dir listing:
.
..
debug\
distr\
myfile.e
<myfile.e>
constant DEBUG=1
sequence inc_path
if DEBUG then inc_path="debug\"
else inc_path="distr\"
end if
include( inc_path&"mylib.e" )
<end myfile.e>
As much as I applaud your efforts Karl, my hope is that maybe we can
convince Rob that some of these 'features' are feasible and worthy
improvements for EU. My train of thought focuses on long term, final
solutions. I personally don't care about the syntax, yours would work
just fine, but it breaks from the EU mold.
Chris
9. RE: include paths
-------Phoenix-Boundary-07081998-
You wrote on 3/18/02 11:30:08 AM:
>How do you figure that it would be rarely used?
I figured once per file, or at most a few times on
consecutive lines. (and almost never by me 
)
Karl Bochert
-------Phoenix-Boundary-07081998---
10. RE: include paths
bensler at mail.com wrote:
> This is what my EUINC var currently looks like, after one day of setting
>
> up my EU environment..
>
> EUINC=c:\euphoria\include\w320551;c:\euphoria\include\eX17;c:\euphoria\include\mylibs
>
Chris:
Why don't you do this:
set INC0=%EUDIR%\include\
set INC1=%INC0%w320551
set INC2=%INC0%eX17
set LIB1=%INC0%mylibs
set EUINC=%INC0%;%INC1%;%INC2%;%LIB1%
Bernie
11. RE: include paths
- Posted by bensler at mail.com
Jan 09, 2002
Thanks Bernie,
I know I can make due with the EUINC variable, it definitely makes a
difference. My point is, how much harder, or complex would it be to
implement the include path recursion into EU?
First of all, in order to fully implement EUINC into my windows
environment, requires a restart, otherwise, the modified EUINC var, is
only available to the program that set it. That works well for what I
was describing before, about setting the EUINC path from within an
unbound application.
I'm just guessing, but I think I CAN permanently modify the environment
variables, using windows calls, but that's beyond me.
Using eu's set_env(), is through DOS, which makes it only temporary,
because a dos box has it's own environment, seperate from the windows
environment, from what I understand.
Also, how long can an environment string be?
I'm in the process of hoarding all the RDS archives, I'd like to be able
to have a folder for each significant category if not for every indivual
library/API.
Personally, this is what I would like to have.
The includes folder, is strictly RDS libs.
Subdirectories contain the various API libs.
The EUINC var is reserved for dynamic inclusion from within an
application, and for including any libraries not contained in the
includes folder.
Make sense?
In all honesty, I can see some problems with general recursion of the
eu\include directory. Filename conflicts come to mind..
I don't know how it should be implemented, but I definitely think that
the current method of EU includes, needs to be overhauled. The EUINC var
makes life easier, but there are still some major limitations to how you
can use the include statement.
Take this example..
My Project Folder:
myapp.exw -- include /API/extlib.ew
customlib.ew
API:
extlib.ew -- include ../customlib.ew
This would keep my project fully contained, allowing me to move the
folder without modification of the source code.
As far as I know this is not possible with the current method of
includes. I need to specify absolutely, where customlib.ew is.
I can probably think of more reasons, given more time, and this post is
long enough:P
Chris
Bernie Ryan wrote:
>
> bensler at mail.com wrote:
> > This is what my EUINC var currently looks like, after one day of setting
> >
> >
> > up my EU environment..
> >
> > EUINC=c:\euphoria\include\w320551;c:\euphoria\include\eX17;c:\euphoria\include\mylibs
> >
> >
> Chris:
>
> Why don't you do this:
>
> set INC0=%EUDIR%\include\
> set INC1=%INC0%w320551
> set INC2=%INC0%eX17
> set LIB1=%INC0%mylibs
>
> set EUINC=%INC0%;%INC1%;%INC2%;%LIB1%
>
> Bernie
>
>
