NameSpace / Arrows
Hi, there.
No, I'm not going into another good/bad discussion.
I just need some feedback on this experiment (see attached file), and it's in a
way about namespace, and the way we use
variables in general actually.
First I will try to explain my theory as best as I can see it, and then what you
can find in the include file. (though its
merely meant as an experiment)
In the most 'high-level' and 'generalizing' view of programming, what is
happening is:
input >> processing >> output
Nevertheless, the OS you are using (whichever it is), plus your mail program,
etc. can't be easily simplified to that level.
You could say, the processing part is dependent on the context. (with 'the
context' I mean: which program you are using, which
flag-modes you are in, which options you choose in your configuration panel,
etc.). Interestingly, the most annoying part about
any interface is that its not as context-sensitive as humans. The most annoying
part about programming and developing is the
level of specification and details you must tell it. The computer never assumes
anything. So, we develop code-sharing,
libraries, inheritance, etc. But every time only a tiny little bit has to be
different, it seems we have to re-code the whole
entity we call object/control/routine/library. Inheritance only partly solves
this, and unfortunately does this at compile them,
meaning we copied the code.
What if, all processing was defined in such a way, that we could easily, at
run-time, consider a process from unlimited
perspectives, reverse the process or list and completely re-organize the
structure of the program flow, without actually having
to code any of those tiny parts that make up the program.
Input, for example, comes from the keyboard, while the output goes to the
screen. The processing in between is done by some
interface. Notice how we can name things ? Off course, all these basic elements
have names. And the screen accepts information,
while the keyboards gives information. The interface takes and gives. One of the
main performance bottlenecks is the amount of
in-needed taking and giving of such information. I will explain with two real
life examples:
1) When I resize my windows (IE4/5) toolbar, I can see, its all redrawn at
least about 2 or 3 times. Why ? because when the
toolbar resizes, its redrawn, the window is put back on top: redraw, the window
needs to be resized (happens automatically when
I resize my toolbar), it redraws again. And in this redrawing process, twice, it
reloads all icons that are in my explorer
window. It loads and recalculates things, even when it could know its not
needed.
2) My old GFX, now put in shame by the latest graphics libraries like Neil
(and interestingly most programs/demos tend to use
other, slower and truecolor/mode19 graphics libraries.. never quite understood
those choices). Anyway, my old GFX-library was
100% Euphoria code, yet it was pretty fast, giving its videomode
independability, etc. Why ? Because at some points (it could
have been many more), I optimized by only re-calculating screen-offsets, when
their location changes, etc. Calculations most
libraries simply put in their end-loop. This made me think of the command-list
principle. A way of describing a common graphical
task, where the calculations/etc were hidden in the routines that alter the
command list, rather than the one executing it. I
never released (or finished) a command-list enabled version of GFX, but after a
little pushing, Micheal Bolin wrote E-Memcopy
based upon that command-list principle (although most used the
one-element-command-list-wrapper-routine) and Pete evolved it
into his asm-linked-commandlist-system he uses in Neil. The speed advantages
show is the only point, I wanted to make. Although
this mail is not about a new sort of command-list manager, not by far.
As you've hopefully noticed I'm working towards something. Those little part of
processing and IO-devices code have names, and
the order, sequence and direction (forward/reverse) they are called is based
upon a context-sensitive namespace. As to the
forward/reverse thingie... it seems return-values and arguments are the same
thing in a different (fixed) direction, in
Euphoria. When the direction is not fixed, it solves many problems to keep both
one-argument long. Well... one argument or
streaming (think of I/O). Its in theory the same thing, it simply depends on the
actual program flow at run-time. Now for this I
want to be a little more specific. There is a difference in requesting a value,
and pushing a value. For example, the screen
requests information 60 or 70 times per second (depends on your refresh rate),
this information comes from your video memory. We
don't copy a virtual screen to the video memory 60 times a second, do we ? No,
when we copy the virtual screen to the video
memory, we are pushing information. In other words, the actual program flow
during run-time is dependent on IO-devices pushing
information and requesting information. (think of a tube you use to drink a cola
at McDonalds. Data flows from an input device
to an output device eventually. The route is takes doesn't change often, and if
the route can be traced down into a minimal set
of 'filters', optimization can be quite high. When the route does change at
run-time, its merely a matter of jumping around.
This route is that part that fascinates me. In Euphoria we can output
information to the default output channel. This could be a
file or another program but usually is the console. The program is not specific
as to where it wants to sent its data to. Just
sent it to 'the output'. At times we are more specific: send it to the 'screen'
.. or more specifically 'output' , 'screen'.
In the library attached, you can define, and connect different routines based
upon a given path.
A program can output to the soundcard, not needing to know which soundcard, or
which IRQ/DMA. This kind of stuff is
content-sensitive. On the other hand, a program should always have the choice to
address the SoundBlaster directly. Say we have
code to handle the SoundBlaster, the location of this code is defined as: {
"output", "soundcard", "soundblaster" } --
(order specific)
And if this is the only entity defined, all output will go that soundblaster
routine. (without any in-between routines)
But if I defined a routine, which location is: { "output", "soundcard" } it
will be called, when we send information in these
directions:
{ "output" }
{ "output", "soundcard" }
{ "soundcard" }
However, when we send information to:
{"output", "soundcard", "soundblaster" }
{"soundcard", "soundblaster"}
{"output", "soundblaster"}
{"soundblaster"}
It will be sent to the soundblaster routine instead.
Information sent into these directions, will not be send at all:
{"output", "screen"}
-- There is an 'output' defined, but it is not defined as 'screen'
You must by now, have been wondering about 'sending information towards some
direction' .. and this is the whole fundamental of
the new namespace suggestion. One could at any time, write a small routine to
add a reverb effect, and install it for all
programs except those marked as games, by simply writing the routine and
locating it right. It should be ideal for building up
GUI's and programs that have to interact, and integrate as a whole. Some parts
of the system could be profile-specific. For
networking and security the ability to specify which parts of the system can and
can not be accessed. Which parts are different
and which should be the same.
By lack of creativity, I've called the library 'arrows' due to the pseudo-syntax
I've used in my head and on paper using '>>'
and '<<' similar to Euphoria's procedure calls, and function return statements.
They allow the direction-freedom, yet show the
direction of which the initiative comes.
Unfortunately, Euphoria isn't too well on this, and forces a linear programming
order (in any way, you look at it), so
currently, in this experiment, every routine returns a value and gets one
argument. (actually two, the second argument is the
path-sequence, for query reasons)
A dream OS, imo, would handle files, devices, programs, files, etc. in the very
same way. Using this, near db-management system,
of locating any object/entity/code-piece/routine by defining its location when
compares to other object/entities/routine.
Some files are profile-specific, some are accessible to all. Consider this,
pseudo-syntax statement of storing the current image
in your paint program.
{ "mypaintprogram", "image", "location" } << { "driveC", "Pictures" }
Off course I could be much more specific:
{"applications", "mypaintprogram", "myopenproject", "image", "location"} << {
"system", "driveC", "folderlist", "Pictures" }
Or less specific:
{"image", "location"} << {"Pictures"}
In theory the above should work, as long as there isn't any other 'image'
defined or 'Pictures' entity.
Like in life, the risk of not being specific enough, is that what you say, is
mis-interpreted.
The cost of being extremely specific is the lack of flexibility. Example: when
you output to the soundcard, the system chooses
which one that is, and at which IRQ/DMA. (this part if configured, off course).
When you choose the soundcard yourself, you
better be sure you choose the *right* soundcard.
Back to the statement above. The location at driveC, the folder named 'Pictures'
is sent to the location of the image. Which in
its store, stores the location in the normal memory like a variable (you could
call it that), but generates a chain-reaction, if
the file either has changed or hasn't been saved yet, to be stored in the folder
'Pictures'. For this to happen, the initiative
should come from the { "image", "location" }. It should contain a statement
like:
{"data"} >> {"driveC", "folderlist", "Pictures", "myopenproject" }
I don't have to specify {"data"} much further, and this is where things get a
little tricky.
All the time, I've specified 'directions' ... 'locations' from the top-down
point of view. Which is not the same as the view
from somewhere else. The order of search in this cases, is downwards (otherwise
we couldn't specify specific exceptions) like
normally, but then, upwards, each time considering each branch, up to the top.
So, eventually, we will search for 'data' in all
entities.
So, although there will be enough entities, where 'data' is part of the
location, it should be quite obvious, the data of image
is meant. The data most nearby you could say.
Now that I've bored you all enough. Have a look at the library. It allows you to
connect two different entities (routines in our
case).
The only developed part, (the rest is limited by Euphoria), is off course the
finding and choosing of which entity, to use.
Just read the comments to see it in action. I would appreciate some response. I
have a feeling, that like always, I'm
reinventing wheels here.
Even so, the mix with the streaming type of program flow, should be original, as
use in a programming language together with
this context-sensitive namespace-system.
Ralf Nieuwenhuijsen
.... Mailto://nieuwen at xs4all.nl
.... Http://www.xs4all.nl/~nieuwen
.... Uin://9389920
begin 666 arrows.e
M"B @+2T@5&AI<R!S=&]R97,@86QL('1H92!E;G1I='DM:6YF;W)M871I;VX-
M"B @<V5Q=65N8V4@9&(@9&(@/2![>WTL>WTL>WTL>WU]#0H-"B @9G5N8W1I
M;VX@9FEN9%]I=&5M("AS97%U96YC92!P871H*0T*(" M+2!,;V-A;"!R;W5T
M("!I;G1E9V5R('!O<PT*#0H@(" @8V0@/2!D8@T*#0H@(" @9F]R(&EN9&5X
M(#T@,2!T;R!L96YG=&@H<&%T:"D@+3$@9&\-"@T*(" @(" @:71E;2 ]('!A
M=&A;:6YD97A=#0H@(" @("!P;W,@/2!F:6YD("AI=&5M+"!C9%LQ72D-"B @
M(" @(&EF('!O<R!T:&5N#0H@(" @(" @(&-D(#T@8V1;,EU;<&]S70T*(" @
M(" @96QS90T*(" @(" @("!R971U<FX@>WT-"B @(" @(&5N9"!I9@T*#0H@
M(" @96YD(&9O<@T*#0H@(" @:71E;2 ]('!A=&A;;&5N9W1H*'!A=&@I70T*
M(" @('!O<R ](&9I;F0@*&ET96TL(&-D6S%=*0T*#0H@(" @:68@<&]S('1H
M96X-"B @(" @(')E='5R;B![8V1;,UU;<&]S72P@<&%T:" F(&-D6S1=?0T*
M(" @(&5L<V4-"B @(" @(')E='5R;B![?0T*(" @(&5N9"!I9@T*#0H@(&5N
M9"!F=6YC=&EO;@T*#0H-"B @9VQO8F%L(&9U;F-T:6]N(&-O;FYE8W0@*&]B
M:F5C="!I=&5M+"!S97%U96YC92!P871H*0T*(" M+2!#86QL<R!A;F]T:&5R
M92!R971U<FXM=F%L=64-"B @+2T@5VAI8V@@96YT:71Y(&ES(&-H;W-E<R!I
M<R!S<&5C:69I960@8GD@=&AE('!A=&@-"B @<V5Q=65N8V4@<F5T#0H-"B @
M("!R970@/2!F:6YD7VET96T@*'!A=&@I#0H@(" @:68@;&5N9W1H*')E="D@
M=&AE;@T*(" @(" @<F5T=7)N(&-A;&Q?9G5N8R H<F5T6S%=+"![:71E;2P@
M<F5T6S)=?2D-"B @("!E;'-E#0H@(" @(" M+2!E<G)O<@T*(" @(" @86)O
M<G0@*#$I#0H@(" @96YD(&EF#0H-"B @96YD(&9U;F-T:6]N#0H-"B @9G5N
M97%U96YC92!P871H+"!S97%U96YC92!C9"D-"B @+2T@3&]C86P@<F]U=&EN
M92!U<V5D(&)Y('1H92!G;&]B86P@)VYE=R H*2<@<F]U=&EN92!B96QO=PT*
M("!S97%U96YC92!I=&5M#0H@(&EN=&5G97(@<&]S#0H-"@T*#0H@(" @("!I
M=&5M(#T@<&%T:%MI;F1E>%T-"B @(" @('!O<R ](&9I;F0@*&ET96TL(&-D
M6S%=*0T*(" @(" @:68@;F]T('!O<R!T:&5N#0H-"B @(" @(" @:68@:6YD
M97@@/2!L96YG=&@H<&%T:"D@=&AE;@T*(" @(" @(" @(&-D6S%=(#T@87!P
M96YD*&-D6S%=+"!P871H6VEN9&5X72D-"B @(" @(" @("!C9%LR72 ](&%P
M<&5N9"AC9%LR72P@>WM]+'M]+'M]+'M]?2D-"B @(" @(" @("!C9%LS72 ]
M(&%P<&5N9"AC9%LS72P@:60I#0H@(" @(" @(" @8V1;-%T@/2!A<'!E;F0H
M8V1;-%TL('M]*0T*(" @(" @("!E;'-E#0H@(" @(" @(" @8V1;,5T@/2!A
M<'!E;F0H8V1;,5TL('!A=&A;:6YD97A=*0T*(" @(" @(" @(&-D6S)=(#T@
M+'M]+'M]+'M]?2DI#0H@(" @(" @(" @8V1;,UT@/2!A<'!E;F0H8V1;,UTL
M(&ED*0T*(" @(" @(" @(&-D6S1=(#T@87!P96YD*&-D6S1=+"!P871H6VEN
M9&5X*S$N+FQE;F=T:"AP871H*5TI#0H@(" @(" @(&5N9"!I9@T*(" @(" @
M("!R971U<FX@8V0-"@T*(" @(" @96YD(&EF#0H-"B @(" @(&EF(&EN9&5X
M(#T@;&5N9W1H*'!A=&@I('1H96X-"B @(" @(" @8V1;,UU;<&]S72 ](&ED
M#0H@(" @(" @(&-D6S1=6W!O<UT@/2![?0T*(" @(" @("!R971U<FX@8V0-
M"B @(" @(&5N9"!I9@T*#0H@(" @("!C9%LR75MP;W-=(#T@<F5C=7)?;F5W
M("AI9"P@:6YD97@@*R Q+"!P871H+" @8V1;,EU;<&]S72D-"B @(" @(')E
M='5R;B!C9 T*("!E;F0@9G5N8W1I;VX-"@T*#0H@(&=L;V)A;"!F=6YC=&EO
M;B!N97<@*&]B:F5C="!I9"P@<V5Q=65N8V4@<&%T:"D-"B @+2T@4F5G:7-T
M(&QO8V%T:6]N#0H-"B @("!I9B!S97%U96YC92 H:60I('1H96X-"B @(" @
M(&ED(#T@<F]U=&EN95]I9" H:60I#0H@(" @96YD(&EF#0H-"B @("!I9B!I
M9" ]("TQ('1H96X-"B @(" @(')E='5R;B Q("TM(&5R<F]R#0H@(" @96YD
M(&EF#0H-"B @("!F;W(@:6YD97@@/2 Q('1O(&QE;F=T:"AP871H*2!D;PT*
M(" @(" @9&(@/2!R96-U<E]N97<@*&ED+" Q+"!P871H6VEN9&5X+BYL96YG
M=&@H<&%T:"E=+"!D8BD-"B @("!E;F0@9F]R#0H-"B @("!R971U<FX@, T*
M#0H-"B @:6YC;'5D92!G970N92 @(" M+2!N965D960@9F]R('=A:70M:V5Y
M#0H-"B @<')O8V5D=7)E(&-H96-K7VEN<'5T("@I#0H@("TM(%1H:7,@<F5A
M="!O=71P=70@;W(@=&AE(&-O;G-O;&4-"B @+2T@4')E<W-I;F<@96YT97(@
M;"!M86ME(&ET(&-O;FYE8W0-"B @+2T@('1O(&-O;G-O;&4@=VAE;B!I="!W
M97)S82X-"@T*("!I;G1E9V5R(&-H87(L(&9L86<-"B @;V)J96-T(&1U;6UY
M#0H-"B @("!P=71S("@Q+" B7&Y<=%!R97-S(&%N>2!K97D@=&\@<V5E('1H
M#0H@(" @<'5T<R H,2P@(EQT4')E<W,@97-C87!E('1O('%U:70@=&AE('!R
M;V=R86U<;B(I#0H@(" @<'5T<R H,2P@(EQT4')E<W,@96YT97(@=&\@<W=I
M(BD-"B @("!P=71S("@Q+" B7'0H86QT:&]U9V@@=&AE>2!I;B!F86-T+"!T
M;R!T:&4@<V%M92!T:&EN9RE<;B(I#0H@(" @<'5T<R H,2P@(EQT*'1H92!P
M92!C:&]S96XI7&Y<;B(I#0H-"B @("!F;&%G(#T@, T*#0H@(" @=VAI;&4@
M,2!D;PT*#0H@(" @("!C:&%R(#T@=V%I=%]K97D@*"D-"B @(" @(&EF(&-H
M87(@/2 R-R!T:&5N#0H@(" @(" @(&%B;W)T("@Q*0T*(" @(" @96QS:68@
M8VAA<B ](#$S('1H96X-"B @(" @(" @9FQA9R ](&YO="!F;&%G#0H@(" @
M("!E;F0@:68-"B @(" @(&EF(&9L86<@=&AE;@T*(" @(" @("!D=6UM>2 ]
M(&-O;FYE8W0@*&-H87(L('LB;W5T<'5T(GTI#0H@(" @(" @("TM('1H97-E
M('=O<FL@87,@=V5L;#H-"B @(" @(" @+2T@9'5M;7D@/2!C;VYN96-T("AC
M:&%R+"![(G-C<F5E;B)]*0T*(" @(" @(" M+2!D=6UM>2 ](&-O;FYE8W0@
M*&-H87(L('LB;W5T<'5T(BP@(G-C<F5E;B)]*0T*(" @(" @96QS90T*(" @
M(" @("!D=6UM>2 ](&-O;FYE8W0@*&-H87(L('LB;W5T<'5T(BPB8V]N<V]L
M92)]*0T*(" @(" @(" M+2!T:&ES('=O<FMS(&%S('=E;&PZ#0H@(" @(" @
M("TM(&1U;6UY(#T@8V]N;F5C=" H8VAA<BP@>R)C;VYS;VQE(GTI#0H@(" @
M("!E;F0@:68-"@T*(" @(&5N9"!W:&EL90T*#0H@(&5N9"!P<F]C961U<F4-
M=65N8V4@<&%T:"D-"B @+2T@3W5T<'5T<R!T;R!T:&4@<V-R965N#0H-"B @
M("!P=71S("@Q+" B7&Y38W)E96X at *&1E9F%U;'0I.B!!4T-)22U#:&%R86-T
M97(Z("(@)B!I=&5M("8@(EQN(BD-"B @("!P=71S("@Q+" B(" @(" @(" @
M(" @(" @(" @05-#24DM5F%L=64Z("(I#0H@(" @<')I;G0@*#$L(&ET96TI
M#0H-"B @("!R971U<FX@," M+2!D=6UM>2!V86QU90T*("!E;F0@9G5N8W1I
M;VX-"@T*("!F=6YC=&EO;B!C;VYS;VQE7V]U='!U=" H;V)J96-T(&ET96TL
M#0H@(" @<'5T<R H,2P@(EQN0V]N<V]L93H at 05-#24DM0VAA<F%C=&5R.B B
M("8@:71E;2 F(")<;B(I#0H@(" @<'5T<R H,2P@(B @(" @(" @($%30TE)
M+59A;'5E.B B*0T*(" @('!R:6YT("@Q+"!I=&5M*0T*#0H@(" @<F5T=7)N
M(# @+2T@9'5M;7D@=F%L=64-"B @96YD(&9U;F-T:6]N#0H-"B @:68@;F5W
M8W)E96XB?2D@=&AE;@T*(" @('!U=',@*#$L(")"860A(BD@(" @+2T@<F]U
M=&EN92UI9"!W87,@8F%D#0H@(&5N9"!I9@T*#0H@(&EF(&YE=R H<F]U=&EN
M95]I9" H(F-O;G-O;&5?;W5T<'5T(BDL('LB;W5T<'5T(BP@(F-O;G-O;&4B
M?2D@=&AE;@T*(" @('!U=',@*#$L(")"860A(BD@(" @+2T@<F]U=&EN92UI
M"B @+2T@5&AI<R!C86X@8F4@<VEM<&QY(&]V97)R:61D96XL(&)Y(&-A;&QI
M;F<Z#0H-"B @(" @(" @+2T@:68@;F5W("AR;W5T:6YE7VED("@B8V]N<V]L
M95]O=71P=70B*2P@>R)O=71P=70B?2D@=&AE;@T*(" @(" @(" M+2 @('!U
M=',@*#$L(")"860A(BD-"B @(" @(" @+2T@96YD(&EF#0H-"B @+2T@5VAE
M86QL(&]U='!U="!W:6QL(&=O('1O('1H92!C;VYS;VQE#0H@("TM(" @(&5X
M(G-C<F5E;B)](&]R('LB<V-R965N(GT-"B @+2T@0W5R<F5N=&QY+"!A;&P@
M<F5C="!I= T*(" M+2 @("!T;W=A<F1S.B![(F]U='!U="(L(")C;VYS;VQE
=96YT#0H@(&-H96-K7VEN<'5T("@I#0H-"@T*#0H`
`
end
|
Not Categorized, Please Help
|
|
