NameSpace / Arrows
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Mar 22, 1999
- 681 views
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