1. Macro & Shrouding
Shrouding
~~~~~~~~
Shrouding should never be a problem for any1.
Restrictions of variable lengths are not needed.
In future versions of Euphoria, shroud.ex should first search all
identifiers, and their positions and lengths, and then replace all of them
with the new assigned.
That shroud.ex now currently has a problem with a short global variable is a
case of bad programming. No offence.
Simply make a list of all identifiers, and their positions and lengths, and
then assign new identifiers, that are not in the list. Furthermore, simply
never mess with globals, it makes routine iD work, shrouded libs and
understanding an .err dump. Especially when encryption is done, this isn't
a worry.
Marco's
~~~~~~
Macro's are used for clarity, not speed. Speed is something ex.exe needs to
worry about, not the programmer.
Considering speed, there's only 1 thing that ex.exe will never know how-to,
and that's what to optimize at the cost of what. Their are some points in a
program where speed isn't as important as other points. In those moments
some advanced optimization can be done. Maybe by supplying an "optimize"
keyword before a routine declaration, or a for/while loop. A loop declared
with optimize, makes Euphoria prepare for the loop before it gets there.
Before a routine declaration it makes the routine inline. Example:
--
value_first = wait_key ()
value_second = wait_key ()
--
optimize while 1 do
x = wait_key () + value_first * 200
y = wait_key () + value_second * 200
--
optimize for index = 1 to length(text) do
position (lookupy[power(x,y)],lookupx[power(x,y)])
puts(1, text[index])
end for
--
end while
--
Consider the above piece of code, value_first & second need to
multiplied only once, instead of every time. Optimize makes this happen, the
x/y lookup with the x to the y-th power should also be calculated before the
for-loop and only when the user has hit different keys. (thus only when x or
y changes, we need to recalculate the power)
It would be super if power was only used when x changes, because when y
changes, it is a matter of small power.
(Example: ...power(2,5) = power(2,3) * power(2,2), and when we already
know power(2,3), it is faster to multiply that value with power(2,2) than it
is to completely recalculate power(2,5)... )
I suppose we don't really need an optimize keyword, since every program
will run faster when we optimize every inner loop, in its outer space.
(prepare as much as you can before we hit the loop)
For routine declaration I think, it is handy, but that decision can also
be made by ex.exe (number of occurrences & routine length should be the
factors considered)
However we could inline any routine, we should also have to keep a
separate routine version for use with routine iD's.
And what about optimize options, like optimize recalculation (only
recalculate what changes), optimize routines (inline small routines and/or
use pass-through variables, when we store it in an argument given), optimize
loops, optimize slicing, etc.
With pass-through optimizations (optimize routines) consider this as an
example:
--
function my_func (sequence s)
-- do a lot of code, so inlining isn't smart
-- Change the value of s
return s
end function
--
text = my_func (text)
--
In the above example, text is a pass-through variable and if Euphoria
handles it like that, it could save a lot of copying (when s changes, the
changes sequences are saved)
And one other thing.
All this is speed optimization, but we might want to memory optimize a
program (or Euphoria decides to optimize for memory at the cost of speed, so
SLOW virtual memory doesn't have to be used)
Also a big optimization for both memory and speed, is having a byte as
smallest integer value. (copying goes faster)
Or (what is easier and ever more helpful) optimize sequence with only byte
values (values beneath 256) as a string-sequence. But when one value changes
type (to an integer, atom or sequence) it is converted to a sequence.
Ralf
(wondering how many people actually reach to the end of this long mail 8-)
