Re: Rob: List?
CChris wrote:
> > 2. provide non-blocking I/O support to assist multitasking
> >
>
> Could you elaborate on this? If it means that Eu gets at last a set of file
>
> xplat commands which are not blocking, this is a welcome development.
> How would a progress or completion status for a I/O command be reported?
I haven't decided exactly how it will work, but Linux and Windows
have API calls that let you start some I/O, and then check a variable
or memory location to detect when it has finished. Meanwhile you can
do other things, rather than getting blocked at that point.
> > 3. Incorporate Daniel's multi-threaded non-blocking WIN32 API calls
> >
>
> Seems to overlap 2) above.
> Also, isn't it simpler to extend the semantics of
> "integer" to cover what ALL language around do, ie machine size integers
> (32 or 64 bit according to host hardware)?
I have no idea what integers have to do with non-blocking API calls,
but Euphoria's integers only use 31 bits, because (effectively)
there is a bit that says "this is not an integer, it's
a pointer to a larger object". Most other languages don't have
dynamic "larger objects" like Euphoria's sequences.
> And why do this in Windows only
> then? Looks like a half baked thing.
If it turns out to be easy, why not?
> > 6. front-end optimization of temps - fewer temps gives better performance
> >
> > 7. try again to speed up scanning/parsing/emiting (front end)
> Are you sure the time you'll spend in these tricky optimisations will not
> outweigh the sum of all execution time gains achieved through them?
> Perhaps most Eu users still use 486s or older, in which case these are
> relevant.
>
> If not, see my final comments.
>
> > 8. Translator optimizations:
> > - translator: if a call_proc/call_func has an argument sequence where
> > all the elements are known to be integers, we shouldn't bother to
> > emit Ref's on the elements
> >
> > - could easily optimize code generation for compare() in translator
> >
>
> Ok, these are probably useful. When I *really* (and rarely) need raw speed,
>
> I directly code in C if asm is not an option. Here again, are these little
> optimisations worth your efforts?
When you optimize code you always run into diminishing returns.
You start off making some impressive improvements in speed with
very little effort. Eventually you start expending a lot of coding
effort just to shave 1% off the time. It's a judgement call
that I will have to make.
> Development and testing time is much larger than execution time,
> except for very specific tasks. Hence I would have welcome anything that makes
> Euphoria more flexible when it comes to coding, since bugs usually arise in
>
> the translation from the developer's goals and the constrained extent of what
>
> an interpreter can understand.
>
> But nothing in the above suggests any move towards this direction:
>
> - No provision for having a better control on what is, or is not, in
> namespaces,
> and specially in the unnamed one where all global symbol live;
I don't want to open the namespace issue.
I suspect most people don't use it, and don't fully understand it,
let alone wish to see it become more complicated.
> - No provision to allow passing arguments as reference to routines;
I have no desire to do that.
Euphoria should be based on values, not locations that can be
pointed-to and changed in subtle indirect ways.
> - No provision to allow more practical, yet structured, control over execution
> flow,
> which could take the form of:
> * optional argument to the exit statement: exit n loops/exit the loop with
> this
> label
> * a continue statement (skip remainder of current iteration)
> * a retry statement (restart current iteration)
> * a select (or switch, or inspect...) statement to handle multiple choices
There's nothing really wrong with adding a bunch of new control-flow
statements. It's simply my philosophy that Euphoria should have a
small number of control-flow statements. That might bother some
professional programmers in some instances, but will ease the
burden on beginners and hobbyists.
> Also, I really think some integrated tool to manage context switch in
> multitasked environments is needed, because the same library may be queried
>
> by different tasks "at the same time", ie while some not shareable data is
> being used. Most OSes know about thread vars, this could be the simplest way
>
> to go. Except DOS admittedly.
When more people start using multitasking, we'll have
a much better idea of what additional features are needed.
Note that I probably won't implement all of these features.
I could back out of something if it looks harder or
less useful than I thought at first. Also, I'm sure
I'll end up doing some other things that aren't on this list.
Regards,
Rob Craig
Rapid Deployment Software
http://www.RapidEuphoria.com
|
Not Categorized, Please Help
|
|
