Re: Euphoria Interpreter design
>>And dare I say it, again, I can order a program much better (much more
>>logical) that Euphoria could ever force me (or you).
>
>Ok, how would that be? Here's the way I try to order my programs:
Well, Ive attached a couple of projects to a person mail.
Try to consider such projects in your order scheme and feel free to respond on
the list-sever.
(I just didnt want to puke my attachments all over the list-server..)
But sometimes 'subject' is an order as well.
Say, File IO - constants, routines, and other declerations packed together.
String manipulation routines packed together,
key-association routines packed together.
In such an order, its order, not in *how* it is implemented
(type/constant/routine) but *what* it relates to and *what* it does.
How the interpreter handles and orders it.. that its own case.
>Sometimes some constants come after globals (ie a sin and cos lookup table
>is faster as a constant, but I need a temp variable to store it until I
>assign it to the consant), but overall this works. If I want a low-level
>routine, like drawing the status bar, I look near the top of my code.
>(Actually, I should look in an include file... oh well.) I know that the
>low-level routines can't call the main routine, etc. Euphoria's way of doing
>things currently has not hindered me at all, but hasn't particularly helped
>me, either.
I havent even began to give some serieus examples of things that just dont work,
without modifying external libraries.
I once tried to make a sort of 'basic' api / say standard for general purpose
graphics library, in such way you would only have
to write a modeX specific library contain some declerations and a few routines,
but the end-program wouldnt know the difference.
Palettes, virtual screens manager, graphical output, etc. were all different
include files. That all followed a certain standard
(and use one general library that manages all the registrations of routines and
machine code). The whole thing had to be OO.
There was simply no 'elegant' way, to have the parts interact this way. Since,
there had to be some logical order. What comes
first, the graphical output ? the palette ? the dos-font ? etc.
Actually the order would be different for each configuration. Never found a
clean way.
Then Pete came out wiht his magic library, that simply supported all modes and
types, and handled all that. It had no point for
me to continue. Im suprised though, that I never seen many games and demos use
Neil.
>Now, I'm not saying your way is bad, I just want to see it so I can want to
>use it, too.
Order is not fixed. Its depends on what you do. But why, could some one, tell me
why, linear order is the best choice for *all*
situations. If its not, the restriction has to go. So you could choose to force
linear, rather than being forced to.
Oh, and for all those that didnt get me, when I used the word 'leech' .. eh.. I
meant leash. (thank you David).
Ralf
|
Not Categorized, Please Help
|
|
