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
|
Not Categorized, Please Help
|
|
