When is a source? not a source? (when its a sink!)
22 views
Skip to first unread message
Gary Gladman
Mar 10, 2012, 7:48:40 AM3/10/12
to visi...@googlegroups.com
</programmer_hat>
<architect>
What intrinsically makes a source a source and not a sink? IMHO perspective.
How about an ether of framable models? Here models (controllably) obtain values/results for identifiers from users or other models, possibly with (limited or lazy) feedback.
Here sources and sinks become attachment points to expose identifiers either to a frame or to other framable models.
A frame may be implemented as an app on a tablet or a phone or a slate or even a young ladies illustrated primer.
Too off the wall?
Not necessarily.
What is key with a source is that it be obtainable (logically) from other than this model; how and from where it is obtained is a less important detail.
What is key with a sink is that it be providable (logically) to potentially other than this model; how and to where is a less important detail.
A model can itself be considered to be mechanically composed of sub-models; well at least to the point of a single identified expression e.g.
b = f(a)
All that makes b intrinsically a sink and a intrinsically a source is perspective.
If I framed this I would expect a to be treated as a source and b as a sink (within the limits of type correctness?).
If I dotted the i's and crossed the t's I might expect to restate it as
!b = f(?a)
[DPP: aside: this nomenclature at this point is really just for my ease of exposition.]
If I embedded this model with another model to create a bigger model e.g.
c = f2(b)
b = f(a)
And if I framed this I would expect a to intrinsically be a source and c to be a sink (yes the ordering is backwards but thats OK cos its really an ellided literary model not a program ;-) ).
What really changed? Perspective.
(Aside: consider, was f2() a function or a model. I guess because it has one result its a function, if its n it might be a model. More perspective? More scenario's? Are functions a specialization of model?)
And if I dot the i's and cross the t's I might expect to restate it as
!c = f2(b)
b = f(?a)
And If I was being formally correct I might write
?a
c = f2(b)
b = f(a)
!c
Or since this is a model composed of 2 models I might formally write
?a
c = f2(b)
b = f(a)
!c
!b
So if we follow this line of thought a little further; we have a model of models that may compose or feed other models and so on and so forth ["standing on the shoulders of giants" anyone?].
So when we describe something as a source or sink we are really just saying these are exposure points (obtained or provided). Framing being the most obvious option for doing this. Ultimately these values could be sourced and sunk from anywhere and if necessary constrained using e.g. overriding language constructs, but for now its simply exposure.
The really important idea IMHO is pluggable or composable models that may be built from or with other models via their exposed sources and sinks. The models may impose extra constraints via the language tbd, or the ether may embed the models with extra constraints somehow.
So when is a source not a source; when it is a sink from my selfish perspective whatever I chose that to be and as and when it suits me.
And from a mechanical point of view (getting things done in the cloud) I suspect some of this is what DPP may have in mind cos ultimately a model is a transformable entity which can be decomposed into sub-models which can be transferred (alive?) into the cloud.
Well we can all dream ... then plan ... then do ... then use ... then share ... then build ... then ...
Magic model ether anyone? Maybe I'm only just catching on? This is exciting!
P.S. with enough plus ones I'm sure I could produce a lite version of this without any attempted humour :-)
<architect>
What intrinsically makes a source a source and not a sink? IMHO perspective.
How about an ether of framable models? Here models (controllably) obtain values/results for identifiers from users or other models, possibly with (limited or lazy) feedback.
Here sources and sinks become attachment points to expose identifiers either to a frame or to other framable models.
A frame may be implemented as an app on a tablet or a phone or a slate or even a young ladies illustrated primer.
Too off the wall?
Not necessarily.
What is key with a source is that it be obtainable (logically) from other than this model; how and from where it is obtained is a less important detail.
What is key with a sink is that it be providable (logically) to potentially other than this model; how and to where is a less important detail.
A model can itself be considered to be mechanically composed of sub-models; well at least to the point of a single identified expression e.g.
b = f(a)
All that makes b intrinsically a sink and a intrinsically a source is perspective.
If I framed this I would expect a to be treated as a source and b as a sink (within the limits of type correctness?).
If I dotted the i's and crossed the t's I might expect to restate it as
!b = f(?a)
[DPP: aside: this nomenclature at this point is really just for my ease of exposition.]
If I embedded this model with another model to create a bigger model e.g.
c = f2(b)
b = f(a)
And if I framed this I would expect a to intrinsically be a source and c to be a sink (yes the ordering is backwards but thats OK cos its really an ellided literary model not a program ;-) ).
What really changed? Perspective.
(Aside: consider, was f2() a function or a model. I guess because it has one result its a function, if its n it might be a model. More perspective? More scenario's? Are functions a specialization of model?)
And if I dot the i's and cross the t's I might expect to restate it as
!c = f2(b)
b = f(?a)
And If I was being formally correct I might write
?a
c = f2(b)
b = f(a)
!c
Or since this is a model composed of 2 models I might formally write
?a
c = f2(b)
b = f(a)
!c
!b
So if we follow this line of thought a little further; we have a model of models that may compose or feed other models and so on and so forth ["standing on the shoulders of giants" anyone?].
So when we describe something as a source or sink we are really just saying these are exposure points (obtained or provided). Framing being the most obvious option for doing this. Ultimately these values could be sourced and sunk from anywhere and if necessary constrained using e.g. overriding language constructs, but for now its simply exposure.
The really important idea IMHO is pluggable or composable models that may be built from or with other models via their exposed sources and sinks. The models may impose extra constraints via the language tbd, or the ether may embed the models with extra constraints somehow.
So when is a source not a source; when it is a sink from my selfish perspective whatever I chose that to be and as and when it suits me.
And from a mechanical point of view (getting things done in the cloud) I suspect some of this is what DPP may have in mind cos ultimately a model is a transformable entity which can be decomposed into sub-models which can be transferred (alive?) into the cloud.
Well we can all dream ... then plan ... then do ... then use ... then share ... then build ... then ...
Magic model ether anyone? Maybe I'm only just catching on? This is exciting!
P.S. with enough plus ones I'm sure I could produce a lite version of this without any attempted humour :-)
David Pollak
Mar 10, 2012, 6:46:52 PM3/10/12
to visi...@googlegroups.com
Gary,
I'll spend more time answering this email tomorrow (I'm about to hop on a flight to London).
If you can make it to http://skillsmatter.com/event/scala/functional-programming-exchange-2012 maybe we can talk more in person.
Thanks!
David
--
Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro
Lift, the simply functional web framework http://liftweb.netReply all
Reply to author
Forward
0 new messages