From: Kenny Tilton
Subject: Interfaces 'r Us
Date: 
Message-ID: <3DD5117A.2060609@nyc.rr.com>
Dave,

Guess what? I had been thinking recently that one way for me to leverage 
my Cells stuff would be to take contracts to provide great interfaces 
for other peoples' projects. Then you call asking if I want to do the 
interface for your project. Scary.

:)

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd

From: cr88192
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <utaq4r2if9o402@corp.supernews.com>
Kenny Tilton wrote:

> Dave,
> 
> Guess what? I had been thinking recently that one way for me to leverage
> my Cells stuff would be to take contracts to provide great interfaces
> for other peoples' projects. Then you call asking if I want to do the
> interface for your project. Scary.
> 
out of curiosity (I did not see it really explained well in the other 
threads, that or I forgot), what is "cells"?...

I have not been able to find any info on it...

-- 
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD58B87.1090906@nyc.rr.com>
cr88192 wrote:
> 
> out of curiosity (I did not see it really explained well in the other 
> threads, that or I forgot), what is "cells"?...
> 
> I have not been able to find any info on it...
> 

SourceForge kicked my ass for me, so I never got it set up there. I'll 
see if my fancy new web site builder will let me upload PDFs for y'all 
to download.

I have some doc, tho one of them is pretty hairy: I deliberately push 
the envelope of Cells so anyone playing with them on their own will know 
how to react to the diagnostics that pop up when one goes out of bounds.

While I am hacking away at my site, from the "Cells Overview":

In Brief
--------
Cells let you define selected slots of CLOS instances as if they were 
cells in a spreadsheet. As with spreadsheet cells, a cell slot (cell, 
for short) can have bound to it a literal value or a formula. The 
formula is any Lisp form which, when wrapped in a suitable macro, enjoys 
access to anaphoric variables �self (the CLOS instance of the slot) and, 
via the macro (cached-value), the most recent value calculated by the
formula.

If a rule dynamically accesses another cell, a dependency is 
automatically recorded. Each time a rule runs the dependencies are 
re-evaluated, so a branching rule may depend on different cells from 
time to time.

When a cell changes, all cells dependent on that cell are recalculated. 
This eager evaluation cascades recursively from one used value to its 
multiple users, recursively through the dependency graph until one of:

� terminating at a computing cell which recomputes the same value as 
last time, despite the changed inputs, such as the many radio buttons 
that recompute �off� after each radio change.

� terminating at a computed cell which does in fact change value, but 
which value no one uses. Such a cell would exist for its echo, if not by 
mistake.

� if it loops back to itself propagating recursively to smUsers. no 
error is signal if the cell is defined to be cyclic (details below).
though if any recalculated cell happens to come up with the same value 
as before, propagation does not continue to its dependents.

The user may define callback echo functions to be invoked when a cell 
changes. Echo functions are called before propagation to other cells. 
For example, a cell for the color slot of a widget has an echo method 
which triggers a screen update so the new color gets shown.

Echo functions are the output of the overall model. Input to the model 
is achieved by setting special variable cells to information culled from 
OS events. So the dataflow goes:

OSevent procedurally -> cell variable -> ruled cells dependent on the 
cell variable -> ruled cells dependent on ruled cells. other dataflow 
is: any given cell procedurally (in echos) -> OS outputs

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: Kenny Tilton
Subject: Cells On-line (woo-hoo!) [Was Re: Interfaces 'r Us]
Date: 
Message-ID: <3DD5A672.3090704@nyc.rr.com>
Kenny Tilton wrote:
> 
> 
> cr88192 wrote:
> 
>>
>> out of curiosity (I did not see it really explained well in the other 
>> threads, that or I forgot), what is "cells"?...
>>
>> I have not been able to find any info on it...

    http://www.tilton-technology.com/

OK, you can now dl two docs or a zip with the same docs /and/ the 
source. Now I need to go back and really emphasize that everything there 
is in a shambles, some of it only works with ACL, etc etc. Basically 
there was an upheaval and I have not finished sorting it all out.

But at least reading the doc and even some of the source (as suggested 
on the site) will tell you a /lot/ about cells.

And I will be delighted to take emails and answer questions.

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: Aleksandr Skobelev
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <m3d6p57ntr.fsf@list.ru>
Kenny Tilton <·······@nyc.rr.com> writes:

> 
> If a rule dynamically accesses another cell, a dependency is
> automatically recorded. Each time a rule runs the dependencies are
> re-evaluated, so a branching rule may depend on different cells from
> time to time.

Sorry, it is not clear for me what 'rule' means here. Is it a synonym for
'formula'? And what does 'rule dynamically accesses' mean?

> The user may define callback echo functions to be invoked when a cell
                               ^^^^
> changes.

What a nice name for callback function! It is always was a "problem" for
me to find short and expresive names for callbacks. 'echo' can serve very
good as a part of such names. So, thank you. :)
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD671E3.5070101@nyc.rr.com>
Aleksandr Skobelev wrote:
> Kenny Tilton <·······@nyc.rr.com> writes:
> 
> 
>>If a rule dynamically accesses another cell, a dependency is
>>automatically recorded. Each time a rule runs the dependencies are
>>re-evaluated, so a branching rule may depend on different cells from
>>time to time.
> 
> 
> Sorry, it is not clear for me what 'rule' means here. Is it a synonym for
> 'formula'? 

Yes, sorry about the terminology switch. I'll go fix that in the doc (RSN).

> And what does 'rule dynamically accesses' mean?

Either directly or indirectly via a call (however recursively deep) to 
some other function.

In the olden days, before I grokked special variables, dependency 
tracking required passing around as a function argument the "asking" 
cell, the one being calculated. To hide this from users, I had the 
macros C? and ^<slotname> work in concert to do that.

So rules used to look like this:

     ... :area (c? * (^height self) (^width self))

Not so bad, but after macroexpansion the (^xxx whatever) form had to be 
lexically part of the (c? ...) form. in some cases the rule got /really/ 
hairy /and/ I wanted to reuse a big chunk of the rule several places. 
That forced me to use a macro so the (^xxx self) forms got in-lined if 
you will into the c? form. Worse, where I wanted a function I could map 
with, I had to come up with (^funcall...) a macro which took care of 
passing extra an argument to methods created vis (def^method...). yech.

Special variables eliminated all that. I can code (a too-simple case):

(defun calc-area (self)
    (* (height self) (width self)))

then... :area (c? (calc-area self))

and even though the C? rule does not see the height/width accesses, the 
dependency gets tracked anyway. How? The c? macro dynamically binds the 
area cell to the *asker* special variable. Any access to another cell 
during that binding leads to a dependency being established, of area on 
that cell.

This was an awesome change, btw. The internals got simpler, the client 
code got simpler and easier, and things got more rigorous. When 
switching over I did discover a couple of places where new dependencies 
got established, because some heavy-lifter function touched on a cell 
(so there /was/ a de facto dependency) but I never thought of that and 
so there was no (^deep-attribute ...) form in the rule.

> 
> 
>>The user may define callback echo functions to be invoked when a cell
> 
>                                ^^^^
> 
>>changes.
> 
> 
> What a nice name for callback function! 

glad you like it. :) and this reminds me of an exception to "any access 
to a cell during the dynamic binding leads to a dependency: an echo for 
B can get run during the derivation of A. Not good. The echo is not 
really part of A's derivation. so when echo functions run, the *asker* 
is dynamically cleared (set to nil).

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: cr88192
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <utfulh852v8ra9@corp.supernews.com>
ok, I had forgotten I had posted here.

I had more typically heard this referred to as constraints (if I understood 
the concept right).

my lang is capable of something similar as well, though in my system there 
is no way to detect dependancies/uses, and values are recomputed *on* 
*each* *reference*, so they could be considered quite expensive in some 
cases (especially in the case of constraints referring to each other, or 
worse is that a circular dependancy would yeild an infinate loop...).

using delay and force (from scheme) they can be made cheaper, though they 
are only computed on first reference.

I had created them as possibly just a helpful hack, but did not expect they 
would be that useful.

at present it would be a notable change to allow any kind of variable 
tracking, so likely for now they will remain expensive...

a possible idea (a hack though) could be to add a "watch", which could keep 
note of variables and recompute the constraint (also possibly recursive) 
when one of the variables changes. this is cheaper but still expensive.

in any cases my crappy constrainsts seem to have worked so far. in my 
system containing many gross inefficiencies, though it required an 
optimization not long ago just to bring my system back into the "usable" 
performance domain (it is still quite slow, but not as bad...).

Kenny Tilton wrote:

> 
> 
> cr88192 wrote:
>> 
>> out of curiosity (I did not see it really explained well in the other
>> threads, that or I forgot), what is "cells"?...
>> 
>> I have not been able to find any info on it...
>> 
> 
> SourceForge kicked my ass for me, so I never got it set up there. I'll
> see if my fancy new web site builder will let me upload PDFs for y'all
> to download.
> 
> I have some doc, tho one of them is pretty hairy: I deliberately push
> the envelope of Cells so anyone playing with them on their own will know
> how to react to the diagnostics that pop up when one goes out of bounds.
> 
> While I am hacking away at my site, from the "Cells Overview":
> 
> In Brief
> --------
> Cells let you define selected slots of CLOS instances as if they were
> cells in a spreadsheet. As with spreadsheet cells, a cell slot (cell,
> for short) can have bound to it a literal value or a formula. The
> formula is any Lisp form which, when wrapped in a suitable macro, enjoys
> access to anaphoric variables ?self (the CLOS instance of the slot) and,
> via the macro (cached-value), the most recent value calculated by the
> formula.
> 
> If a rule dynamically accesses another cell, a dependency is
> automatically recorded. Each time a rule runs the dependencies are
> re-evaluated, so a branching rule may depend on different cells from
> time to time.
> 
> When a cell changes, all cells dependent on that cell are recalculated.
> This eager evaluation cascades recursively from one used value to its
> multiple users, recursively through the dependency graph until one of:
> 
> ? terminating at a computing cell which recomputes the same value as
> last time, despite the changed inputs, such as the many radio buttons
> that recompute ?off? after each radio change.
> 
> ? terminating at a computed cell which does in fact change value, but
> which value no one uses. Such a cell would exist for its echo, if not by
> mistake.
> 
> ? if it loops back to itself propagating recursively to smUsers. no
> error is signal if the cell is defined to be cyclic (details below).
> though if any recalculated cell happens to come up with the same value
> as before, propagation does not continue to its dependents.
> 
> The user may define callback echo functions to be invoked when a cell
> changes. Echo functions are called before propagation to other cells.
> For example, a cell for the color slot of a widget has an echo method
> which triggers a screen update so the new color gets shown.
> 
> Echo functions are the output of the overall model. Input to the model
> is achieved by setting special variable cells to information culled from
> OS events. So the dataflow goes:
> 
> OSevent procedurally -> cell variable -> ruled cells dependent on the
> cell variable -> ruled cells dependent on ruled cells. other dataflow
> is: any given cell procedurally (in echos) -> OS outputs
> 

-- 
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD80C81.3000505@nyc.rr.com>
cr88192 wrote:
> ok, I had forgotten I had posted here.
> 
> I had more typically heard this referred to as constraints (if I understood 
> the concept right).

yep.

> 
> my lang is capable of something similar ...I had created them as possibly
 > just a helpful hack, but did not expect they
> would be that useful.

we had the same experience, completely surprised by what happened when 
we got our little hack cooking.

Steele in his thesis (in which he presented the development of a 
full-blown constraints language) likewise mentioned his surprise that 
constraints, presented over a decade earlier in the context of (memory 
fails me) another constraints implementation, had not taken the world by 
storm. Of course history repeated itself and constraints are still found 
only in highly specific applications.

I think the reason Cells work in a real-world application simply because 
we stuck with the dead simple, deterministic dataflow model and eschewed 
multiway constraints.

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: cr88192
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <utgdura7qkdu35@corp.supernews.com>
Kenny Tilton wrote:

> 
> 
> cr88192 wrote:
>> ok, I had forgotten I had posted here.
>> 
>> I had more typically heard this referred to as constraints (if I
>> understood the concept right).
> 
> yep.
> 
>> 
>> my lang is capable of something similar ...I had created them as possibly
>  > just a helpful hack, but did not expect they
>> would be that useful.
> 
> we had the same experience, completely surprised by what happened when
> we got our little hack cooking.
> 
agreed.
in my case the hack was quite simple (for objects anyways):
make pattern matcher match keywords and symbols with an equivalent base 
(which works given the general design of my objects).

then I had constraints, which are pretty cool but so far I have not used 
them much except in examples demonstrating the pythagorean theorem...

> Steele in his thesis (in which he presented the development of a
> full-blown constraints language) likewise mentioned his surprise that
> constraints, presented over a decade earlier in the context of (memory
> fails me) another constraints implementation, had not taken the world by
> storm. Of course history repeated itself and constraints are still found
> only in highly specific applications.
> 
yes, it is funny. I think now there is the potential for them to become 
more common, maybe not expecting much from something so simple is why they 
have not become more common.

> I think the reason Cells work in a real-world application simply because
> we stuck with the dead simple, deterministic dataflow model and eschewed
> multiway constraints.
> 
ok.

ok, probably I can just try using them and seeing what happens. like 
everything else I can probably start optimizing stuff if it gets too slow.

for right now though I have my new toy (persistence) working, so likely I 
will continue messing with that for a while...

-- 
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD87EC2.6080304@nyc.rr.com>
cr88192 wrote:
 > yes, it is funny. I think now there is the potential for them to become
 > more common, maybe not expecting much from something so simple is why 
they
 > have not become more common.

I call multi-way constraints going "a bridge too far". But having had so
much fun with one-way, I can see the temptation to take it to another
level, esp. academics without a specific application to build. I was
just trying to build this:

      http://www.tilton-technology.com/Arith_big_step.html

...and then some other hacks like a pendulum simulation (physical
modeling) and the acrostic puzzle on that same site, and I never
happened to come across a need for multi-way.

of course the constraint logic programming crowd is trying to solve much
tougher problems, so i would not say they were reaching higher just for
the sake of reaching higher. it's just too bad the simpler technology
never got out of the research lab when they got bogged down in multiway
stuff.[1]

my 2c, anyway.

[1] To be precise, Cells is just one of many projects involving simple
constraints, but they are not as ubiquitous as they should be.

-- 

   kenny tilton
   clinisys, inc
   ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
    and I'm happy to state I finally won out over it.""
                                                    Elwood P. Dowd
From: Paul Wallich
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <pw-6B3BD4.09242218112002@reader1.panix.com>
In article <················@nyc.rr.com>,
 Kenny Tilton <·······@nyc.rr.com> wrote:

>cr88192 wrote:
> > yes, it is funny. I think now there is the potential for them to become
> > more common, maybe not expecting much from something so simple is why 
>they
> > have not become more common.
>
>I call multi-way constraints going "a bridge too far". But having had so
>much fun with one-way, I can see the temptation to take it to another
>level, esp. academics without a specific application to build. I was
>just trying to build this:
>
>      http://www.tilton-technology.com/Arith_big_step.html
>
>...and then some other hacks like a pendulum simulation (physical
>modeling) and the acrostic puzzle on that same site, and I never
>happened to come across a need for multi-way.
>
>of course the constraint logic programming crowd is trying to solve much
>tougher problems, so i would not say they were reaching higher just for
>the sake of reaching higher. it's just too bad the simpler technology
>never got out of the research lab when they got bogged down in multiway
>stuff.[1]
>
>my 2c, anyway.
>
>[1] To be precise, Cells is just one of many projects involving simple
>constraints, but they are not as ubiquitous as they should be.

If you think about the enormous cultural intertia pushing people toward 
other programming methods, it's not really surprising. Other than 
spreadsheets (which aren't anywhere near complete for constraints, and 
which are almost universally contemned as "not really programming") 
there's nothing out there for people to see on a regular basis that uses 
any kind of constraint, and certainly nothing that kids at the 
beginnings of their programming careers would be introduced to in a 
principled way...

paul
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD91671.3040803@nyc.rr.com>
Paul Wallich wrote:
> In article <················@nyc.rr.com>,
>  Kenny Tilton <·······@nyc.rr.com> wrote:

>>[1] To be precise, Cells is just one of many projects involving simple
>>constraints, but they are not as ubiquitous as they should be.
> 
> 
> If you think about the enormous cultural intertia pushing people toward 
> other programming methods, it's not really surprising. 

Absolutely. Those of us who have programmed with constraints realize it 
is simply the only way we ever want to program again, but we have to 
remember other folks don't know that yet and they sure as hell are not 
going to take our word for it.

That's why from day one I knew I would have to build an entire app 
framework (including GUI) atop cells just to get folks to look at it. 
And even then it will be an uphill battle, because everyone knows what 
tools they will be using when they sit down to the computer every day.

So these things take time. Early adopters, word of mouth, etc etc. 
Someone said a non-native GUI would be of interest only for small hacks. 
I suggested also students and folks just learning Lisp. Maybe that's my 
beachhead.

That way I do not have to undertake a huge SWT-like universal-yet-native 
thang. I am leaning strongly now to OpenGL for imaging, conditional 
compilation to handle diff native OS events: Win32, Mac OS X, X.
-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: cr88192
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <utj6gj1ipoj0f6@corp.supernews.com>
Kenny Tilton wrote:

> 
> 
> Paul Wallich wrote:
>> In article <················@nyc.rr.com>,
>>  Kenny Tilton <·······@nyc.rr.com> wrote:
> 
>>>[1] To be precise, Cells is just one of many projects involving simple
>>>constraints, but they are not as ubiquitous as they should be.
>> 
>> 
>> If you think about the enormous cultural intertia pushing people toward
>> other programming methods, it's not really surprising.
> 
> Absolutely. Those of us who have programmed with constraints realize it
> is simply the only way we ever want to program again, but we have to
> remember other folks don't know that yet and they sure as hell are not
> going to take our word for it.
> 
I do not know much about them though, only what I have done and little 
pieces of info I have seen thus far...

the idea seems cool, so I will try to gather more info on the subject.
prolog seems related, so I will look into it to see if there is any useful 
info.

> That's why from day one I knew I would have to build an entire app
> framework (including GUI) atop cells just to get folks to look at it.
> And even then it will be an uphill battle, because everyone knows what
> tools they will be using when they sit down to the computer every day.
> 
eh?...
getting anyone to use anything I make would be a problem, even though what 
I am trying to make would likely be quite good for what I am doing many 
things could likely be considered "oddball".
until watching the "lightweight langauge" conference thinggy a few days ago 
I was not really aware that others had similar ideas.
not to seem egotistical or anything, but I came up with many of the 
mentioned ideas on my own (though in other cases I saw the source 
information). also I personally did not really like the approach zope/zodb 
was using for persistence (though they probably have reasons for doing it 
that way...), my system is somewhat different (and a bit more flexible). 
allready (after getting it to work yesterday) I can store code, and should 
also be able to store thread/process contexts...

now I need to get going with the details of persistent gc (I currently lack 
a good idea for "on-line" collection of the store, but maybe I will 
manage). the difficulty is the previously planned approach to collection 
will not really work given the current approach to memory 
managment/persistence. I am thinking I will need to implement an 
"evacuating" collector. actually I am thinking I might need a combination 
algo, mark/sweep+evacuation, mark/sweep so that evacuation decisions can be 
informed, or I could use evacuation for collection and try to free several 
chunks at once:
the first chunk on the "collection list" will be compacted, and the next 
few chunks will be evacuated into the first (until it is full). after that 
the process could be continued on other blocks until the needed number of 
chunks are freed (this may sound like what I was thinking before, but 
differs in smaller details...).
or, for early testing, I could just use a more conventional compacting 
collector.

nevermind, this is off subject...

> So these things take time. Early adopters, word of mouth, etc etc.
> Someone said a non-native GUI would be of interest only for small hacks.
> I suggested also students and folks just learning Lisp. Maybe that's my
> beachhead.
> 
ok, my gui will be non-native (or at least in the pure gui context). if 
anyone wants once my system becomes more stabilized I could write wrappers 
to allow my vm to go through the more conventional gui (mostly because they 
probably wouldn't want some zooming gl based thinggy taking over their 
screen...).

> That way I do not have to undertake a huge SWT-like universal-yet-native
> thang. I am leaning strongly now to OpenGL for imaging, conditional
> compilation to handle diff native OS events: Win32, Mac OS X, X.

ok. for now I have a minimalist gui (partly because I do not want to 
implement a whole lot, partly because I have not fully decided how I want 
to do things...).


why do I not use cl:
cl allready defines too much, and would not give me the room to express my 
freedom (not that it is incapable, but cl tends to have ways it wants 
things done, so I can't do things terribly "weird" like I can do with 
scheme and still be "complient", though my lang is not really scheme 
either, but it is also notably not cl...).

it is not "pure" anything, it is a mish-mash of many things, which I am 
trying to keep as a consistent whole... it just seems that in my mish-mash 
the parts are starting to fit reasonably well...

for now it is for no one but me...

-- 
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD9B0DD.6040407@nyc.rr.com>
cr88192 wrote:
> Kenny Tilton wrote:
>>Absolutely. Those of us who have programmed with constraints realize it
>>is simply the only way we ever want to program again, but we have to
>>remember other folks don't know that yet and they sure as hell are not
>>going to take our word for it.
>>
> 
> 
> the idea seems cool, so I will try to gather more info on the subject.
> prolog seems related, so I will look into it to see if there is any useful 
> info.

OK, but look out. Constraints are as maddening as Prolog. Cells are a 
walk in the park. :)

> until watching the "lightweight langauge" conference thinggy a few days ago 
> I was not really aware that others had similar ideas.
> not to seem egotistical or anything, but I came up with many of the 
> mentioned ideas on my own...

Yeah, I too completely reinvented the wheel, blissfully unaware of 
decades of research. Fun, isn't it? That's the downside of being 
self-taught and working as a one-man group. c.l.l. helps a lot, as will 
ILUG-NY.

With Cells, as soon as I realized the paradigm did not have a fatal flaw 
I went searching the Web for prior art, convinced someone else must have 
stumbled on it before. It was too good (and simple) to be new under the sun.

> nevermind, this is off subject...

heh-heh, we love talking about our pet projects, don't we? Sounds like 
you are into some fun stuff.

> why do I not use cl:
> cl allready defines too much, and would not give me the room to express my 
> freedom 

You have a scoop! And indeed you must be doing something weird if CL is 
a constraint. :) best of luck with it.

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: cr88192
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <utjnea8vel1ufc@corp.supernews.com>
Kenny Tilton wrote:

> 
> 
> cr88192 wrote:
>> Kenny Tilton wrote:
>>>Absolutely. Those of us who have programmed with constraints realize it
>>>is simply the only way we ever want to program again, but we have to
>>>remember other folks don't know that yet and they sure as hell are not
>>>going to take our word for it.
>>>
>> 
>> 
>> the idea seems cool, so I will try to gather more info on the subject.
>> prolog seems related, so I will look into it to see if there is any
>> useful info.
> 
> OK, but look out. Constraints are as maddening as Prolog. Cells are a
> walk in the park. :)
> 
ok.

>> until watching the "lightweight langauge" conference thinggy a few days
>> ago I was not really aware that others had similar ideas.
>> not to seem egotistical or anything, but I came up with many of the
>> mentioned ideas on my own...
> 
> Yeah, I too completely reinvented the wheel, blissfully unaware of
> decades of research. Fun, isn't it? That's the downside of being
> self-taught and working as a one-man group. c.l.l. helps a lot, as will
> ILUG-NY.
> 
> With Cells, as soon as I realized the paradigm did not have a fatal flaw
> I went searching the Web for prior art, convinced someone else must have
> stumbled on it before. It was too good (and simple) to be new under the
> sun.
> 
agreed.

many things of mine are not original, but some I have not been able to 
find. luckily for me I have a sufficient pool of ideas that I don't think I 
will run out soon. things are designed with little attention payed to the 
outside world (beyond theory), I do not really care what others are doing, 
I do what seems to make sense to me. I have little basis for my decisions, 
but what I do is one place where I have some freedom of expression...

>> nevermind, this is off subject...
> 
> heh-heh, we love talking about our pet projects, don't we? Sounds like
> you are into some fun stuff.
> 
yeah, kind of. my project has become large enough so that if there is 
trouble in one place I can allways wander somewhere else and start working 
on that (except when it becomes large enough that I wander off and forget 
that I was working on the first thing...).

some things are pretty difficult to imlement, but once implemented are 
pretty cool and offer a lot to mess with. a persistent store offers a lot 
of tweak room. sadly I haven't really checked how common persistence is in 
different systems though.
ok, note: my persistence is not a raw heap image, nor does it serialize 
data. mostly it takes the heap and attempts to store all that is reachable 
from the persistent roots.
my idea is based loosly off of the "pointer swizzling at page fault 
time"/"the 'texas' system", and a variation of the larchant model (lost 
somewhere along the way).

implementing those is not terribly convinient, so far my swizzler works in 
terms of "chunks", which tend to be much larger than pages. now I am down 
to using hacks (preventing allocation in persistent pages) to avoid 
creating references from persistent space into the live heap (hoping to 
control store growth to some extent).

I have multithreading, and am implementing a messaging system borrowed from 
erlang (presently my cost/thread is 64 bytes, and however much time is 
eaten up when the thread is running). blocked threads do not generate 
load, and deadlocked threads can be reclaimed by the gc. not really 
sure if this is a good way to handle deadlocks though.

I have been considering making the threads list persistent. the repl state, 
however is not persistent. I could make the gui state persistent, however I 
would have to strip out all the gui stuff hacked in to test the gui (little 
loss).
I would likely need to add something to "reconstitute" things which are 
destroyed and need to be regained between times the vm runs (such as 
graphics, which are not just vm data...).

so many details...

then I am also distracted by other issues, ie: that I want to encode extra 
"side information" with lists so I can have nice formatted output (ok, so 
print and display will dump out something a little more resenbling what 
read pulls in, and I can make my 'ls-env' command display something "nice" 
for users), maybe also providing some extra security info or some other 
arcane use...

>> why do I not use cl:
>> cl allready defines too much, and would not give me the room to express
>> my freedom
> 
> You have a scoop! And indeed you must be doing something weird if CL is
> a constraint. :) best of luck with it.
> 
I can go on like this for a while.

most notably would be that a custom object system would "clash" with clos 
(in that it would be expected that I have both); my idea for modules was 
different; many other trivial details were different;
I did not want to implement the size of cl, nor did I want to use an 
existing implementation;
I did not want to be "tied" to conventional systems designs (files, ...); 
...

(those things which would give cl power would get in the way of 
creativity...). not meaning to cause flames here or anything.

I had started out with scheme, but my system now is hardly scheme. from 
what I have seen scheme looks like a better base for language 
experimentation, given its small size and minimal semantics.

what do I do then: take scheme and bolt on crap from self (object system) 
and python (part of the syntax)...

and I get:
render-show
        dialog "test-app-0" #(0 0)
                let ((lab0 #z) (entry0 #z))
                        stack-horizontal
                                stack-vertical
                                        lab0 := (label "")
                                        entry0 := (textentry 16)

                                button "OK"
                                        handler (use:)
                                                lab0.text := entry0.text
                                                entry0.text := ""

as a simple program, demonstrating the horridness that I lack a clean way 
to deal with objects hidden in structures (if anyone wonders why most 
fragments I bring up relate to the gui, that is because that is the only 
really large bit of code written in my lang right now).

I get bored with my fragments, given I don't have terribly much code 
anymore that I haven't posted piecewise on usenet.


at least I can say that my projects are "starting" to get more 
interesting...

-- 
<cr88192[at]hotmail[dot]com>
<http://bgb1.hypermart.net/>
From: Christopher Browne
Subject: Cells/Constraints
Date: 
Message-ID: <arb5t2$go5vb$1@ID-125932.news.dfncis.de>
The world rejoiced as Paul Wallich <··@panix.com> wrote:
> In article <················@nyc.rr.com>,
>  Kenny Tilton <·······@nyc.rr.com> wrote:
>>[1] To be precise, Cells is just one of many projects involving simple
>>constraints, but they are not as ubiquitous as they should be.
>
> If you think about the enormous cultural intertia pushing people
> toward other programming methods, it's not really surprising. Other
> than spreadsheets (which aren't anywhere near complete for
> constraints, and which are almost universally contemned as "not
> really programming") there's nothing out there for people to see on
> a regular basis that uses any kind of constraint, and certainly
> nothing that kids at the beginnings of their programming careers
> would be introduced to in a principled way...

Constraints also have the problem that they can conflict, and when
that happens, it may be troublesome to resolve the conflict.  Getting
back to a "feasible" condition may require backtracking quite a bit,
in a Prolog-like manner, and people certainly aren't typically trained
to do that sort of thing.
-- 
(reverse (concatenate 'string ····················@" "454aa"))
http://cbbrowne.com/info/lisp.html
Rules of the Evil Overlord  #142. "If I have children and subsequently
grandchildren, I will keep  my three-year-old granddaughter near me at
all times. When  the hero enters to  kill me, I will ask  him to first
explain to her  why it is necessary to kill  her beloved grandpa. When
the hero launches  into an explanation of morality  way over her head,
that will be  her cue to pull the  lever and send him into  the pit of
crocodiles. After  all, small children like crocodiles  almost as much
as Evil Overlords  and it's important to spend  quality time with your
grandkids. <http://www.eviloverlord.com/>
From: Kenny Tilton
Subject: Re: Cells/Constraints
Date: 
Message-ID: <3DD922F4.8080104@nyc.rr.com>
Christopher Browne wrote:
> The world rejoiced as Paul Wallich <··@panix.com> wrote:
> 
>>In article <················@nyc.rr.com>,
>> Kenny Tilton <·······@nyc.rr.com> wrote:
>>
>>>[1] To be precise, Cells is just one of many projects involving simple
>>>constraints, but they are not as ubiquitous as they should be.
>>
>>If you think about the enormous cultural intertia pushing people
>>toward other programming methods, it's not really surprising. 
...snip..
> 
> Constraints also have the problem that they can conflict, and when
> that happens, it may be troublesome to resolve the conflict.  Getting
> back to a "feasible" condition may require backtracking quite a bit,
> in a Prolog-like manner, and people certainly aren't typically trained
> to do that sort of thing.

Yes, I mentioned the multi-way thing being a problem, but it goes beyond 
that as in the problem you describe.

Digression: my little Cells hack avoids that. They are the simplest kind 
of constraint, and in fact constraint is not the right word at all for 
Cells! I just don't think I can escape the umbrella term for this sort 
of thing given its long history.

Digression (cont'd): The rule for a Cell does not /constrain/ the values 
that cell can hold, it /decides/ the cell's value entirely; the rule you 
see for a cell, like a spredsheet cell's rule, gives you all its 
semantics (one big win, btw). If a cell rule is a constraint, it is a 
constraint with extreme prejudice. But no, even that suggests that the 
programmer can code (setf <constrained-cell> 42) and see if the 
constraint system will buy it. Not with Cells, an error is signaled.

So i guess my feeling is that folks like Steele should /not/ be 
surprised. getting full-blown constraint systems to produce desired 
behavior can be as tough as doing so with Prolog.

I think Cells will be easier for people.

-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd
From: Kenny Tilton
Subject: Re: Interfaces 'r Us
Date: 
Message-ID: <3DD514D9.1080901@nyc.rr.com>
Ha-ha, looks like I just hung out a shingle by mistake! Step right up, 
buy two, get one free. All sales final!

Kenny Tilton wrote:
> Guess what? I had been thinking recently that one way for me to leverage 
> my Cells stuff would be to take contracts to provide great interfaces 
> for other peoples' projects. 


-- 

  kenny tilton
  clinisys, inc
  ---------------------------------------------------------------
""Well, I've wrestled with reality for thirty-five years, Doctor,
   and I'm happy to state I finally won out over it.""
                                                   Elwood P. Dowd