World: r3wp

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.

elixir already has that built-in to its values, so any gadget also 
inherit their "flawlessness" but its not something that jumps at 
you... its a subtle but oh so important detail.

so, my answer to DideC, I guess, is:  

Give me ideas on simple demo applications I can build ! 

And I'll consider which one I do first.  :-)


 I need and want this info to make the whole package more appealing 
 and comprehensible.  The current uber simple Sum example, just gives 
 a glimpse of the engine's capabilities, not of its application.

Brian asks, "Can you map nodes to physical world objects?"

I'd need a bit more explanation of what you mean by that.

Sorry if that was confusing. Most of my code has no user interface 
at all. It runs without intervention. Any monitoring or command interface 
is seperate. Most of my data points correspond to physical objects 
in the real world, and the code mostly tracks and directs these objects.

yes that would be easy (figuratively speaking) now it obviously depends 
on the nature of your interfaces and what you track...

but liquid would allow you to pregrogram any matter of "alerts" based 
on specific conditions, for example.

which will be triggered whenever you want to be aware of things...

the nice thing is that you don't have to want to be aware of everything.. 
so whatever is not interesting will not cause *much* processing.

and won't trigger other events.

my next step for liquid (what I was working on During the devcon, 
but wasn't able to get done do to lack of sleep) was the creation 
of liquid net.

basically a connection based TCP i/o interface to any liquid network. 
 you define the ports, the protocol (on either end) and can then 
interface your Dataflow across machines  :-)  it would allow distributed 
processing without any understanding of such concepts.

obviously, the standard issues of machine redundancy will arise, 
but that is a good exercise for the later revisions of the system.

so one (actually several)  machines can be a controler and synchronise 
to others which can also locally change their states... and whatever 
they data can generate can be sent to any other machine, including 
the controlers... so you have ONE kernel to handle all aspects of 
your systems.  and its dead easy... and would interface directly 
within any other liquified systems like liquid GL, elixir, globs, 
or eventually GLASS.

want text ports, just make a liquid which spues out text on the console... 
need that logged, just plug in another node which spues out stuff 
on disk as it comes in... but you don't even have to change anything 
in your systems... and can even easily connect your logger to other 
nodes, so you can track the flow of traffic, or the end effects some 
root events are having on the outputs of the system.  sometimes its 
not obvious to see the real world relation of inputs and output... 


liquid allows you inspect all states at all points in time of you 
system's processing and compare it.

and actually generate other data from it  like diffs or comparison 
reports. :-)

you can figure out that out of 10 systems, one is actually contributing 
to most of the indirect unwanted outputs.