1. Comments on ORAC
Obviously this is all just my opinion, and when it comes across as harsh, that
is probably just because it is 
1) Implemented as a preprocessor:
Madness, utter madness.
I accept you are invested, but I suspect you know I am right: STOP
Regroup, figure out your goals, and use your head.
I've been here and done this: if you are determined you will find a way
to use the stuff you have learned to your advantage. It may take time.
2) Conditional compilation:
Good, and VERY BAD.
DEBUG=0->1 is an example of Good.
Linux vs Windows is an example of WRONG (one .il works on both = good).
HLL statements to do this = VERY BAD:
function f()
puts(1,"compiler asks")
return find(wait_key(),"aA")
end function
if f() then
include zA.e
else
include zB.e
end if
Remember this is just my opinion, point is there are cases galore.
You could probably prove me wrong round about here
3) include/global mods:
GOOD
I've agreed with MWL on similar, what would be cool is something that
could suggest best possible changes "include"/"include global" wise.
4) comparison ops:
I predict you just got this badly wrong from a true language semantics
point, but as you said it is ultimately tweakable, and not something
that would particularly worry me.
(It all depends on exactly how you treat eg (a=b)=(c=d), where for
simplicity of argument, a,b,c,d are all seqs of length 3 or 4)
<as point 2>
5) Improved syntax:
Dot notation. We like.
Indirect routine calls:
I think you missed a trick here.
Impossible from a pre-processor angle, but what if routine_id did +1,
and c_func/c_proc did +1 on the _same_ counter? Therefore c_func would
be the faster/better route, missing a wrapping level, but call_func
would (accept one sequence parameter and) achieve the same result?
Auto-increment constants. We like, lots.
Humbling how simple that is.
I would use "infix notation" rather than "native operators", prolly just me.
abs: Note that nested "|" may need additional round brackets, eg "|a + |b||"
will not compile properly, but "|a + (|b|)|" would be fine.
~s Hmm: I personally dislike, but that sort of thing would be good as an
"alias '~'=length(%1)" sort of thing?
On the macro side, macros can (quite rarely imo) be pretty cool, but you
MUST at least have a "-pp=expand_macros -out=x.exw" option so you can
figure out/trace(1) what the pig is going on.
You also wrote:
"Perhaps some kind person will volunteer to write a <ahem> simple utility
that can translate the names in the error file back into their original form.."
Should you steadfastly ignore what I said in point 1 (just my opinion) and
grant me the means, I hereby volunteer to make Edita do this.
Lastly, incremental compilation seems a total cop-out to me. That said, while
2.4 did not need it, imo 2.5 and later do
Regards,
Pete
2. Re: Comments on ORAC
Pete Lomax wrote:
> Obviously this is all just my opinion, and when it comes across as harsh, that
> is probably just because it is
>
> 1) Implemented as a preprocessor:
> Madness, utter madness.
> I accept you are invested, but I suspect you know I am right: STOP
> Regroup, figure out your goals, and use your head.
You are right. A pre-processor (of this nature) for Euphoria is a bad idea. BUT,
you need to know
that I have been working on Orac since about the time you investigated FASM -
years.
To convert the half-finished Eu-to-C translator that Orac is into a pp took
about a month.
Orac (as a pp) is a stepping stone to a greater goal.
> 2) Conditional compilation:
> Good, and VERY BAD.
> DEBUG=0->1 is an example of Good.
> Linux vs Windows is an example of WRONG (one .il works on both = good).
> HLL statements to do this = VERY BAD:
> }}}
<eucode>
> function f()
> puts(1,"compiler asks")
> return find(wait_key(),"aA")
> end function
>
> if f() then
> include zA.e
> else
> include zB.e
> end if
> </eucode>
{{{
> Remember this is just my opinion, point is there are cases galore.
> You could probably prove me wrong round about here
This example would fail in Orac.. was that your intention? I couldn't work it
out, sorry
> 3) include/global mods:
> GOOD
> I've agreed with MWL on similar, what would be cool is something that
> could suggest best possible changes "include"/"include global" wise.
>
> 4) comparison ops:
> I predict you just got this badly wrong from a true language semantics
> point, but as you said it is ultimately tweakable, and not something
> that would particularly worry me.
> (It all depends on exactly how you treat eg (a=b)=(c=d), where for
> simplicity of argument, a,b,c,d are all seqs of length 3 or 4)
All comparisons return a boolean value, no more {1,1,0,1,0,0,1,0,0}
As you have tested for yourself, these sequence ops are almost never used in
"real" code but many times we want to do: if a = "name" then....well, now we can
- nice!
Oh. BTW, what does Backward Compatibility mean? I never really knew what that
was..
.. does someone have a dictionary..?
> <as point 2>
>
> 5) Improved syntax:
> Dot notation. We like.
> Indirect routine calls:
> I think you missed a trick here.
> Impossible from a pre-processor angle, but what if routine_id did +1,
> and c_func/c_proc did +1 on the _same_ counter? Therefore c_func would
> be the faster/better route, missing a wrapping level, but call_func
> would (accept one sequence parameter and) achieve the same result?
If we could do: xDeleteObject(hWnd) well, that would be just great. If someone
could please tell me how to detect the difference between an integer that is the
result
of a dll link and an integer that is a routine_id - I'll happily use it.
IF, one day I wake up AND feel like getting beaten up, instead I'll hack Orac to
trace
the result of machine_func(M_DEFINE_C,...) *backwards* to a target constant so
that
I can plug in the correct calls as above.
> Auto-increment constants. We like, lots.
> Humbling how simple that is.
>
> I would use "infix notation" rather than "native operators", prolly just me.
noted.
> abs: Note that nested "|" may need additional round brackets, eg "|a + |b||"
>
> will not compile properly, but "|a + (|b|)|" would be fine.
Hey, yeah! I'll update the docs...
>
> ~s Hmm: I personally dislike, but that sort of thing would be good as an
> "alias '~'=length(%1)" sort of thing?
It was a vestige of the Eu-to-C system that I decided to keep. I would have
used it to get the size of a structure (~~ = size in bytes, ~ = unit length).
Please just ignore it.
> You also wrote:
> "Perhaps some kind person will volunteer to write a <ahem> simple utility
> that can translate the names in the error file back into their original
> form.."
> Should you steadfastly ignore what I said in point 1 (just my opinion) and
> grant me the means, I hereby volunteer to make Edita do this.
Thank you very much for that. Ok. I'll send info to you shortly on how to access
the Symbol Table and also convert mangled names into their true form.
> Lastly, incremental compilation seems a total cop-out to me.
Euphoria does almost everything in one pass of the code. Orac requires many
passes but
this was the only way to achieve the more complex semantics. Eventually, even
more passes
will be added to Orac, therefore, parsing times will increase. The ultimate goal
for
Orac is to be a direct Eu-to-C translator that has start-up times equivalent to
those
of an interpreter. Now, I imagine that Incremental Compilation is a good tool
for
achieving that goal. In the docs I suggest that the *parsing* time for a large
program
could be reduced to 10%.
IMO, there is no reason why Orac could not be used for very large apps written
by teams
of programmers. IC is not needed for Arwen-sized apps but when it will be
needed, it will
be a life-saver.. or have I just made a big mistake in my thinking on this?
> that said, while
> 2.4 did not need it, imo 2.5 and later do
>
> Regards,
> Pete
Mike
3. Re: Comments on ORAC
Umm, I need to rethink some of this..
I wrote:
>
> Pete Lomax wrote:
>
> > 3) include/global mods:
> > GOOD
> > I've agreed with MWL on similar, what would be cool is something that
> > could suggest best possible changes "include"/"include global" wise.
The next version will feature something like this..
> The ultimate goal for Orac is to be a direct Eu-to-C translator
The _original_ plan was an E2C translator but now it could easily be something
else.
>.. that has start-up times equivalent to those of an interpreter.
Alas, there is still somethig wrong with just having a straight compiler.
A debugging tool (like an interpreter) would be a valuable asset. What if
an interpreter were built directly into Orac? The execution speed would be
much slower than normal Euphoria programs but the start-up time would be
virtually instant - even for large programs.
Mike
4. Re: Comments on ORAC
Mike wrote:
>
> Orac (as a pp) is a stepping stone to a greater goal.
OK, good to know.
>
> > 2) Conditional compilation:
> This example would fail in Orac.. was that your intention? I couldn't work it
> out, sorry
My bad, I really meant to say conditional compilation is only useful for fixed
literal constants, such as "constant ASSERT=1" then "if ASSERT then", and/or
stripping out assert() and trace() statements, but not conditional includes imho.
In the docs you listed:
* OS version string/{type,major,minor}
* Current video mode
* Screen size (text-mode)/resolution (graph mode).
* Current printer flags: technology (laser, inkjet, dot-matrix), PCL, etc..
* dpi values for screen and printer
* keyboard layout string
* Locale string or id
* Unicode support (current CP should be enough)
Now, if *ANY* of those were applied in the next public release of Edita, or
wxEuphoria, not too many people would likely be happy.
In other words I am not inspired with confidence by a system that proposes to do
such things, and given the choice I would disable such permanently.
>
> Oh. BTW, what does Backward Compatibility mean? I never really knew what
> that was..
> .. does someone have a dictionary..?
I think it means suitable for retarded people 
> > Indirect routine calls:
> If we could do: xDeleteObject(hWnd) well, that would be just great. If
> someone
> could please tell me how to detect the difference between an integer that is
> the result
> of a dll link and an integer that is a routine_id
CChris might know whether it is possible to merge the routine_id and c_func
tables in the backend or not.
Alternatively, why not just add say #30000000 to define_c_proc results,
#20000000 to define_c_func, and #10000000 to routine_ids of procedures?
Hence if and_bits(n,#20000000) then it is a C routine else an Eu one,
and if and_bits(n,#10000000) then it is a procedure else a function,
and mask these things with #0FFFFFFF before use.
Regards,
Pete
5. Re: Comments on ORAC
Pete Lomax wrote:
>
> Mike wrote:
> >
> > Orac (as a pp) is a stepping stone to a greater goal.
> OK, good to know.
> >
> > > 2) Conditional compilation:
> > This example would fail in Orac.. was that your intention? I couldn't work
> > it out, sorry
> My bad, I really meant to say conditional compilation is only useful for fixed
> literal constants, such as "constant ASSERT=1" then "if ASSERT then", and/or
> stripping out assert() and trace() statements, but not conditional includes
> imho. In the docs you listed:
> * OS version string/{type,major,minor}
> * Current video mode
> * Screen size (text-mode)/resolution (graph mode).
> * Current printer flags: technology (laser, inkjet, dot-matrix), PCL, etc..
> * dpi values for screen and printer
> * keyboard layout string
> * Locale string or id
> * Unicode support (current CP should be enough)
> Now, if *ANY* of those were applied in the next public release of Edita, or
> wxEuphoria, not too many people would likely be happy.
> In other words I am not inspired with confidence by a system that proposes to
> do such things, and given the choice I would disable such permanently.
> >
Really?
Granted, the video config isn't the best example; availability of such or such
video mode on the host machine, or hysical cpabilities of this or that device, is
probably more useful.
You can easily unerstand that some libraries won't be the same in an ANSI or
Unicode context, or according to the command language a printer understands, etc.
Rather than having monolithic libraries that need to handle it all, it is much
cleaner to have one librry per relevant configuration and include it
conditionally. Sounds like implementing virtual methods? Yes, it makes much
simpler to maintain and extend.
> > Oh. BTW, what does Backward Compatibility mean? I never really knew what
> > that was..
> > .. does someone have a dictionary..?
> I think it means suitable for retarded people
>
Agreed.
> > > Indirect routine calls:
> > If we could do: xDeleteObject(hWnd) well, that would be just great. If
> > someone
> > could please tell me how to detect the difference between an integer that is
> > the result
> > of a dll link and an integer that is a routine_id
>
> CChris might know whether it is possible to merge the routine_id and c_func
> tables in the backend or not.
>
> Alternatively, why not just add say #30000000 to define_c_proc results,
> #20000000
> to define_c_func, and #10000000 to routine_ids of procedures?
>
> Hence if and_bits(n,#20000000) then it is a C routine else an Eu one,
> and if and_bits(n,#10000000) then it is a procedure else a function,
> and mask these things with #0FFFFFFF before use.
>
Merging is probably doable - there are always some pitfalls in merging things
that are not processed in exactly the same way. I'd suggest rather using the
lower 2 bits to stand for func vs proc and routine_id vs defined_c_routine. Basic
indexes would increment by 4, and getting the table offset would be done by a
fast >>2.
Ability to tell these characteristics from simple inspection of the id would
have greatly simplified my http://oedoc.free.fr/Fichiers/ESL/function.zip
package.
CChris
> Regards,
> Pete
6. Re: Comments on ORAC
CChris wrote:
>
> Pete Lomax wrote:
> >
> >
> > My bad, I really meant to say conditional compilation is only useful
> > for fixed literal constants, such as "constant ASSERT=1" then
> > "if ASSERT then", and/or stripping out assert() and trace() statements,
> > but not conditional includes imho. In the docs you listed:
> > * OS version string/{type,major,minor}
> > * Current video mode
> > * Screen size (text-mode)/resolution (graph mode).
> > * Current printer flags: technology (laser, inkjet, dot-matrix), PCL, etc..
> > * dpi values for screen and printer
> > * keyboard layout string
> > * Locale string or id
> > * Unicode support (current CP should be enough)
> > Now, if *ANY* of those were applied in the next public release of
> > Edita, or wxEuphoria, not too many people would likely be happy.
> > In other words I am not inspired with confidence by a system that
> > proposes to do such things, and given the choice I would disable such
> > permanently.
Heh. You *can't* turn off Unicode in wxEuphoria. Nyah nyah.
In fact, I think that you shouldn't even allow those. A cleaner solution
is probably to add some sort of command line switch to the interpreter:
$ exu -dDEBUG=1 myapp.ex
$ ecu -dDEBUG=1 myapp.ex
#if DEBUG=1 include libdebug.e
#else include librelease.e
#if DEBUG=1 assert()
Of course, the backend, bound and translated executables don't take any
special switches, since those decisions have all been made already. I
was actually just thinking about adding this concept of interpreter level
command switches this morning, specifically for extending the EUINC path:
$ exu -i$EUDIR/include/somelib myapp.ex
We'd probably want to do something creative with the result of
command_line(). I'd suggest stripping out the interpreter level stuff,
and maybe adding a new built in like interpreter_switch() or something
in order to access those options.
>
> > > Oh. BTW, what does Backward Compatibility mean? I never really knew what
> > > that was..
> > > .. does someone have a dictionary..?
> >
> > I think it means suitable for retarded people
>
> Agreed.
I guess I really am special like my mom always told me.
> > > > Indirect routine calls:
> > > If we could do: xDeleteObject(hWnd) well, that would be just great.
> > > If someone could please tell me how to detect the difference between
> > > an integer that is the result of a dll link and an integer that is
> > > a routine_id
> >
> > CChris might know whether it is possible to merge the routine_id and
> > c_func tables in the backend or not.
> >
> > Alternatively, why not just add say #30000000 to define_c_proc results,
> > #20000000
> > to define_c_func, and #10000000 to routine_ids of procedures?
> >
> > Hence if and_bits(n,#20000000) then it is a C routine else an Eu one,
> > and if and_bits(n,#10000000) then it is a procedure else a function,
> > and mask these things with #0FFFFFFF before use.
>
> Merging is probably doable - there are always some pitfalls in merging things
> that are not processed in exactly the same way. I'd suggest rather using the
> lower 2 bits to stand for func vs proc and routine_id vs defined_c_routine.
> Basic
> indexes would increment by 4, and getting the table offset would be done by a
> fast >>2.
I don't see any benefit to merging the tables. You still have a check
to see what type of thing you're dealing with, but you've inflated the
required memory usage.
If you simply add something on the high bit, it's still a fast operation
to convert: id & 0x1fffffff (or whatever the correct value would be) to get
the location in the table.
Matt
7. Re: Comments on ORAC
Pete Lomax wrote:
> > > Indirect routine calls:
> > If we could do: xDeleteObject(hWnd) well, that would be just great. If
> > someone
> > could please tell me how to detect the difference between an integer that is
> > the result
> > of a dll link and an integer that is a routine_id
>
> CChris might know whether it is possible to merge the routine_id and c_func
> tables in the backend or not.
>
> Alternatively, why not just add say #30000000 to define_c_proc results,
> #20000000
> to define_c_func, and #10000000 to routine_ids of procedures?
>
> Hence if and_bits(n,#20000000) then it is a C routine else an Eu one,
> and if and_bits(n,#10000000) then it is a procedure else a function,
> and mask these things with #0FFFFFFF before use.
>
> Regards,
> Pete
I'm part way through enhancing Orac to detect these cases.
It actually doesn't seem to be all that difficult now.
It'll work for Arwen, wxEuphoria or any library that assigns the
c_func/proc id directly to a constant.
It probably won't work for win32lib. Oh well..
Mike
8. Re: Comments on ORAC
Pete Lomax wrote:
>
> Obviously this is all just my opinion, and when it comes across as harsh, that
> is probably just because it is
>
-- snip
> 5) Improved syntax:
> Dot notation. We like.
> Indirect routine calls:
> I think you missed a trick here.
> Impossible from a pre-processor angle, but what if routine_id did +1,
> and c_func/c_proc did +1 on the _same_ counter? Therefore c_func would
> be the faster/better route, missing a wrapping level, but call_func
> would (accept one sequence parameter and) achieve the same result?
Pete,
FYI
This is working now In Orac. I couldn't detect any increase in parsing time
either
However, I've restricted it to work only for constants that are associated with
functions that eventually lead back to the specific machine_func() call that
links to a dll. I'll send an update to the Recent Contributions page in a few
days.
Some may find it useful..
Mike
9. Re: Comments on ORAC
Mike wrote:
> However, I've restricted it to work only for constants that are associated
> with
> functions that eventually lead back to the specific machine_func() call that
> links to a dll.
Any further thoughts on using the #30000000 mask idea to eliminate that
restriction?
Regards,
Pete
10. Re: Comments on ORAC
Pete Lomax wrote:
>
> Mike wrote:
> > However, I've restricted it to work only for constants that are associated
> > with
> > functions that eventually lead back to the specific machine_func() call that
> > links to a dll.
>
> Any further thoughts on using the #30000000 mask idea to eliminate that
> restriction?
>
> Regards,
> Pete
Sorry Pete. A mask would only be useful if the Euphoria internals were modified
to natively support (what I refer to as) seamless calls. If such a modification
were done, there'd be no need for what I just did to Orac.. ummm, it would be a
better solution - for sure. Unfortunately, I'm not one of the few people
talented
enough to do this adjustment. What I've done is a compile-time analysis,
whereas,
a mask is a run-time flag.
Now, if the Euphoria internals were modified to have said mask, Orac could only
take advantage of this for routines called as procedures since it'd have to emit
some "if" statements. Therefore, routines called as functions (in an expression)
just wouldn't work.
However, I can easily extend Orac to include integers assigned at the top-level
(just like the constants are). This might reduce the remaining deficiency to
tolerable levels. The thing about integers, of course, is that they can be
re-assigned at run-time so all sorts of effects are possible. And yet, perhaps
the easiest idea is simply to add a declaration specifier that tells the
compiler
how to treat "seamless calls" with that particular reference, eg:
dll_proc int DeleteObject
.. the integer is assigned somewhere at runtime
DeleteObject(hWnd) // it works!
The analysis that Orac does is to automatically deduce whether a symbol will be
used
as a function reference for an indirect call. But all I really need to know
is what did the programmer intend the symbol to be used for. Well, a specifier
would do it. In fact, 2 specifiers - one for C functions and one for C
procedures,
say, dll_proc and dll_func.
I could take this idea a little bit further by permitting any data type to be
used,
so that a sequence could therefore be the reference, eg:
dll_func seq gdi
gdi = repeat(0, ..)
gdi.1 = c_func(..
gdi.2 = c_func(..
gdi.3 = c_func(..
..
gdi.2(987) // also works!
The numbers shown here can all be replaced by constant names and, as you know,
the auto-numbering of Orac can be used to make this very easy (and safe).
I think this idea would achieve pretty much all we'd need for now without having
alter Euphoria itself.
regards,
Mike
11. Re: Comments on ORAC
Mike wrote:
>
> Pete Lomax wrote:
> >
> > Mike wrote:
> > > However, I've restricted it to work only for constants that are associated
> > > with
> > > functions that eventually lead back to the specific machine_func() call
> > > that
> > > links to a dll.
> >
> > Any further thoughts on using the #30000000 mask idea to eliminate that
> > restriction?
> >
> > Regards,
> > Pete
>
> Sorry Pete. A mask would only be useful if the Euphoria internals were
> modified
> to natively support (what I refer to as) seamless calls. If such a
> modification
> were done, there'd be no need for what I just did to Orac.. ummm, it would be
> a
> better solution - for sure. Unfortunately, I'm not one of the few people
> talented
> enough to do this adjustment. What I've done is a compile-time analysis,
> whereas,
> a mask is a run-time flag.
>
> Now, if the Euphoria internals were modified to have said mask, Orac could
> only
> take advantage of this for routines called as procedures since it'd have to
> emit
> some "if" statements. Therefore, routines called as functions (in an
> expression)
> just wouldn't work.
I think you're overcomplicating this. Since you're writing a preprocessor,
you just need to create a global function and a global procedure, something
like:
global function call_indirect_function( integer func, sequence args )
if and_bits( func, C_FUNC_INDIRECT ) then
return c_func( and_bits( func, ROUTINE_MASK ), args )
elsif and_bits( func, EU_FUNC_INDIRECT ) then
return call_func( and_bits( func, ROUTINEMASK ), args )
end if
-- error handling here...
end function
Matt
12. Re: Comments on ORAC
Matt Lewis wrote:
>
> I think you're overcomplicating this. Since you're writing a preprocessor,
> you just need to create a global function and a global procedure, something
> like:
> }}}
<eucode>
> global function call_indirect_function( integer func, sequence args )
> if and_bits( func, C_FUNC_INDIRECT ) then
> return c_func( and_bits( func, ROUTINE_MASK ), args )
>
> elsif and_bits( func, EU_FUNC_INDIRECT ) then
> return call_func( and_bits( func, ROUTINEMASK ), args )
> end if
> -- error handling here...
> end function
> </eucode>
{{{
>
Yep, that is what I meant. I also knew that the work Mike has just done allows
eg constant r_id=routine_id("eu_func") ... call_func(r_id,{}), when there was no
other use of r_id, to be left as-is, so I let him get on with that part first.
But if r_id gets used elsewhere, ie stored in some larger structure, esp a mix of
eu/c func/proc, then:
r_id = define_c_func(blah)
...
s[j] = {r_id,x,y,z}
...
s[k].1(blahblah) -- a "void = " may be needed(/autoinserted) here
...
void = c_func(r_id,blah3)
==>
r_id = or_bits(define_c_func(blah),CFUNC)
...
s[j] = {r_id,x,y,z}
...
orac_proc(s[k].1,blahblah)
...
void = c_func(and_bits(r_id,MASK),blah3)
where orac_proc is the sister routine of the one Matt just posted:
global procedure orac_proc(integer id, object args)
integer isFunc, isC
isFunc = and_bits(id, FUNCTION)
isC = and_bits(id, CCALL)
id = and_bits(id, MASK)
if isFunc then
if isC then
void = c_func(id,args)
else
void = call_func(id,args)
end if
else
if isC then
c_proc(id,args)
else
call_proc(id,args)
end if
end if
end procedure
By all means avoid using such wrappers when you possibly can.
I also believe it would be quite trivial to (later) change the back end to set
such bits in define_c_func/proc & routine_id, and completely ignore them in
call_/c_ func/proc. At the last minute I changed a "+CFUNC" above to or_bits() to
ease this. All existing code should work unaltered, unless doing something very
strange like call_func(r_id+1,{}), and even that would probably still work in
most cases.
Regards,
Pete
13. Re: Comments on ORAC
Matt Lewis wrote:
>
> Mike wrote:
> > Now, if the Euphoria internals were modified to have said mask, Orac could
> > only
> > take advantage of this for routines called as procedures since it'd have to
> > emit
> > some "if" statements. Therefore, routines called as functions (in an
> > expression)
> > just wouldn't work.
>
> I think you're overcomplicating this. Since you're writing a preprocessor,
> you just need to create a global function and a global procedure, something
> like:
> }}}
<eucode>
> global function call_indirect_function( integer func, sequence args )
> if and_bits( func, C_FUNC_INDIRECT ) then
> return c_func( and_bits( func, ROUTINE_MASK ), args )
>
> elsif and_bits( func, EU_FUNC_INDIRECT ) then
> return call_func( and_bits( func, ROUTINEMASK ), args )
> end if
> -- error handling here...
> end function
> </eucode>
{{{
>
> Matt
Hi Matt,
Now why didn't I think of that, :-o Yes, that would work. However, routines
called as procedures would need to be encapsulated in a function call since
it won't be known beforehand if a func or proc is being referenced. Orac
allows (normal) functions to act like procedures so, to be consistent, that
should be possible for indirect functions too. To the programmer it'll all
look the same so it had better act the same.
Therefore, the mask requires 2 pieces of info: indirect vs dll and func vs
proc.
This throws up a subtle gotcha: Since indirect calls of both kinds could be
treated as functions, what happens if a procedure is inadvertently used in
an expression? The code will work but be wrong.
I think a bit mask would be a good idea if Euphoria were fully modified to
*natively* support seamless calls. But if this were done in conjunction with
Orac the code analysis it does now would still need to be done in order to be
able to optimize certain calls - as Pete suggested.
But since indirect calls will always be slower than direct ones, is there really
any point to optimizing? If not, then, there is no point to analysing the code
either. I have no qualms about suspending the code I've just written - it's a
hack anyway.
If this mask were added to Euphoria, what (other than Orac) could take
advantage of it? I would feel uncomfortable if Euphoria were modified just
to suit Orac - particularly when I'm inclined to something else.
IMO, an easier solution is simply to add a specifier to a variable/constant
declaration. I am going to do this shortly unless someone can convince me
otherwise with very persuasive arguments.
Mike
14. Re: Comments on ORAC
Mike wrote:
>
> Matt Lewis wrote:
> >
> > Mike wrote:
>
> > > Now, if the Euphoria internals were modified to have said mask, Orac could
> > > only
> > > take advantage of this for routines called as procedures since it'd have
> > > to
> > > emit
> > > some "if" statements. Therefore, routines called as functions (in an
> > > expression)
> > > just wouldn't work.
> >
> > I think you're overcomplicating this. Since you're writing a preprocessor,
> > you just need to create a global function and a global procedure, something
> > like:
> > }}}
<eucode>
> > global function call_indirect_function( integer func, sequence args )
> > if and_bits( func, C_FUNC_INDIRECT ) then
> > return c_func( and_bits( func, ROUTINE_MASK ), args )
> >
> > elsif and_bits( func, EU_FUNC_INDIRECT ) then
> > return call_func( and_bits( func, ROUTINEMASK ), args )
> > end if
> > -- error handling here...
> > end function
> > </eucode>
{{{
> >
> > Matt
>
>
> Hi Matt,
>
> Now why didn't I think of that, :-o Yes, that would work. However, routines
> called as procedures would need to be encapsulated in a function call since
>
> it won't be known beforehand if a func or proc is being referenced. Orac
> allows (normal) functions to act like procedures so, to be consistent, that
> should be possible for indirect functions too. To the programmer it'll all
> look the same so it had better act the same.
>
> Therefore, the mask requires 2 pieces of info: indirect vs dll and func vs
> proc.
>
> This throws up a subtle gotcha: Since indirect calls of both kinds could be
> treated as functions, what happens if a procedure is inadvertently used in
> an expression? The code will work but be wrong.
>
> I think a bit mask would be a good idea if Euphoria were fully modified to
> *natively* support seamless calls. But if this were done in conjunction with
> Orac the code analysis it does now would still need to be done in order to be
> able to optimize certain calls - as Pete suggested.
>
> But since indirect calls will always be slower than direct ones, is there
> really
> any point to optimizing? If not, then, there is no point to analysing the code
> either. I have no qualms about suspending the code I've just written - it's
> a hack anyway.
>
> If this mask were added to Euphoria, what (other than Orac) could take
> advantage of it? I would feel uncomfortable if Euphoria were modified just
> to suit Orac - particularly when I'm inclined to something else.
>
> IMO, an easier solution is simply to add a specifier to a variable/constant
> declaration. I am going to do this shortly unless someone can convince me
> otherwise with very persuasive arguments.
>
>
> Mike
If there is a way - whichever it is - to tell from an id what it refers to -
function vs procedure, indirect Eu vs external - then there would be no need for
c_proc() vs call_proc(), since any of them would do the right thing. So the
change would simplify the language.
Having the index in the indirect call table being different from the id returned
to programmer isn't much of a problem, since the conversion would be fast -
either shifting or anding -.
CChris
15. Re: Comments on ORAC
CChris wrote:
>
> If there is a way - whichever it is - to tell from an id what it refers to -
> function vs procedure, indirect Eu vs external - then there would be no need
> for c_proc() vs call_proc(), since any of them would do the right thing. So
> the change would simplify the language.
> Having the index in the indirect call table being different from the id
> returned
> to programmer isn't much of a problem, since the conversion would be fast -
> either shifting or anding -.
>
CChris:
If Euphoria did multipass parsing; then allot of routine_id complications
could be handle internally by the interpeter.
That would go along way to simplify the language.
Bernie
My files in archive:
WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
Can be downloaded here:
http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan
16. Re: Comments on ORAC
Mike wrote:
>
> Matt Lewis wrote:
> > }}}
<eucode>
> > global function call_indirect_function( integer func, sequence args )
> > -- error handling here...
> > end function
> > </eucode>
{{{
> This throws up a subtle gotcha: Since indirect calls of both kinds could be
> treated as functions, what happens if a procedure is inadvertently used in
> an expression? The code will work but be wrong.
As above, I think it will crash pdq, in an elegant way if you want.
> But since indirect calls will always be slower than direct ones, is there
> really
> any point to optimizing? If not, then, there is no point to analysing the code
> either. I have no qualms about suspending the code I've just written - it's
> a hack anyway.
I assumed part of your plan involved (eg) arwen + orac, and the extra layer
round all message handling routines would probably be quite noticeable.
> If this mask were added to Euphoria, what (other than Orac) could take
> advantage of it? I would feel uncomfortable if Euphoria were modified just
> to suit Orac - particularly when I'm inclined to something else.
While I have no real example, there is clearly something quite powerful with
seamless calls. True, you could achieve much the same effect by storing
routine_ids and and define_c_func results along with an explicit tag, and
non-orac uses of this idea would need to hand-code and hand-call a version of
call_indirect_function().
> IMO, an easier solution is simply to add a specifier to a variable/constant
> declaration. I am going to do this shortly unless someone can convince me
> otherwise with very persuasive arguments.
The only remotely relevant existing examples I can thing of are the vHandler
table in win32lib, and the HandlerRoutine sequence in arwen. Both those happen to
be homogenous (all Eu functions), so a single specifier at the variable level
would probably work. But equally I could imagine someone wanting to replace
some-but-not-all of them with c routines in a dll...
Regards,
Pete
17. Re: Comments on ORAC
Bernie Ryan wrote:
>
> CChris wrote:
> >
> > If there is a way - whichever it is - to tell from an id what it refers to -
> > function vs procedure, indirect Eu vs external - then there would be no need
> > for c_proc() vs call_proc(), since any of them would do the right thing. So
> > the change would simplify the language.
> > Having the index in the indirect call table being different from the id
> > returned
> > to programmer isn't much of a problem, since the conversion would be fast -
> > either shifting or anding -.
> >
>
> CChris:
>
> If Euphoria did multipass parsing; then allot of routine_id complications
>
> could be handle internally by the interpeter.
>
> That would go along way to simplify the language.
>
> Bernie
>
> My files in archive:
> WMOTOR, XMOTOR, W32ENGIN, MIXEDLIB, EU_ENGIN, WIN32ERU, WIN32API
>
> Can be downloaded here:
> <a
> href="http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan">http://www.rapideuphoria.com/cgi-bin/asearch.exu?dos=on&win=on&lnx=on&gen=on&keywords=bernie+ryan</a>
True. However, this leads to non optimal use of memory (too many cache misses).
I didn't test what the performance penalty would be, but I'm afraid it would be
noticeable.
Fortunately, this is not needed. You may check the modified interpreter which
ships with Orac to see how to handle forward references, and avoid 80-90% of all
call_func/call_proc/routine_id calls altogether.
CChris
