OpenEuphoria

Re: NameSpace / Arrows

• Posted by Ralf Nieuwenhuijsen <nieuwen at XS4ALL.NL> Mar 23, 1999
• 608 views

----- 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