World: r3wp

Single process, no virtual memory - through other tricks, they managed 
to avoid needing it. Because of this the event broadcast, like everything 
else it did, ran by itself on the bare metal. Hence the speed.

Gabriele, liquid (dataflow) adds a level of stability to any project. 
 the fact that its lazy pays off very well so far.

the system in its current form is not meant to be easy to code  (for 
maintenance reasons).  I know many ways to change this, but before 
going to far, I had to have as stable an architecture as possible.

I have gone through 3 rewrites before hitting this sweetspot.  other 
versions might have been simpler in a way, but left the system, non 
generic and unscalable in one of many different ways.

liquid's strength lies in the fact that it is generic.  we all write 
dataflow within our applications, without realising it.  but we then 
recode each little system in its own isolated architecture.  this 
means we just loose a lot of time.

I was able to write elixir in about 40-50 hours of time and the only 
bugs it has are within the parts of code which has no dataflow.  
everytime I trust liquid and switch part of the code to it, I end 
up forgetting about that part, because it gets to be so stable.

I am as anxious as all of you and understand ALL of your qualms about 
using dataflow and liquid. 
 *complexity?
 *speed?
 *scalability?
 *difference in programming model
 * ....

The truth is, I do not have the reflex of using liquid for most of 
my coding, still, but actuall exposure and use, is forcing me to 
value its effect on my code.  this is empiric use, not advocacy. 
 If you could see just how easy it was for me to build fully bug-free 
AGG gadgets in so little time, you'd understand.


its not about just sharing data between gadgets, its about allowing 
your code to know what's going on.

and in fact, if we do add a measure of reflexivity to VID, we will 
just be redoing most of liquid, or run in the same issues, I had 
in my other prototypes, which led to this design.   ;-)

but we will not gain the advantage of having generic dataflow!

max: liquidgl is push based, isn't it? so "lazy" does not count.

nope, its all using the same core plug.  so its really pull based.

the only difference is that some (switcheable in real time, even 
set to a function) which will always want to refresh, when they are 
aware of data changes.

when you move a slider that is attached to something, is that something 
that has to pull? does it pull x times a second?

its also nice to know that your GUI is actually capable of reflecting 
data.  not just gui.  change the data:

fill data value


and don't even have to wonder IF and HOW any gadget should change.

that is push, isn't it?

 does it pull x times a second?

that is up to you to decide, really.

my decision is not to pull at all, if something changes the change 
is pushed to everything that needs to know.

at a high level yes.  but in reality, no.  if you have some gadgets 
or other parts of dependent systems which do not "need" the value, 
it might not cause any refresh.

that doesn't scale well.

(tested)

that really is just like an action.

exactly, just an action, or to say it differently, just an event.

but you are only seeing all of this as a VID thing.

dataflow has nothing to do with GUI.

we only need it for the gui - that's exactly my point

its something the whole language should have.

nope.

noone stops people from including liquid

cause you do not see its value if it where built in.

;-)

especially since its such a small kernel !  (not the current implementation, 
which has a few prototypical stuff left)

liquid is small, but the functionality we needs comes free with my 
vid design, so you can't win ;)

you see, if we had a dataflow datatype, we would not even need to 
talk about "do we add this to VID"  people could just set values 
to attributes which are DF based.

but I know your POV.  but you don't see how limited that becomes. 
 we could have what you propose and ALSO have full DF.

it wont remove what you propose... and in fact its not even more 
complex in use.

full df, sure, but no reason to have it builtin.

if we had to put everything that is cool built in, rebol would be 
10mb like many other languages.

eg, should pdf maker be built in? of course not!

hum liquid is what 50 kb of 0% optimised code.  DF its a data processing 
kernel, paradigm level feature.. quite different in scope.

Hi Max, reading the %liquid.r source code from rebol.org, I've found 
a typo at line 948 : count plug/subordnates object!  (i missing in 
"subordnates").

Hi Max,

Do you have any demo apps using liquid ? Something simple, but usefull 
to help me (and others) understand how and when to use it.

Hi doc, The version of liquid on line is not quite the latest (obviously)... 
 but I'll check out your info... its possible that one was already 
fixed.... I fixed a few minor bugs  since I last released.  Mainly 
due to intense use within glob and elixir.

dideC: well, I'm am working towards that.  I am keeping up the habit 
of working on one thing at a time and currently I'm hard at work 
on Revault.  that being said... guess what are the first libs to 
be put online  ;-)

elixir is a proof of concept generating application... I am still 
measuring how well the generalised use of Liquid in all aspects of 
an application equate to all of my claims, but so far, empiricaly... 
it seems to be keeping up the intended benefits.

unfortunately, demo apps are still not available.  One person using 
liquid is making a for profit dentist EMR and scheduling app.  there 
is elixir, and there was the original liquified draw dialect example 
I had released just before the new year.

I have a pretty nifty parse-rule generating application which uses 
liquidGL but its far to complex to be used for understanding of anything.

once revault is at least put to demo on line and I start getting 
feedback, I will turn to liquid fullblast...  what I am really looking 
for are examples of simple apps which can be liquified.

the real problem is also that dataflow usually improves larger systems. 
 so small demos might not illustrate the particular merits of using 
liquid, unless you count in the subjective, bug free, nature of most 
DF systems.

I do want to convert rebolek's famous color picker into using liquid... 
one of the thing which will be made better is the fact that I can 
sample colours from mouse events much more often than actual refreshes 
occur, so that it should feel smoother.

I think the best, simple illustration of liquid will be in making 
an unbreakable form example.