1. Another EU 2.5 suggestion...
I would like to be able to set the value of a variable like this:
integer
some_extremly_long_variable_name=82,another_extremly_long_variable_name=45
Instead of:
integer
some_extremly_long_variable_name,another_extremly_long_variable_name
some_extremly_long_variable_name=82
another_extremly_long_variable_name=45
This would be much easeyer, especilly with long variable names.
This is already used in constants, so why not with regular variables?
And I would also REALLY like my other suggestions included:
"eval()" commands/crash callbacks/ect. for Euphoria 2.5?
Some of the following is missing from Euphoria and would be very
helpful to me and many other programmers. I would like to see this in
Eu 2.5. Please take these into consideration.
"eval()" commands:
I would really like to see a way to do an "eval()" type command.
Many other languages have something like this.
eval(sequence eval_commands,integer global_type,integer crash)
eval_commands is a sequence of commands
global_type is:
0-No routines/varibles (even global) exist in main program
1-Only routines/varibles declared as global exist in main program
2-All routines/varibles exist in main program
if crash is true, if it encounters an error (like 1/0) than the
program dies with (or a crash routine, see below) ex.err, otherwise, it
returns an error
code(like 5 for divide by 0,see below)
Example:
integer a,global_type
sequence eval_commands
eval_commands="
include incl_file.e--should allow including(This could be used
--instead of complex "dynamic includeing" libraries)
if a then
?a
end if"
a=7
var_type=1
?eval(eval_commands,global_type,0)
Displays:
7(value of a)
0(eval encountered no errors)
____________________________________________________________
Crash callback
A way to setup a callback function would allow programs to save user
data before exiting
with ex.err
set_crash(integer routine_id)
routine_id is the routine id of the function
it calls the function with an error code(like 5 for divide by 0),
a sequence with info about the error(like a line #, invalid subscript,
ect.)
and a text string with the complete text error message(
"test.ex:3
attempt to divide by 0")
if the function returns -1, ignore the error
Example:
function oncrash(integer err_code,sequence info,sequence msg)
if err_code=34 then--this error can be ignored in this program
return -1
end if
save_all_important_data()
return 0
end function
set_crash(routine_id("oncrash"))
_________________________________________________
2. Re: Another EU 2.5 suggestion...
- Posted by akusaya at gmx.net
Jan 25, 2004
After reading many posts about the eval() function, I want to post my
opinion, that eval() will not be suitable for euphoria, because
euphoria can be translated and compiled, not just interpreted. Eval()
needs interpreter. So I think there will never be an eval() function
in euphoria.
However I really want a method to set and detect unassigned value in
euphoria. This function
constant ERROR = -1
function generate_random()
-- generate a random number
if (success) then
return the_number
else
return ERROR -- failed to generate
end if
end function
procedure main()
object x x = generate_random()
if x = ERROR then
puts(1, "error occured")
end if
end procedure
would be able to be replaced by:
function generate_random()
-- generate a random number
if (success) then
return the_number
else
return no_value() -- failed to generate
^^^^^^^^^
built-in function that returns unassigned
end if
end function
procedure main()
object x x = generate_random()
if unassigned(x) then
puts(1, "error occured")
end if
end procedure
For a function that returns all possible value it will be very useful
to differentiate special return value.
C> I would like to be able to set the value of a variable like this:
C> integer
C> some_extremly_long_variable_name=82,another_extremly_long_variable_name=45
C> Instead of:
C> integer
C> some_extremly_long_variable_name,another_extremly_long_variable_name
C> some_extremly_long_variable_name=82
C> another_extremly_long_variable_name=45
C> This would be much easeyer, especilly with long variable names.
C> This is already used in constants, so why not with regular variables?
C> And I would also REALLY like my other suggestions included:
C> "eval()" commands/crash callbacks/ect. for Euphoria 2.5?
C> Some of the following is missing from Euphoria and would be very
C> helpful to me and many other programmers. I would like to see this in
C> Eu 2.5. Please take these into consideration.
C> "eval()" commands:
C> I would really like to see a way to do an "eval()" type command.
C> Many other languages have something like this.
C> eval(sequence eval_commands,integer global_type,integer crash)
C> eval_commands is a sequence of commands
C> global_type is:
C> 0-No routines/varibles (even global) exist in main program
C> 1-Only routines/varibles declared as global exist in main program
C> 2-All routines/varibles exist in main program
C> if crash is true, if it encounters an error (like 1/0) than the
C> program dies with (or a crash routine, see below) ex.err, otherwise, it
C> returns an error
C> code(like 5 for divide by 0,see below)
C> Example:
C> integer a,global_type
C> sequence eval_commands
C> eval_commands="
C> include incl_file.e--should allow including(This could be used
C> --instead of complex "dynamic includeing" libraries)
C> if a then
C> ?a
C> end if"
C> a=7
C> var_type=1
C> ?eval(eval_commands,global_type,0)
C> Displays:
C> 7(value of a)
C> 0(eval encountered no errors)
C> ____________________________________________________________
C> Crash callback
C> A way to setup a callback function would allow programs to save user
C> data before exiting
C> with ex.err
C> set_crash(integer routine_id)
C> routine_id is the routine id of the function
C> it calls the function with an error code(like 5 for divide by 0),
C> a sequence with info about the error(like a line #, invalid subscript,
C> ect.)
C> and a text string with the complete text error message(
C> "test.ex:3
C> attempt to divide by 0")
C> if the function returns -1, ignore the error
C> Example:
C> function oncrash(integer err_code,sequence info,sequence msg)
C> if err_code=34 then--this error can be ignored in this program
C> return -1
C> end if
C> save_all_important_data()
C> return 0
C> end function
C> set_crash(routine_id("oncrash"))
C> _________________________________________________
C> TOPICA - Start your own email discussion group. FREE!
3. Re: Another EU 2.5 suggestion...
Sometimes I need to return an error code, but my function can return any
value, such in the case of a random generator. In this case I use NAN. NAN
means Not A Number and is used in C often. It's basically equal to the
opposite of zero, which is obviously not a real number.
constant -- taken from another post
POS_INF = 1.8e+307 * 10,
NEG_INF = -POS_INF,
NAN = -(POS_INF+NEG_INF)
function rand_num()
-- generate a random number
if (success) then
return rand_number
else
return NAN
end if
end function
procedure test_rand()
atom num
num = rand_num()
if num = NAN then
-- ERROR
end if
end procedure
----- Original Message -----
From: "aku saya" <akusaya at gmx.net>
To: <EUforum at topica.com>
Sent: Sunday, January 25, 2004 1:06 AM
Subject: Re: Another EU 2.5 suggestion...
>
>
> After reading many posts about the eval() function, I want to post my
> opinion, that eval() will not be suitable for euphoria, because
> euphoria can be translated and compiled, not just interpreted. Eval()
> needs interpreter. So I think there will never be an eval() function
> in euphoria.
>
> However I really want a method to set and detect unassigned value in
> euphoria. This function
>
> constant ERROR = -1
>
> function generate_random()
> -- generate a random number
> if (success) then
> return the_number
> else
> return ERROR -- failed to generate
> end if
> end function
>
> procedure main()
> object x x = generate_random()
> if x = ERROR then
> puts(1, "error occured")
> end if
> end procedure
>
> would be able to be replaced by:
>
> function generate_random()
> -- generate a random number
> if (success) then
> return the_number
> else
> return no_value() -- failed to generate
> ^^^^^^^^^
> built-in function that returns unassigned
> end if
> end function
>
> procedure main()
> object x x = generate_random()
> if unassigned(x) then
> puts(1, "error occured")
> end if
> end procedure
>
> For a function that returns all possible value it will be very useful
> to differentiate special return value.
>
>
> C> I would like to be able to set the value of a variable like this:
> C> integer
> C>
some_extremly_long_variable_name=82,another_extremly_long_variable_name=45
>
> C> Instead of:
> C> integer
> C> some_extremly_long_variable_name,another_extremly_long_variable_name
> C> some_extremly_long_variable_name=82
> C> another_extremly_long_variable_name=45
>
> C> This would be much easeyer, especilly with long variable names.
> C> This is already used in constants, so why not with regular variables?
>
> C> And I would also REALLY like my other suggestions included:
>
> C> "eval()" commands/crash callbacks/ect. for Euphoria 2.5?
>
> C> Some of the following is missing from Euphoria and would be very
> C> helpful to me and many other programmers. I would like to see this in
> C> Eu 2.5. Please take these into consideration.
>
>
> C> "eval()" commands:
> C> I would really like to see a way to do an "eval()" type command.
> C> Many other languages have something like this.
>
> C> eval(sequence eval_commands,integer global_type,integer crash)
> C> eval_commands is a sequence of commands
> C> global_type is:
> C> 0-No routines/varibles (even global) exist in main program
> C> 1-Only routines/varibles declared as global exist in main program
> C> 2-All routines/varibles exist in main program
>
> C> if crash is true, if it encounters an error (like 1/0) than the
> C> program dies with (or a crash routine, see below) ex.err, otherwise, it
> C> returns an error
> C> code(like 5 for divide by 0,see below)
>
>
> C> Example:
> C> integer a,global_type
> C> sequence eval_commands
>
> C> eval_commands="
> C> include incl_file.e--should allow including(This could be used
> C> --instead of complex "dynamic includeing" libraries)
> C> if a then
> C> ?a
> C> end if"
>
> C> a=7
> C> var_type=1
>
> C> ?eval(eval_commands,global_type,0)
> C> Displays:
> C> 7(value of a)
> C> 0(eval encountered no errors)
>
> C> ____________________________________________________________
> C> Crash callback
> C> A way to setup a callback function would allow programs to save user
> C> data before exiting
> C> with ex.err
>
> C> set_crash(integer routine_id)
> C> routine_id is the routine id of the function
> C> it calls the function with an error code(like 5 for divide by 0),
> C> a sequence with info about the error(like a line #, invalid subscript,
> C> ect.)
> C> and a text string with the complete text error message(
> C> "test.ex:3
> C> attempt to divide by 0")
>
> C> if the function returns -1, ignore the error
>
> C> Example:
> C> function oncrash(integer err_code,sequence info,sequence msg)
> C> if err_code=34 then--this error can be ignored in this program
> C> return -1
> C> end if
> C> save_all_important_data()
> C> return 0
> C> end function
> C> set_crash(routine_id("oncrash"))
>
> C> _________________________________________________
>
>
> C> TOPICA - Start your own email discussion group. FREE!
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
4. Re: Another EU 2.5 suggestion...
aku saya wrote:
>
>
>After reading many posts about the eval() function, I want to post my
>opinion, that eval() will not be suitable for euphoria, because
>euphoria can be translated and compiled, not just interpreted. Eval()
>needs interpreter. So I think there will never be an eval() function
>in euphoria.
>
>
I disagree entirely. The facility that eval() provides would be easy to
implement. Simply create a function euParse() which returns the IL code
for a string of Euphoria source, and a function euRun() which executes
this IL. You could then provide a function eval(sequence source) that
just does return euRun(euParse(source)). Easy.
Also, it is not quite true that Euphoria can be compiled. It is simply
translated to the aforementioned IL, and then executed, so providing
these three functions should be as simple as wrapping their Euphoria
(for the parser in 2.5) and C counterparts.
5. Re: Another EU 2.5 suggestion...
aku saya wrote:
> After reading many posts about the eval() function, I want to post my
> opinion, that eval() will not be suitable for euphoria, because
> euphoria can be translated and compiled, not just interpreted. Eval()
> needs interpreter. So I think there will never be an eval() function
> in euphoria.
Why should eval() need an interpreter? I wrote my own Euphoria function
for evaluating math expressions, which are given as string at runtime.
This works fine in compiled programs.
<snip>
Regards,
Juergen
--
/"\ ASCII ribbon campain | Math problems?
\ / against HTML in | Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
6. Re: Another EU 2.5 suggestion...
CoJaBo wrote:
> I would like to be able to set the value of a variable like this:
> integer
> some_extremly_long_variable_name=82,another_extremly_long_variable_name=45
>
> Instead of:
> integer
> some_extremly_long_variable_name,another_extremly_long_variable_name
> some_extremly_long_variable_name=82
> another_extremly_long_variable_name=45
>
> This would be much easeyer, especilly with long variable names.
> This is already used in constants, so why not with regular variables?
This has been discussed here several times before. I think most people
on this list agree with you.
<snip>
Regards,
Juergen
--
/"\ ASCII ribbon campain | Math problems?
\ / against HTML in | Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
7. Re: Another EU 2.5 suggestion...
Isaac Raway wrote:
> aku saya wrote:
>
>>
>> After reading many posts about the eval() function, I want to post my
>> opinion, that eval() will not be suitable for euphoria, because
>> euphoria can be translated and compiled, not just interpreted. Eval()
>> needs interpreter. So I think there will never be an eval() function
>> in euphoria.
>>
>>
> I disagree entirely. The facility that eval() provides would be easy to
> implement. Simply create a function euParse() which returns the IL code
> for a string of Euphoria source, and a function euRun() which executes
> this IL. You could then provide a function eval(sequence source) that
> just does return euRun(euParse(source)). Easy.
>
> Also, it is not quite true that Euphoria can be compiled.
aku saya wrote: "translated and compiled".
I have translated Eu code to C myself several times, using RDS' Eu2C
translator. Then I did something with the C code, using the Borland or
the Watcom C compiler, resulting in an EXE file.
What did the compilers do with he C code, if they did not compile it?
> It is simply
> translated to the aforementioned IL, and then executed, so providing
> these three functions should be as simple as wrapping their Euphoria
> (for the parser in 2.5) and C counterparts.
Regards,
Juergen
--
/"\ ASCII ribbon campain | Math problems?
\ / against HTML in | Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
8. Re: Another EU 2.5 suggestion...
I understand what your sayin but I dont think its necasary.
In my opinion the first example is better. In the first example the if
statement in produre main() only has to check if x = ERROR, where in the
second example it has to call a low_level routine to check if x is
assighned.
----- Original Message -----
From: "aku saya" <akusaya at gmx.net>
To: <EUforum at topica.com>
Sent: Sunday, January 25, 2004 5:06 PM
Subject: Re: Another EU 2.5 suggestion...
>
>
> After reading many posts about the eval() function, I want to post my
> opinion, that eval() will not be suitable for euphoria, because
> euphoria can be translated and compiled, not just interpreted. Eval()
> needs interpreter. So I think there will never be an eval() function
> in euphoria.
>
> However I really want a method to set and detect unassigned value in
> euphoria. This function
>
> constant ERROR = -1
>
> function generate_random()
> -- generate a random number
> if (success) then
> return the_number
> else
> return ERROR -- failed to generate
> end if
> end function
>
> procedure main()
> object x x = generate_random()
> if x = ERROR then
> puts(1, "error occured")
> end if
> end procedure
>
> would be able to be replaced by:
>
> function generate_random()
> -- generate a random number
> if (success) then
> return the_number
> else
> return no_value() -- failed to generate
> ^^^^^^^^^
> built-in function that returns unassigned
> end if
> end function
>
> procedure main()
> object x x = generate_random()
> if unassigned(x) then
> puts(1, "error occured")
> end if
> end procedure
>
> For a function that returns all possible value it will be very useful
> to differentiate special return value.
>
>
> C> I would like to be able to set the value of a variable like this:
> C> integer
> C>
some_extremly_long_variable_name=82,another_extremly_long_variable_name=45
>
> C> Instead of:
> C> integer
> C> some_extremly_long_variable_name,another_extremly_long_variable_name
> C> some_extremly_long_variable_name=82
> C> another_extremly_long_variable_name=45
>
> C> This would be much easeyer, especilly with long variable names.
> C> This is already used in constants, so why not with regular variables?
>
> C> And I would also REALLY like my other suggestions included:
>
> C> "eval()" commands/crash callbacks/ect. for Euphoria 2.5?
>
> C> Some of the following is missing from Euphoria and would be very
> C> helpful to me and many other programmers. I would like to see this in
> C> Eu 2.5. Please take these into consideration.
>
>
> C> "eval()" commands:
> C> I would really like to see a way to do an "eval()" type command.
> C> Many other languages have something like this.
>
> C> eval(sequence eval_commands,integer global_type,integer crash)
> C> eval_commands is a sequence of commands
> C> global_type is:
> C> 0-No routines/varibles (even global) exist in main program
> C> 1-Only routines/varibles declared as global exist in main program
> C> 2-All routines/varibles exist in main program
>
> C> if crash is true, if it encounters an error (like 1/0) than the
> C> program dies with (or a crash routine, see below) ex.err, otherwise, it
> C> returns an error
> C> code(like 5 for divide by 0,see below)
>
>
> C> Example:
> C> integer a,global_type
> C> sequence eval_commands
>
> C> eval_commands="
> C> include incl_file.e--should allow including(This could be used
> C> --instead of complex "dynamic includeing" libraries)
> C> if a then
> C> ?a
> C> end if"
>
> C> a=7
> C> var_type=1
>
> C> ?eval(eval_commands,global_type,0)
> C> Displays:
> C> 7(value of a)
> C> 0(eval encountered no errors)
>
>
> C> set_crash(integer routine_id)
> C> routine_id is the routine id of the function
> C> it calls the function with an error code(like 5 for divide by 0),
> C> a sequence with info about the error(like a line #, invalid subscript,
> C> ect.)
> C> and a text string with the complete text error message(
> C> "test.ex:3
> C> attempt to divide by 0")
>
> C> if the function returns -1, ignore the error
>
> C> Example:
> C> function oncrash(integer err_code,sequence info,sequence msg)
> C> if err_code=34 then--this error can be ignored in this program
> C> return -1
> C> end if
> C> save_all_important_data()
> C> return 0
> C> end function
> C> set_crash(routine_id("oncrash"))
>
>
> C> TOPICA - Start your own email discussion group. FREE!
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
> --
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.564 / Virus Database: 356 - Release Date: 20/01/04
>
---
--
9. Re: Another EU 2.5 suggestion...
The translator uses a compiler to convert Euphoria to compatible C/C++
modules, depending on the compiler.
You can then use "make.bat" that is produced to link the C source code wich
takes care of any posibble parameters you may have needed.
This means you dont really have to use Borland or
the Watcom C compiler manualy at all.
----- Original Message -----
From: "Juergen Luethje" <j.lue at gmx.de>
To: <EUforum at topica.com>
Sent: Sunday, January 25, 2004 8:22 PM
Subject: Re: Another EU 2.5 suggestion...
>
>
> Isaac Raway wrote:
>
> > aku saya wrote:
> >
> >>
> >> After reading many posts about the eval() function, I want to post my
> >> opinion, that eval() will not be suitable for euphoria, because
> >> euphoria can be translated and compiled, not just interpreted. Eval()
> >> needs interpreter. So I think there will never be an eval() function
> >> in euphoria.
> >>
> >>
> > I disagree entirely. The facility that eval() provides would be easy to
> > implement. Simply create a function euParse() which returns the IL code
> > for a string of Euphoria source, and a function euRun() which executes
> > this IL. You could then provide a function eval(sequence source) that
> > just does return euRun(euParse(source)). Easy.
> >
> > Also, it is not quite true that Euphoria can be compiled.
>
> aku saya wrote: "translated and compiled".
> I have translated Eu code to C myself several times, using RDS' Eu2C
> translator. Then I did something with the C code, using the Borland or
> the Watcom C compiler, resulting in an EXE file.
> What did the compilers do with he C code, if they did not compile it?
>
> > It is simply
> > translated to the aforementioned IL, and then executed, so providing
> > these three functions should be as simple as wrapping their Euphoria
> > (for the parser in 2.5) and C counterparts.
>
> Regards,
> Juergen
>
> --
> /"\ ASCII ribbon campain | Math problems?
> \ / against HTML in | Call 1-800-[(10x)(13i)^2]-[sin(xy)/2.362x].
> X e-mail and news, |
> / \ and unneeded MIME | http://home.arcor.de/luethje/prog/
>
>
>
> TOPICA - Start your own email discussion group. FREE!
>
>
> --
> Incoming mail is certified Virus Free.
> Checked by AVG anti-virus system (http://www.grisoft.com).
> Version: 6.0.564 / Virus Database: 356 - Release Date: 20/01/04
>
---
--
10. Re: Another EU 2.5 suggestion...
>From: Isaac Raway <isaac-topica at blueapples.org>
>Subject: Re: Another EU 2.5 suggestion...
>
>aku saya wrote:
>
>>After reading many posts about the eval() function, I want to post my
>>opinion, that eval() will not be suitable for euphoria, because
>>euphoria can be translated and compiled, not just interpreted. Eval()
>>needs interpreter. So I think there will never be an eval() function
>>in euphoria.
>>
>>
>I disagree entirely. The facility that eval() provides would be easy to
>implement. Simply create a function euParse() which returns the IL code for
>a string of Euphoria source, and a function euRun() which executes this IL.
>You could then provide a function eval(sequence source) that just does
>return euRun(euParse(source)). Easy.
>
With the next version of Euphoria, I think this will be very easy. The
parser will be Euphoria code, so all you have to do is translate it to IL
code, and use it to translate stuff you want to eval(). This is useable even
when you translate the code.
11. Re: Another EU 2.5 suggestion...
--- Isaac Raway <isaac-topica at blueapples.org> wrote:
>
> aku saya wrote:
>
> >
> >After reading many posts about the eval() function, I want to post my
> >opinion, that eval() will not be suitable for euphoria, because
> >euphoria can be translated and compiled, not just interpreted. Eval()
> >needs interpreter. So I think there will never be an eval() function
> >in euphoria.
> >
> >
> I disagree entirely. The facility that eval() provides would be easy to
> implement. Simply create a function euParse() which returns the IL code
> for a string of Euphoria source, and a function euRun() which executes
> this IL. You could then provide a function eval(sequence source) that
> just does return euRun(euParse(source)). Easy.
>
> Also, it is not quite true that Euphoria can be compiled. It is simply
> translated to the aforementioned IL, and then executed, so providing
> these three functions should be as simple as wrapping their Euphoria
> (for the parser in 2.5) and C counterparts.
>
As others have noted, Euphoria *can* be compiled (using the Euphoria runtime
library). In order to have the eval() functionality, though, you'd probably
need an additional library to do the parsing, as well as a thin interpreter
that could call the run time libarary.
Matt Lewis
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
12. Re: Another EU 2.5 suggestion...
Matt Lewis wrote:
>
>
>--- Isaac Raway <isaac-topica at blueapples.org> wrote:
>=20=20
>
>>aku saya wrote:
>>
>>=20=20=20=20
>>
>>>After reading many posts about the eval() function, I want to post my
>>>opinion, that eval() will not be suitable for euphoria, because
>>>euphoria can be translated and compiled, not just interpreted. Eval()
>>>needs interpreter. So I think there will never be an eval() function
>>>in euphoria.
>>>=20
>>>
>>>=20=20=20=20=20=20
>>>
>>I disagree entirely. The facility that eval() provides would be easy to=
=20
>>implement. Simply create a function euParse() which returns the IL code=
=20
>>for a string of Euphoria source, and a function euRun() which executes=
=20
>>this IL. You could then provide a function eval(sequence source) that=20
>>just does return euRun(euParse(source)). Easy.
>>
>>Also, it is not quite true that Euphoria can be compiled. It is simply=
=20
>>translated to the aforementioned IL, and then executed, so providing=20
>>these three functions should be as simple as wrapping their Euphoria=20
>>(for the parser in 2.5) and C counterparts.
>>
>>=20=20=20=20
>>
>
>As others have noted, Euphoria *can* be compiled (using the Euphoria runti=
me
>library). In order to have the eval() functionality, though, you'd probab=
ly
>need an additional library to do the parsing, as well as a thin interprete=
r
>that could call the run time libarary.
>
>Matt Lewis
>
>
>=20=20
>
No, it cannot be compiled.
An approximately equivalent C source file can be generated, which is=20
then compiled. This is very different from an actual compiler, as it=20
introduces another layer in the process with it's own questions. Such a=20
question was cited in another response to this thread, where Aku assumed=
=20
that the translator should discard variable names. I don't know that it=20
does this now, as I don=92t use it, but it certainly is not a requirement=
=20
that it does.
The facility I described (euParse(), euRun() and eval()) should execute=20
just fine in a translated program. If not, then the translator would be=20
changing the semantics of the program to the point that little else=20
should be expected to execute properly either.
Even if would not work in a translated program, this should not be of=20
concern to a new version of the language. The translator will just have=20
to "grow up", so to speak, and support the new feature.
>__________________________________
>Do you Yahoo!?
>=20=20
>
No. I most certainly do not Yahoo.
13. Re: Another EU 2.5 suggestion...
--- Isaac Raway <isaac-topica at blueapples.org> wrote:
>
> Matt Lewis wrote:
>
> >As others have noted, Euphoria *can* be compiled (using the Euphoria
> >runtime library). In order to have the eval() functionality, though,
> >you'd probably need an additional library to do the parsing, as well as a
> >thin interpreter that could call the run time libarary.
> >
> No, it cannot be compiled.
>
> An approximately equivalent C source file can be generated, which is
> then compiled. This is very different from an actual compiler, as it
> introduces another layer in the process with it's own questions. Such a
> question was cited in another response to this thread, where Aku assumed
> that the translator should discard variable names. I don't know that it
> does this now, as I don=92t use it, but it certainly is not a requirement
> that it does.
I think we're getting into semantics here. We could get real silly and say
that compiling doesn't give you an executable--you have to link first. So the
translation is just another step in the process (like a preprocessor).
Variable names aren't exactly dropped, but they aren't currently stored in a
symbol table. This would be part of the job of the extra libraries that I
mentioned.
> The facility I described (euParse(), euRun() and eval()) should execute
> just fine in a translated program. If not, then the translator would be
> changing the semantics of the program to the point that little else
> should be expected to execute properly either.
I don't think this is the proper way to go. What about dynamically created
code to be eval'd? There's no way to pre-translate/compile that.
> Even if would not work in a translated program, this should not be of
> concern to a new version of the language. The translator will just have
> to "grow up", so to speak, and support the new feature.
I agree, it just has to be planned out. But it also has to be below a certain
level of complexity, I suspect, before Rob would agree to implement it.
Matt Lewis
__________________________________
Do you Yahoo!?
Yahoo! SiteBuilder - Free web site building tool. Try it!
http://webhosting.yahoo.com/ps/sb/
14. Re: Another EU 2.5 suggestion...
aku saya wrote:
>> Why should eval() need an interpreter? I wrote my own Euphoria function
>> for evaluating math expressions, which are given as string at runtime.
>> This works fine in compiled programs.
>
> I mean, eval() will need an interpreter if the parameter to eval() is
> like this:
>
> atom A
> A = 10
> print(1, eval("A + 7")) -- access the above A
Ah, I see. You want the eval() function to be able to access variables
in the program ...
> In compiled program variable names will be discarded, right?
I don't know.
> If you need only the math only eval, why request to Rob? Why don't
> just make your own eval() function? (So, not built-in in euphoria)
Hm ...?? I did not request Rob for an eval() function. I _did_ write my
own eval() function, as I previously wrote (see 1st paragraph of this
mail).
Regards,
Juergen
--
/"\ ASCII ribbon campain | This message has been ROT-13 encrypted
\ / against HTML in | twice for higher security.
X e-mail and news, |
/ \ and unneeded MIME | http://home.arcor.de/luethje/prog/
15. Re: Another EU 2.5 suggestion...
Matt Lewis wrote:
>
>
>--- Isaac Raway <isaac-topica at blueapples.org> wrote:
>
>
>>Matt Lewis wrote:
>>
>>
>>>As others have noted, Euphoria *can* be compiled (using the Euphoria
>>>runtime library). In order to have the eval() functionality, though,
>>>you'd probably need an additional library to do the parsing, as well as a
>>>thin interpreter that could call the run time libarary.
>>>
>>>
>>No, it cannot be compiled.
>>
>>An approximately equivalent C source file can be generated, which is
>>then compiled. This is very different from an actual compiler, as it
>>introduces another layer in the process with it's own questions. Such a
>>question was cited in another response to this thread, where Aku assumed
>>that the translator should discard variable names. I don't know that it
>>does this now, as I don=92t use it, but it certainly is not a requirement
>>that it does.
>>
>>
>I think we're getting into semantics here.
>
Yes we are. We're talking about executing program code in four different
types of environments (interpreted, translated, eval'd within
interpreted, and eval'd within translated).
This whole problem is all about semantics.
>We could get real silly and say
>that compiling doesn't give you an executable--you have to link first.
>
That's not silly at all.
>So the
>translation is just another step in the process (like a preprocessor).
>
>
Somewhat. However, the code itself is potentially modified
substantially. If variable names are dropped and other such information
is discarded, then the function of the translator is quite different
from that of a textual preprocessor.
>Variable names aren't exactly dropped, but they aren't currently stored in a
>symbol table. This would be part of the job of the extra libraries that I
>mentioned.
>
>
Symbol tables would be an interesting solution, however the problem I
see there is that such a new system could potentially change the
semantics of the Euphoria program. Those libraries would need to be
very, very careful to adhere exactly to the same process used in
"interpreted" code or there could be unforeseen incompatibilities. I
vote for a simpler solution, and that is to not allow variables
references inside of eval'd code.
>>The facility I described (euParse(), euRun() and eval()) should execute
>>just fine in a translated program. If not, then the translator would be
>>changing the semantics of the program to the point that little else
>>should be expected to execute properly either.
>>
>>
>I don't think this is the proper way to go. What about dynamically created
>code to be eval'd? There's no way to pre-translate/compile that.
>
>
You misunderstand. I meant to say that the semantics of executing those
three functions, weather directly in Euphoria or iside a translated
program, should be exactly the same; therefore it should run just fine.
I personally do not see what the big deal is, anyway. The new parser
will be written in Euphoria, which will (presumably) execute fine as a
translated program, and the runtime engine itself is simply a C program,
so it should not be a big deal to call it.
We only run into problems when we expect the eval'd code to be able to
modify variables in the host program. I think that this shouldn't be
allowed anyway for safty sake. Rather, I'd treat all eval'd code as if
it where within a procedure body. If we really want to have global
variables accessable within the eval'd code, then that could be part of
the function of euRun(), to pass variables too and from the eval'd code.
>
>
>>Even if would not work in a translated program, this should not be of
>>concern to a new version of the language. The translator will just have
>>to "grow up", so to speak, and support the new feature.
>>
>>
>I agree, it just has to be planned out. But it also has to be below a certain
>level of complexity, I suspect, before Rob would agree to implement it.
>
>
Agreed. Not just so that he will implement it, but so that it will be
transparent to the programmer using the system.
~ Isaac Raway
