1. NameSpace / Arrows
- Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL>
Mar 22, 1999
-
Last edited Mar 23, 1999
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
2. Re: NameSpace / Arrows
Your example looks a lot like Unix pipes. But how about handling real-time
data streaming? Here's a trivial example - I want to set a file to upper
case:
file.txt > uppercase.app > upper.txt
If the data was non-realtime, you could send over the whole file. But if it
was streamed, you would have to send the data over in chunks - presumably in
byte-size pieces.
Now, I want to change all the keys to uppercase, so I set up the pipeline:
keyboard > uppercase.app > stdio
So far, so good - you can stream the data one byte at a time. But what about
sorting?
file.txt > sort.app > sorted.txt
This only makes sense on non-streamed data. After all, you can't sort the
data until it's all accumulated. Here's a parallel example using your
soundcard example:
file.wav > reverb.app > soundcard
could work with streamed data. On the other hand:
file.wav > reverse.app > soundcard
would not.
Another complexity of streamed data is that different applications chunk
different kinds of data into different sizes. For example, I have an
application which 'composes' MIDI files. It creates a text file, which is
converted into a MIDI file:
compose.app > text2midi.app > file.mid
It would be nice to set up a rendering pipeline like:
compose.app > text2midi.app > render.app > reverb.app > soundcard
Now, obviously the file cannot be rendered in real time, since the first two
processes are not realtime. For the sake of discussion, I'll imagine that
'>' indicates a non-streamed output (passed a whole file at a time), and
'>>' indicates a streamed output (passed a chunk at a time). The pipeline
could be built:
compose.app > text2midi.app >> render.app >> reverb.app >> soundcard
So the compose application generates an entire file, and passes that file to
the text2midi application. That program processes the file, and send the
output one chunk at a time (presumably in byte-size chunks) to the render
application. The render application takes chunks of text in, and in real
time converts them into chunks of waves (say, in 500ms size chunks). These
chunks of waves are passed on to the reverb application, which added reverb
to the chunks in real time and passes the processed chunks to the soundcard
application, which builds a buffer and outputs the stream of sound.
So, assuming that you deal with real-time streaming by 'chunking' data into
bite-size pieces, this leads to the question how data is moved through the
pipeline. Is it pushed through by the leftmost application, or pulled
through by the rightmost application based on demand?
Since there are different kinds of data in the pipeline, the 'chunks' in
data size don't match up. It can sometimes take a lot of ASCII data to
describe a wave of sound, such as a stream of numbers that describe a sin
wave:
sin_wave.app >> text2wave >> soundcard
or a few characters, such as a stream of MIDI commands:
file.mid >> render.app >> soundcard
Another issue with real-time streaming is that you have to timeslice between
the parts of the pipeline. If you decide to slice each time a process has
generated a 'chunk' of data, then the soundcard will be starved for data
before long. Seems like each node would need to be able to signal when it
needed information, and have to track buffers, and other Real Complicated
Stuff.
Add to the the fact the the user may want to redirect several devices, and
you have a multitasking timesliced environment. Do you really want to write
a multitasking Euphoria?
Leaving streaming out, you are left with something a lot easier to implement
- but much less interesting.
-- David Cuny
3. Re: NameSpace / Arrows
Thank you for the feedback, David.
First of all, a clarification, it was _not_ a suggestion for a future version
of Euphoria.
My experiment and associated thoughts were offered for feedback, since I'm
lost, but have the feeling there's something to be
found in this direction. I've wrote the library, for myself, to get a little
more grip and concrete examples and to show the
context-sensitive namespace method.
And ICON's streaming syntax is still going through my head. First of all, lets
try to position what I had in mind.
Unlike Euphoria, I would see this as a declarative or 'conditional' language.
(hoping those terms mean, what I think they do)
You give, the relationship between certain elements, in terms of how data is
processed between different 'entities'.
Does this mean a multitasking environment ? No, at least, not preemptive.
This may confuse you, so I'll start to explain a few things, I left out:
The streaming syntax is consistent used throughout. Eventually, a program
consists of many little entities. A minimal set of
processors and operators. Like a routine in Euphoria hides a lot of code, in the
same way a lot of 'pipes'/'streams' are hidden
behind an expression like:
compose.app > text2midi.app > file.mid
Secondly, data does not move. Code pointers move at the most. At the end,
compose.app and text2midi.app do not have access
to the data. Just like you don't have access to the data in Euphoria. You are
only allowed to tell the system, what you want it
to do with the data.
The actual management, streaming/copying/processing/calculating is in hands
of the system. I believe that a minimal set of
basic 'instruction's that handle datatype-shape, calculations and boolean
expressions will allow for great optimization.
Also, we don't drive data through the program. (like driving a car through a
city). We prepare a route, and simplify that
route. Before we do anything, the route from the input till the output is
prepared. Those few places where we might need to take
alternative paths, can be settled with just a few pointers to jump around and
set.
The flowing is _lazy_. There is no need for processing if it doesn't have
any result in the output. No need to drive in to a
dead-end alley is there ?
This should answer the question of time-handling/slicing. The program flow
is thus pretty linear. There is no need to worry
about 'push' or 'pull' of data. Not both shall be needed. Either of two can take
the initiative for a connection. Let me explain
this further. We only need to redraw the mouse when we move the mouse. When we
move the mouse, the mouse device pulls. (it
always pulls), if the position has changed, a chain-reaction automatically
occurs. The keyboard device pulls, and new keys are
put in the stack. The program however, is not given the keys. It can, on its own
initiative pull the keys from the stack.
Initiative is not an issue. Things are pushed, resulting a chain reaction, or
things are pulled when they are needed. Consider a
spinning cube example. The rendering happens on request of the window. Which
wants to know its graphical data, because its
pushed into the video memory.
> Add to the the fact the the user may want to redirect several devices, and
> you have a multitasking timesliced environment. Do you really want to write
> a multitasking Euphoria?
I must agree, its close to multi-tasking.
However, except for the input devices such as mouse and keyboard, the program
flow is linear.
Because of the lazyness of the system, you will need some constantly pulling
device (screen -- video memory) or constantly
pushing device (mouse/keyboard), however, how mutli-tasking will this be ? We
have a basic loop, not much different from any
event-based system. In this basic loop, we check the keyboard, mouse, etc. and
data is pushed when needed, and pulled upon
request.
> Leaving streaming out, you are left with something a lot easier to implement
> - but much less interesting.
I agree, the context-sensitive namespace is not effective in the way we
currently use variables and routines.
Ralf
5. Re: NameSpace / Arrows
It seems to be the normal behavior of unix: each command works with three
"devices" even when not specified, that are stdin (standard input), stdout
(standard output) and stderr (standard error). They all default to
"console".
Redirection and pipes apply to these devices, by connecting the output
stream
of a command to the input stream of the second. Any file or pipe can be
used.
I prefer to keep the unix syntax to remain clear. If you write:
file.txt > uppercase.app > upper.txt
it seems that file.txt is a command. To do that in real life, you will
write:
cat file.txt | capitalize -u > upper.txt
"cat" takes all his arguments (here "file.txt") as files and put them on his
stdout.
mainly used to conCATenate files like : cat one.txt two.txt > total.txt
capitalize is a filter, it takes a stream (a character flow) as his stdin,
computes
and put the result on stdout. without the redirection it would go to the
screen.
and more, if you write:
... > upper.txt the file is created
... >> upper.txt the output is appended to the existing file
... >! upper.txt force to overwrite, without warning
... >>! upper.txt force to create, without warning
it is important to distinguish commands and filters. a filter must have an
input
stream, and doesn't matter what it is. The first example could be written
this way:
capitalize -u < file.txt > upper.txt
the problem is that many programs are both, according how you use
them. for example, wc (word count) gives the number of lines, words and
chars of a file.
prompt) wc laser1.html
595 1809 27916 laser1.html
it is a command. if you dont give a file name, he will read stdin (the
keyboard)
and wait a ctrl-d (end of file). but you can also do:
prompt) cat laser1.html | wc
595 1809 27916
then it is a filter, and it doesn't know what file it computes, it sees only
his stdin.
That is clearer when you take more files: ("?" is the joker, for one char.)
the two cases give:
prompt) wc laser?.html
595 1809 27916 laser1.html
593 1820 27454 laser3.html
593 1831 27484 laser4.html
1781 5460 82854 total
prompt) cat laser?.html | wc
1781 5460 82854
Filters are used as you mentioned, to create new devices for other programs.
they are used a lot to make printers, there is a file called printcap that
describes
for each printer name, on which host it is, which device to use an what
filter to
apply so that you cat have any formatting or translating there.
I prefer not to mention how you handle with stderr, there are many
possibilities to
add or separate from stdout, and they differ according to the shell you use.
But what I must say is that these streaming and redirecting applies to
Everything,
it is maybe the most important feature of unix.
and if you want to have fun, you can do
ls > /dev/audio to "hear" the listing of the current directory
or
csh | rev
which launches a new shell, but REVerts all its output!
(type exit to get out)
6. Re: NameSpace / Arrows
----- Original Message -----
From: Raude Riwal <rauder at THMULTI.COM>
To: <EUPHORIA at LISTSERV.MUOHIO.EDU>
Sent: dinsdag 23 maart 1999 12:33
Subject: Re: NameSpace / Arrows
> It seems to be the normal behavior of unix: each command works with three
> "devices" even when not specified, that are stdin (standard input), stdout
> (standard output) and stderr (standard error). They all default to
> "console".
> Redirection and pipes apply to these devices, by connecting the output
> stream
> of a command to the input stream of the second. Any file or pipe can be
> used.
Yes, but the idea wasn't about unix, or how it handles such things on
application/file level.
I was talking about streaming from input till the eventual output, throughout
every tiny corner of the program.
> it is important to distinguish commands and filters. a filter must have an
> input
> stream, and doesn't matter what it is. The first example could be written
> this way:
Command / filter distinguishments ?
In the experiment I gave you, commands would be extra specifictions given.
Like sending it to the soundcard-soundblaster rather than just to the soundcard.
This is what you would call 'commands' but I feel comparing it to unix, is the
wrong way.
Unix is just a set of linear programmed programs that run independently, and
happen to use a common interrupt that handles
default input and output, which results in an OS which allows you to specify
sources for those in- and out- put.
And currently, this is something Euphoria already can do.
> But what I must say is that these streaming and redirecting applies to
> Everything,
On *top* level, and only for *file* IO.
Programs still run independently, and call the file io/soundcard, etc.
themselves.
Im talking programs run in source-code form, non-executables, that together
integrate into this OS.
Programs not assuming or forcing any program flow. Conditional type language
thus, rather than over-featured-macro-assembler
C and its brother C++.
Ralf N.
nieuwen at xs4all.nl
ralf_n at email.com
