OpenEuphoria

Re: NameSpace / Arrows

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

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