1. call_back() etc
Ok, I know this is beating a dead horse, but I just want to make sure
I'm flexing myself before I give up on this:
Ok, now I totally guessing here, but it would seem that call_back()
returns a 32-bit address referring to a location in memory of the code
associated with a call to routine_id(). As such, the win32 C code, or
whatever is using the call_back() refers to this memory location for
execution. The other possibility is that it's just J. Random integer
that windows uses internally.
So, i guess the question is, is it possible to coax euphoria into giving
up more information about a function/procedure, so that another run can
use it?
Or maybe I'm not fully grasping what's going on here, mebbe I should be
more specific as to why I'm confused:
Im currently passing 32-bit memory addresses between runs of euphoria by
utilizing a temp file and the system_exec() function, and it appears to
work--Im pretty sure I can swap information between runs of Euphoria,
and now I want to send functions.
Blech.
noah
2. Re: call_back() etc
noah smith wrote:
>Ok, I know this is beating a dead horse, but I just want to make sure
>I'm flexing myself before I give up on this:
>
>Ok, now I totally guessing here, but it would seem that call_back()
>returns a 32-bit address referring to a location in memory of the code
>associated with a call to routine_id(). As such, the win32 C code, or
>whatever is using the call_back() refers to this memory location for
>execution. The other possibility is that it's just J. Random integer
>that windows uses internally.
>
>So, i guess the question is, is it possible to coax euphoria into giving
>up more information about a function/procedure, so that another run can
>use it?
Okay, I'm still not quite sure what you're looking for... it sounds
like you're trying to get one program to execute code that's in another
program, WITHOUT putting that code in the first program at all (via an
include, or directly.) Or are you wanting one program to tell another
to execute a specific function?
In the latter case, would it suit your needs if, instead of using the
temp file to pass call_back() values (I'm not even sure you can use that
with the DOS32 version of Euphoria), you passed actual function names?
For example, instead of of doing:
id = routine_id ("f")
callback_val = call_back (id)
and writing callback_val to the other temp file, would just writing "f"
to the file accomplish what you want?
Rod
3. Re: call_back() etc
Im almost entirely unfamiliar with win32/object oriented/dll stuff, but let
me see if I can try one more time:
What I've played with so far:
Run ProgA
Code
system_exec(ProgB)
Code
end ProgA
What I really want to happen is for ProgA to be able to invoke Euphoria to
intrepret ProgB, and then use the functions ProgB has created. Basically,
ProgA needs the ability to temporarily add Euphoria-intepreted code from an
external file on the fly:
Run ProgA
ProgA code
Run ProgB
Register ProgB functions/procedures with ProgA
ProgA code using ProgB functions/procedures
end ProgB
Unregister ProgB functions/procedures from ProgA
ProgA code
end ProgA
It was suggested earlier that the new code could be added as includes to the
original code and then re-run. However, I want the ability to add several
new scripts, and to drop them quickly, without significant interruption of
the program.
Okay, I'm still not quite sure what you're looking for... it sounds
> like you're trying to get one program to execute code that's in another
> program, WITHOUT putting that code in the first program at all (via an
> include, or directly.) Or are you wanting one program to tell another
> to execute a specific function?
>
> In the latter case, would it suit your needs if, instead of using the
> temp file to pass call_back() values (I'm not even sure you can use that
> with the DOS32 version of Euphoria), you passed actual function names?
> For example, instead of of doing:
>
> id = routine_id ("f")
> callback_val = call_back (id)
>
> and writing callback_val to the other temp file, would just writing "f"
> to the file accomplish what you want?
>
> Rod
4. Re: call_back() etc
Noah-
I have 2 suggestions:
1) translate your ProgB's routines into machine code and poke that into
memory and use call()... or
2) instead of loading ProgB's routines, do something like this:
C:\>ProgB runprogram this would run ProgB's code like a program
C:\>ProgB routinename bufferaddr this would run one of ProgB's
routines, and if a function, place the return value at bufferaddr, which you
allocate() before calling. When doing it like this, you'd need to pull a
sprintf() to string-ize the bufferaddr in ProgA, and value() in ProgB to
return it to a number.
This work?
Mike Hurley
________________________________________________________
NetZero - We believe in a FREE Internet. Shouldn't you?
Get your FREE Internet Access and Email at
http://www.netzero.net/download/index.html
5. Re: call_back() etc
noah smith wrote:
>What I've played with so far:
>
>Run ProgA
> Code
> system_exec(ProgB)
> Code
>end ProgA
>
>What I really want to happen is ...
<snip>
>Run ProgA
> ProgA code
> Run ProgB
> Register ProgB functions/procedures with ProgA
> ProgA code using ProgB functions/procedures
> end ProgB
> Unregister ProgB functions/procedures from ProgA
> ProgA code
>end ProgA
<snip>
I see now. Well, I hate to say it, but to do this the way you're
wanting is pretty much impossible. Once code has been declared in
a context (such as for use with ProgA), you can't get rid of it.
Now you COULD, in theory, do this: write ProgA so that when it
needs to execute ProgB's functions, it runs a second instance of
Euphoria, interpreting ProgB, and gives (as command-line parameters)
the specific function to execute, plus any data needed to get the
right answer.
If you're willing to take the performance hit to run Euphoria for
EACH function call to ProgB, you can do something like the following:
-- BEGIN PROGB (WARNING: pseudo-code) --
sequence params, function_name
object return_object
params = get_command_line_params ()
function_name = params[1]
params = params[2..length(params)] -- remove the function name
return_object = call_func (routine_id (function_name), params)
write_to_file ("temp.txt", return_object)
-- END PROGB --
-----------------
-- BEGIN PROGA --
function CallProgBFunc (sequence FuncName, sequence ParamStrings)
sequence ProgBExecString
object ReturnObject
ProgBExecString = "ex progb.ex " & FuncName
for i = 1 to length (ParamStrings) do
ProgBExecString = ProgBExecString & " " & ParamStrings[i]
end for
system_exec (ProgBExecString) -- you may need system() instead
ReturnObject = get_data_from_file ("temp.txt") -- pseudo-code
delete_file ("temp.txt") -- more pseudo-code
return ReturnObject
end function
-- execute some ProgA code...
x = CallProgBFunc ("square", {sprintf (x)})
y = CallProgBFunc ("add", {sprintf (x), sprintf (y)})
-- execute some more ProgA code...
-- END PROGA --
Now, this method might run into difficulties (I'm not sure if you'll
be able to send sequences to the ProgB functions), but I think it's
pretty close to what you want. If you want to use several ProgB
functions at a time before returning to ProgA, let me know; I still
might be able to help you out.
But honestly, this seems like a lot of work to avoid keeping the
routines in memory, plus the performance hit when using ProgB's
routines is going to be significant. Is there some reason why you
don't want to include code as needed, or at the start? Are you
trying to keep the program size small or something? If there's some
other factor at work here, we might be able to help you get around
it some other way.
Rod
6. Re: call_back() etc
----- Original Message -----
From: noah smith <option1 at OPTIONINTERACTIVE.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, August 12, 1999 4:39 PM
Subject: Re: call_back() etc
> Im almost entirely unfamiliar with win32/object oriented/dll stuff, but
let
> me see if I can try one more time:
<snip>
> What I really want to happen is for ProgA to be able to invoke Euphoria to
> intrepret ProgB, and then use the functions ProgB has created. Basically,
> ProgA needs the ability to temporarily add Euphoria-intepreted code from
an
> external file on the fly:
>
> Run ProgA
> ProgA code
> Run ProgB
> Register ProgB functions/procedures with ProgA
> ProgA code using ProgB functions/procedures
> end ProgB
> Unregister ProgB functions/procedures from ProgA
> ProgA code
> end ProgA
>
> It was suggested earlier that the new code could be added as includes to
the
> original code and then re-run. However, I want the ability to add several
> new scripts, and to drop them quickly, without significant interruption of
> the program.
I can sure make use of this too. I am currently doing this with DDE in
win95, but i'd prefer to do it in msdos, but at the moment, i don't have the
time to write this code. In win95, if the DDE fails, it just fails, no
problems,,, if it succeeds, then something happens. The DDE handles can be
registered, unregistered, changed, etc,, and new instances run and killed.
Maybe linux offers a better way of doing this,,, sigh, yet another porting
to another OS. Also, in Mirc, i can load a script and run it, and unload it,
no problem, while it is running. It's a terribly limiting "OS", it's not an
OS, it's an irc client,, and i am hoping i can easily do the same things in
Euphoria. One other thing i like in Mirc is the ability to build a var while
it's running:
set -u5 %someothervarname thisisatest
set %Somevar. [ $+ [ %someothervarname ] ] any var, regardless of type.
now %Somevar.thisisatest equals: any var, regardless of type.
and in 5 seconds, %someothervarname is erased, set to $null, deleted, etc
and:
unset %Somevar.*
will set to $null, erase all variables with names beginning with
'%Somevar.".
I figure i can pull it off using sequences in Eu. Mirc is incredibly slow
and memory limiting in storing variables. Has anyone already done this? An
easier timer interface, like mirc has, would be nice also. 
Kat,
still exploring for that perfect programming language.
7. Re: call_back() etc
----- Original Message -----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, August 12, 1999 5:27 PM
Subject: Re: call_back() etc
<snip>
> But honestly, this seems like a lot of work to avoid keeping the
> routines in memory, plus the performance hit when using ProgB's
> routines is going to be significant. Is there some reason why you
> don't want to include code as needed, or at the start? Are you
> trying to keep the program size small or something? If there's some
> other factor at work here, we might be able to help you get around
> it some other way.
One word: huristics.
I expect i will not know when i write more code that i will know all i want
the code to do, indeed, i expect the code to write more of it's own code. I
fully expect and hope that new vars will be created, var names that i can
only guess at now, altho i do have a skeleton for it to build on. I, for
one, will need the code i write to be able to interface to code i have no
knowledge of, using variables i don't know the names of. So far, what i have
done does work, and i hope it works in Eu. This is why i wish to avoid *all*
type checking also, i have no idea what the types are, and i don't care
either. If a variable is a math expression, maybe i want to *execute* that
variable, if it is an integer, then i can increment it, or maybe i want to
append them and print them out. I do not want info types locked in at
compile time or at run time. If i have a callable function that does
something, and i want it to do something new *while the calling app is
running*, because the program learned something and wants to implement it,
then it should be free to do so. It's the basic principle of learning, to
grow, to be able to do things not known at compile time.
Kat,
learning.
8. Re: call_back() etc
On Thu, 12 Aug 1999, you wrote:
> Also, in Mirc, i can load a script and run it, and unload it,
> no problem, while it is running. It's a terribly limiting "OS", it's not an
> OS, it's an irc client,, and i am hoping i can easily do the same things in
> Euphoria. One other thing i like in Mirc is the ability to build a var while
> it's running:
>
> set -u5 %someothervarname thisisatest
> set %Somevar. [ $+ [ %someothervarname ] ] any var, regardless of type.
>
> now %Somevar.thisisatest equals: any var, regardless of type.
> and in 5 seconds, %someothervarname is erased, set to $null, deleted, etc
>
> and:
> unset %Somevar.*
> will set to $null, erase all variables with names beginning with
> '%Somevar.".
>
> I figure i can pull it off using sequences in Eu. Mirc is incredibly slow
> and memory limiting in storing variables. Has anyone already done this? An
> easier timer interface, like mirc has, would be nice also.
>
> Kat,
> still exploring for that perfect programming language.
You should try perl. I think there are ways to do most of what you describe.
Irv
9. Re: call_back() etc
On Thu, 12 Aug 1999, Kat wrote:
> One word: huristics.
>
> I expect i will not know when i write more code that i will know all i want
> the code to do, indeed, i expect the code to write more of it's own code. I
> fully expect and hope that new vars will be created, var names that i can
> only guess at now, altho i do have a skeleton for it to build on. I, for
> one, will need the code i write to be able to interface to code i have no
> knowledge of, using variables i don't know the names of. So far, what i have
> done does work, and i hope it works in Eu. This is why i wish to avoid *all*
> type checking also, i have no idea what the types are, and i don't care
> either. If a variable is a math expression, maybe i want to *execute* that
> variable, if it is an integer, then i can increment it, or maybe i want to
> append them and print them out. I do not want info types locked in at
> compile time or at run time. If i have a callable function that does
> something, and i want it to do something new *while the calling app is
> running*, because the program learned something and wants to implement it,
> then it should be free to do so. It's the basic principle of learning, to
> grow, to be able to do things not known at compile time.
Interesting. What answer (or answers) will your program give to this question:
what is "Hello World" + 29.95 ?
Irv
10. Re: call_back() etc
- Posted by Bernie Ryan <bwryan at PCOM.NET>
Aug 12, 1999
-
Last edited Aug 13, 1999
On Thu, 12 Aug 1999, Kat wrote:
> One word: huristics.
Heuristics means to invent, discover or to learn.
For Heuristics you need a self modifing langauge.
Euphoria can not modifiy it-self during run time.
You will have to write your own special language in Euphoria.
So the first step is to define and design your special language before
you can even think about using your special langauge to write anything.
11. Re: call_back() etc
----- Original Message -----
From: Irv Mullins <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, August 12, 1999 6:35 PM
Subject: Re: call_back() etc
> On Thu, 12 Aug 1999, Kat wrote:
>
> > One word: huristics.
> >
> > I expect i will not know when i write more code that i will know all i
want
> > the code to do, indeed, i expect the code to write more of it's own
code. I
> > fully expect and hope that new vars will be created, var names that i
can
> > only guess at now, altho i do have a skeleton for it to build on. I, for
> > one, will need the code i write to be able to interface to code i have
no
> > knowledge of, using variables i don't know the names of. So far, what i
have
> > done does work, and i hope it works in Eu. This is why i wish to avoid
*all*
> > type checking also, i have no idea what the types are, and i don't care
> > either. If a variable is a math expression, maybe i want to *execute*
that
> > variable, if it is an integer, then i can increment it, or maybe i want
to
> > append them and print them out. I do not want info types locked in at
> > compile time or at run time. If i have a callable function that does
> > something, and i want it to do something new *while the calling app is
> > running*, because the program learned something and wants to implement
it,
> > then it should be free to do so. It's the basic principle of learning,
to
> > grow, to be able to do things not known at compile time.
>
> Interesting. What answer (or answers) will your program give to this
question:
> what is "Hello World" + 29.95 ?
Prolly the same answer i would give you: A badly formed math expression with
no answer.
Re-read where i said "If a variable is a math expression, maybe i want to
*execute* that
> > variable, if it is an integer, then i can increment it, or maybe i want
to
> > append them and print them out. "
Kat
12. Re: call_back() etc
----- Original Message -----
From: Bernie Ryan <bwryan at PCOM.NET>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Thursday, August 12, 1999 7:42 PM
Subject: Re: call_back() etc
> On Thu, 12 Aug 1999, Kat wrote:
>
> > One word: huristics.
>
> Heuristics means to invent, discover or to learn.
>
> For Heuristics you need a self modifing langauge.
> Euphoria can not modifiy it-self during run time.
> You will have to write your own special language in Euphoria.
> So the first step is to define and design your special language before
> you can even think about using your special langauge to write anything.
>
Unless you can dynamically relink the functions/procedures throughout the
program, as i explained can be done with Mirc, where it can send code to a
file, and then load that file and call code in it, and unload it or reload a
new file as needed. Or where you can register a DDE handle with one .exe,
use it, unreg the handle, call a 2nd .exe with the original handle, etc...
Eu can also send code to a file, and use systemexec to start EXW with the
new file as a command line parameter, then link to that new program, using
either DDE or Winxx _msgs,, right?
Kat
13. Re: call_back() etc
Kat wrote:
>>Is there some reason why you
>> don't want to include code as needed, or at the start? Are you
>> trying to keep the program size small or something? If there's some
>> other factor at work here, we might be able to help you get around
>> it some other way.
>
>One word: huristics.
<snip>
>If i have a callable function that does
>something, and i want it to do something new *while the calling app is
>running*, because the program learned something and wants to implement it,
>then it should be free to do so. It's the basic principle of learning, to
>grow, to be able to do things not known at compile time.
Ah, self-modifying code. Well, sorry to say it, but some of the others
are right: Euphoria's not the best language for that. If you *really*
want to go all-out with that approach, something like Lisp might be a
better choice. (Still haven't looked at Perl, it might do it too.)
Currently, the only way I know to attempt running newly-created code
in Euphoria is:
1) Write code to a file, then "include" it later. Problem here is,
you must write the file outside of all routines, the new routines
become a permanent part of the program, and you can only do it a
limited number of times since you have to specify each new filename.
2) Write out a program to file, execute it via system()/system_exec(),
and have it return a value in a temp file or an environment variable.
Problem here is the performance hit when executing the new code to use
it's routines.
3) Create some sort of simple scripting language in Euphoria yourself,
and a means of interpreting it within your program. Then you can write
code in the scripting language, modify it, remove it, etc. Problem here
is it's cumbersome to write the scripting engine, plus you're no longer
doing all of your coding in Euphoria.
If you're interested in approach #3, may I humbly suggest trying out
Topaz? It's a simple, "multithreading" scripting engine written in
Euphoria; you can extend it with new commands. You can find it on the
Euphoria website, under recent user contributions.
Have fun,
Rod
14. Re: call_back() etc
On Fri, 13 Aug 1999, you wrote:
> > > i have no idea what the types are, and i don't care
> > > either. If a variable is a math expression, maybe i want to *execute* that
> > > variable, if it is an integer, then i can increment it, or maybe i want to
> > > append them and print them out. I do not want info types locked in at
> > > compile time or at run time.
> > Interesting. What answer (or answers) will your program give to this
> > question:
> > what is "Hello World" + 29.95 ?
>
> Prolly the same answer i would give you: A badly formed math expression with
> no answer.
> Re-read where i said "If a variable is a math expression, maybe i want to
> *execute* that
> variable,
It _is_ a perfectly good math expression. On a previous input, I typed "Hello
World" = 3. Therefore, it should print 32.95
> if it is an integer, then i can increment it,
> or maybe i want to append them and print them out.
On another line, I typed 29.95 = "Bubba", so I am expecting it to
print "3 Bubba".
Unless, of course, your program refuses to accept the assignments:
"Hello World" = 3
29.95 = "Bubba"
In which case, you have not gotten rid of typed variables at all, but are
simply asking the user to declare the types at input time. This can work, but
you'll need a lot of "re-do from start" messsages, not unlike another language
most of us are familiar with :)
Irv
15. Re: call_back() etc
If *I* don't think this way, why would I want my *computer* to think like this?
> -----Original Message-----
> From: Irv Mullins [SMTP:irv at ELLIJAY.COM]
> Sent: Friday, August 13, 1999 8:33 AM
> To: EUPHORIA at LISTSERV.MUOHIO.EDU
> Subject: Re: call_back() etc
>
> On Fri, 13 Aug 1999, you wrote:
>
> > > > i have no idea what the types are, and i don't care
> > > > either. If a variable is a math expression, maybe i want to *execute*
> > > > that
> > > > variable, if it is an integer, then i can increment it, or maybe i want
> > > > to
> > > > append them and print them out. I do not want info types locked in at
> > > > compile time or at run time.
>
> > > Interesting. What answer (or answers) will your program give to this
> > > question:
> > > what is "Hello World" + 29.95 ?
> >
> > Prolly the same answer i would give you: A badly formed math expression with
> > no answer.
> > Re-read where i said "If a variable is a math expression, maybe i want to
> > *execute* that
> > variable,
>
> It _is_ a perfectly good math expression. On a previous input, I typed "Hello
> World" = 3. Therefore, it should print 32.95
>
> > if it is an integer, then i can increment it,
> > or maybe i want to append them and print them out.
> On another line, I typed 29.95 = "Bubba", so I am expecting it to
> print "3 Bubba".
>
> Unless, of course, your program refuses to accept the assignments:
> "Hello World" = 3
> 29.95 = "Bubba"
> In which case, you have not gotten rid of typed variables at all, but are
> simply asking the user to declare the types at input time. This can work, but
> you'll need a lot of "re-do from start" messsages, not unlike another language
> most of us are familiar with :)
>
> Irv
16. Re: call_back() etc
----- Original Message -----
From: Irv Mullins <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Friday, August 13, 1999 7:32 AM
Subject: Re: call_back() etc
> On Fri, 13 Aug 1999, you wrote:
>
> > > > i have no idea what the types are, and i don't care
> > > > either. If a variable is a math expression, maybe i want to
*execute* that
> > > > variable, if it is an integer, then i can increment it, or maybe i
want to
> > > > append them and print them out. I do not want info types locked in
at
> > > > compile time or at run time.
>
> > > Interesting. What answer (or answers) will your program give to this
question:
> > > what is "Hello World" + 29.95 ?
> >
> > Prolly the same answer i would give you: A badly formed math expression
with
> > no answer.
> > Re-read where i said "If a variable is a math expression, maybe i want
to *execute* that
> > variable,
>
> It _is_ a perfectly good math expression. On a previous input, I typed
"Hello
> World" = 3. Therefore, it should print 32.95
But you didn't say you had previously declared, assigned, and informally
"typed" it...
> > if it is an integer, then i can increment it,
> > or maybe i want to append them and print them out.
> On another line, I typed 29.95 = "Bubba", so I am expecting it to
> print "3 Bubba".
But you didn't say you had previously declared, assigned, and informally
"typed" it...
> Unless, of course, your program refuses to accept the assignments:
> "Hello World" = 3
> 29.95 = "Bubba"
No reason not to accept those, but in your previous email, you didn't say
you had done that, and when i searched my personal wetware's memory banks, i
saw no such assignments either.
Sorry, please try again,
Kat,
constant debugging_tool = Irv -- a new debugging tool
17. Re: call_back() etc
On Fri, 13 Aug 1999, you wrote:
> > Unless, of course, your program refuses to accept the assignments:
> > "Hello World" = 3
> > 29.95 = "Bubba"
>
> No reason not to accept those, but in your previous email, you didn't say
> you had done that, and when i searched my personal wetware's memory banks, i
> saw no such assignments either.
Accept them if you wish. However, neither you nor your program has any way at
all of knowing whether I want "Hello World", or 29.95, to be treated as a string
of characters, a formula, or a variable reference.
I declare a variable:
2 = "Hi there"
now I enter a common formula:
diameter = radius * 2
I'm afraid this is going to return the famous "unexpected result".
It's beginning to remind me of a programming language (I forget which one)
where you could declare variables with the same name as reserved words,
leading to code like:
for for = to to by by do do
print (for)
next
Irv
18. Re: call_back() etc
----- Original Message -----
From: Irv Mullins <irv at ELLIJAY.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: Saturday, August 14, 1999 8:47 AM
Subject: Re: call_back() etc
> On Fri, 13 Aug 1999, you wrote:
>
> > > Unless, of course, your program refuses to accept the assignments:
> > > "Hello World" = 3
> > > 29.95 = "Bubba"
> >
> > No reason not to accept those, but in your previous email, you didn't
say
> > you had done that, and when i searched my personal wetware's memory
banks, i
> > saw no such assignments either.
>
> Accept them if you wish. However, neither you nor your program has any way
at
> all of knowing whether I want "Hello World", or 29.95, to be treated as a
string
> of characters, a formula, or a variable reference.
>
> I declare a variable:
> 2 = "Hi there"
> now I enter a common formula:
> diameter = radius * 2
> I'm afraid this is going to return the famous "unexpected result".
I seem to be missing your point. I wouldn't know what you wanted either,
unless i were to forgo processing nonsense and ask you what you wanted. What
is your point?
Kat,
now wondering if "Hi There" was ever defined.
19. Re: call_back() etc
I believe the language you're looking for is FORTH. That "feature"
struck me as incredibly dangerous when I first saw it.
----------
From: Irv Mullins[SMTP:irv at ELLIJAY.COM]
Sent: Saturday, August 14, 1999 8:47 AM
To: EUPHORIA at LISTSERV.MUOHIO.EDU
Subject: Re: call_back() etc
On Fri, 13 Aug 1999, you wrote:
> > Unless, of course, your program refuses to accept the assignments:
> > "Hello World" = 3
> > 29.95 = "Bubba"
>
> No reason not to accept those, but in your previous email, you didn't say
> you had done that, and when i searched my personal wetware's memory banks, i
> saw no such assignments either.
Accept them if you wish. However, neither you nor your program has any way at
all of knowing whether I want "Hello World", or 29.95, to be treated as a string
of characters, a formula, or a variable reference.
I declare a variable:
2 = "Hi there"
now I enter a common formula:
diameter = radius * 2
I'm afraid this is going to return the famous "unexpected result".
It's beginning to remind me of a programming language (I forget which one)
where you could declare variables with the same name as reserved words,
leading to code like:
for for = to to by by do do
print (for)
next
Irv
20. Re: call_back() etc
Actually, in FORTH there are no reserved words. You could redefine the
meaning and behaviour of any word, but each word only had one behaviour at
a time.
In FORTH you can do silly things like...
: 2 3 ; ( which means, define '2' to put 3 on the stack )
: + - ; ( which means, define '+' to execute the '-' word )
1 2 + . ( which would respond with -1 instead of the expected 3)
cheers,
Derek Parnell
dparnell @ bigpond.net.au
Melbourne, Australia
-----Original Message-----
From: Roderick Jackson <rjackson at CSIWEB.COM>
To: EUPHORIA at LISTSERV.MUOHIO.EDU <EUPHORIA at LISTSERV.MUOHIO.EDU>
Date: Sunday, August 15 1999 15:44
Subject: Re: call_back() etc
|I believe the language you're looking for is FORTH. That "feature"
|struck me as incredibly dangerous when I first saw it.
|
||It's beginning to remind me of a programming language (I forget which
one)
||where you could declare variables with the same name as reserved words,
||leading to code like:
||
||for for = to to by by do do
|| print (for)
||next
