a question of ?sources and "sinks" (or perhaps !sinks)

[Gary Gladman]

I'm struggling with the basic source and sink ideas.

Consider this example taken from the language spec:

?taxRate
?taxable
?nonTaxable

total = subtotal + tax
tax = taxable * taxRate
subtotal = taxable + nonTaxable

"Total " = total
"Tax" = tax

Say I want to observe subtotal, can I simply rewrite "subtotal =
taxable + nonTaxable" as:

"subtotal" = taxable + nonTaxable

But hang on, the implication is I cant just do that, I need to resort
to adding an extra line instead:

"subtotal" = subtotal

Though on the plus side that does give me the freedom at least to
write:

"Sub Total" = subtotal

So sinks/sources are really about presentation or output/input?

Hang on, how about rewriting the largely original example as

?TaxRate
?taxable
?nonTaxable

!total = SubTotal + Tax
!Tax = taxable * TaxRate
!SubTotal = Taxable + NonTaxable

Quite a few ideas and a bit of a leap ...

Its briefer, does more and is more succinct.

Source TaxRate is presented as "TaxRate"
Source taxable is presented as "taxable"
Source nonTaxable is presented as "nonTaxable"

Sink total is presented as "total"
Sink Tax is presented as "Tax"
Sink SubTotal is presented as "SubTotal"

If the presentation of total and SubTotal still isn't good enough then
we can rewrite as:

?TaxRate
?taxable
?nonTaxable

total = SubTotal + Tax
!Tax = taxable * TaxRate
SubTotal = Taxable + NonTaxable

!Total = total
!"Sub Total" = SubTotal

And if we still don't like the source presentation of TaxRate then we
can rewrite as:

TaxRate = ?"Tax Rate"
?taxable
?nonTaxable

total = SubTotal + Tax
!Tax = taxable * TaxRate
SubTotal = Taxable + NonTaxable

!Total = total
!"Sub Total" = SubTotal

So whats been gained;

- least surprise declaration of sinks where just a single character
change can '!' make an (intermediate) result a sink allowing easy
debugging (maybe similar for sources).
- simple default presentation of sources and sinks
- hard formatting of sources and sinks possible if and only if
necessary
- simpler and more uniform approach

The use of '!' to identify a sink follows similar usage elsewhere e.g.
send in actor frameworks, fact in paper note taking systems.

Heres another contrived example:

i1 = ?source + 1
i2 = i1 * 2
!Answer = i2 - 1

To see the working value of i2 we can VERY simply rewrite as:

i1 = ?source + 1
!i2 = i1 * 2
!Answer = i2 - 1

DPP love Lift, love the visi idea. I can see parrallels between this
and a sysem I worked on a while back where the background was optimal
data distribution across a network of widely distributed machines. I
can totally see the spreadsheet metaphor.

Please be gentle oh great and wonderful BDFL and other interested
parties; I'm new to this, I've probably missed something and I still
want to feel brave enough to ask even more taxing questions.

[David Pollak]

Gary,

Thanks for participating in the conversation.

On Sat, Mar 3, 2012 at 9:03 AM, Gary Gladman <feig...@gmail.com> wrote:

I'm struggling with the basic source and sink ideas.

Consider this example taken from the language spec:

       ?taxRate
       ?taxable
       ?nonTaxable

       total = subtotal + tax
       tax = taxable * taxRate
       subtotal = taxable + nonTaxable

       "Total " = total
       "Tax" = tax

Say I want to observe subtotal, can I simply rewrite "subtotal =
taxable + nonTaxable" as:

       "subtotal" = taxable + nonTaxable

That's perfectly valid.  I'll add the example to the language definition.  The right hand side of a sink can be any expression.

 

But hang on, the implication is I cant just do that, I need to resort
to adding an extra line instead:

       "subtotal" = subtotal

Though on the plus side that does give me the freedom at least to
write:

       "Sub Total" = subtotal

So sinks/sources are really about presentation or output/input?

output/input.  The current demo does automatic generation of presentation, but I'm working on an Interface Builder-like tool to layout a UI and associate it with a Visi model.

I've been debating how to delineate sources and sinks.  Identifiers in Visi have to be lower case (that's not yet enforced, but it will be soon). Sources have to be identifiers.  Sinks do not (it's not legal to have an expression that references a sink).  I would like to find a way for the source and sink names to be human-expressive so that when you're wiring up the UI to a model (or wiring the sinks of one model to the sources of another model), you've got nice names rather than "variable" names.

 

- simple default presentation of sources and sinks
- hard formatting of sources and sinks possible if and only if
necessary
- simpler and more uniform approach

The use of '!' to identify a sink follows similar usage elsewhere e.g.
send in actor frameworks, fact in paper note taking systems.

I'm not opposed to '!'.  I used quotes because it led to a nicer human-readable auto-generated UI.  I've also been noodling with Unicode characters such as ☞ and ☜ They are hard to type, but would lead to cool looking code. ;-)

 

Heres another contrived example:

       i1 = ?source + 1
       i2 = i1 * 2
       !Answer = i2 - 1

I think it's best to have sources on their own line rather than being part of expressions.  This makes clear what the sources are.

 

To see the working value of i2 we can VERY simply rewrite as:

       i1 = ?source + 1
       !i2 = i1 * 2
       !Answer = i2 - 1

I think it will be hard to develop the dependency system to have sinks depend on other sinks.  I'm not sure of this mathematically, but it feels that way in my gut (it's been 15 years since I build a dependency system, but having constraints on the dependencies makes a huge difference in simplifying the computation of the dependencies).

Also, I'm not sure that conciseness is a virtual in all cases.

One of the many problems with Excel spreadsheets is that it's hard to figure out what the model does.  Yes, you can look at the formula in a cell and figure out what is happening in that cell, but it's non-trivial to look at a collection of cells and see what's going on.  One of the drivers for making Visi a literate language is to increase certain verbosity... help the modeler tell a story where the model is only a small part of the story.  I think having a separation between sources, sinks, and logic is an important part of telling the story.  You can look at the business logic in isolation and better understand what the actual model does.

With all that being said, I like your ideas and I super-like that you put your ideas out in the Visi forum.  I'd love to hear from others.  I may be totally off-base with my perspective and having lots of people weigh in early allows us to make the best decisions going forward.  The only thing I ask is that you take off your "I'm a good programmer" hat (if you're coding in Scala or Haskell or OCaml or Java or Ruby then you wear that hat) and put on the "I want to computer to be an appliance and I want it to be simple now and simple when I go back to it in 6 months" hat.  Those two hats are different, although they can be served by similar technology (e.g., a powerful type system) but in different ways (e.g., type error messages that recommend an action rather than telling you why the types didn't resolve.)

 

DPP love Lift, love the visi idea. I can see parrallels between this
and a sysem I worked on a while back where the background was optimal
data distribution across a network of widely distributed machines. I
can totally see the spreadsheet metaphor.

Please be gentle oh great and wonderful BDFL and other interested
parties; I'm new to this, I've probably missed something and I still
want to feel brave enough to ask even more taxing questions.

Looking forward to your questions and further dialog! 

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

[Gary Gladman]

On Monday, March 5, 2012 6:56:40 PM UTC, David Pollak wrote:

Gary,

Thanks for participating in the conversation.

On Sat, Mar 3, 2012 at 9:03 AM, Gary Gladman wrote:

I'm struggling with the basic source and sink ideas.

Consider this example taken from the language spec:

       ?taxRate
       ?taxable
       ?nonTaxable

       total = subtotal + tax
       tax = taxable * taxRate
       subtotal = taxable + nonTaxable

       "Total " = total
       "Tax" = tax

Say I want to observe subtotal, can I simply rewrite "subtotal =
taxable + nonTaxable" as:

       "subtotal" = taxable + nonTaxable

That's perfectly valid.  I'll add the example to the language definition.  The right hand side of a sink can be any expression.

 

But hang on, the implication is I cant just do that, I need to resort
to adding an extra line instead:

       "subtotal" = subtotal

Though on the plus side that does give me the freedom at least to
write:

       "Sub Total" = subtotal

So sinks/sources are really about presentation or output/input?

output/input.  The current demo does automatic generation of presentation, but I'm working on an Interface Builder-like tool to layout a UI and associate it with a Visi model.

 

Seperate the concerns? At this stage sounds good to me.

lowercase? e.g. 1) anidentifier NOT 2) anIdentifier NOT 3) AnIdentifier? Prefer  2. Enforced soon - OK

Sources have to be identifiers.

OK

Sinks do not

Hmm?

(it's not legal to have an expression that references a sink).

 Hmm? (I may not be understanding see first modified example as accepted and then breakout at end)

I would like to find a way for the source and sink names to be human-expressive so that when you're wiring up the UI to a model

 Yes

(or wiring the sinks of one model to the sources of another model),

 ... and this is the idea that excites me and I regard as very very important (and hopefully is to be the point of another post)

(DPP:) you've got nice names rather than "variable" names. (GG: Oops formatting mistake)
... and I'm guessing this tension may be at the centre of the struggle.

Initially how about sticking to a temporary seperation of concerns if that helps.

Make the language primarily about a literary model involving variables and functions and the "UI" about attaching or inferring human expression (e.g. auto converting case in variable names, adding spaces as necessary, searching the literary expression etc). In anycase the literary/model approach may make the transition to be less jarring since it isnt difficult to read a discussion regarding "Tax Rate" then understand a model involving taxRate! ;-)

This would at least relax any tension.

- simple default presentation of sources and sinks
- hard formatting of sources and sinks possible if and only if
necessary
- simpler and more uniform approach

The use of '!' to identify a sink follows similar usage elsewhere e.g.
send in actor frameworks, fact in paper note taking systems.

I'm not opposed to '!'.  I used quotes because it led to a nicer human-readable auto-generated UI.  I've also been noodling with Unicode characters such as ☞ and ☜ They are hard to type, but would lead to cool looking code. ;-)

... so if sources and sinks are equally important in this context then the language solution could be evenly applied whatever the final choice e.g sinks/sources equally do/do not use quotes for/not for presentation with something else denoting sink or source 'ness.

At the moment I don't even know how to inject those special characters so ;-)
 

 

Heres another contrived example:

       i1 = ?source + 1
       i2 = i1 * 2
       !Answer = i2 - 1

I think it's best to have sources on their own line rather than being part of expressions.  This makes clear what the sources are.

From a literary perspective I would prefer to seperate out sources and sinks.

From a lets try something out perspective I'd like to bang it out and see the result(s) now.

 

To see the working value of i2 we can VERY simply rewrite as:

       i1 = ?source + 1
       !i2 = i1 * 2
       !Answer = i2 - 1

I think it will be hard to develop the dependency system to have sinks depend on other sinks.  I'm not sure of this mathematically, but it feels that way in my gut (it's been 15 years since I build a dependency system, but having constraints on the dependencies makes a huge difference in simplifying the computation of the dependencies).

I cant really comment on the difficulty, I don't know enough. I am learning in by monitoring the code base changes.

I don't feel "sinks" depending on "sinks" should be a problem mathematically and functionally since I see it as an intermediate result. If the example (ignoring ?source) had stopped at !i2  = i1 * 2 everything would have been fine? I think it would surprise if the first sink was wrong when that result is itself then built upon, or as my thinking was at the time if I want to easily "debug" an intermediate result.

Also, I'm not sure that conciseness is a virtual in all cases.

I guess mathematicians might disagree ;-) Personally and in the large I agree.

One of the many problems with Excel spreadsheets is that it's hard to figure out what the model does.  Yes, you can look at the formula in a cell and figure out what is happening in that cell, but it's non-trivial to look at a collection of cells and see what's going on.  One of the drivers for making Visi a literate language is to increase certain verbosity... help the modeler tell a story where the model is only a small part of the story.  I think having a separation between sources, sinks, and logic is an important part of telling the story.  You can look at the business logic in isolation and better understand what the actual model does.

I agree plus I think the literate approach will in itself lead to clearer expression. I'm just worried that when people play/bootstrap their first concern is what can I do, then practically oh that didnt work, where was it ok up to? Not how can I express myself. Realistically I'm no literary author, I'm just this guy trying to get stuff done. Perceived constraints alienate people unless they can TOTALLY see the advantage and then of course there is a mental reboxing to it being common sense.

I'd have thought there was room for both approaches with good examples (as you have) leading good practice.

IMHO
1) the model is only part of the story (good practice - led/driven by example)
2) Sources, sinks and logic should be seperated (good practice - led/driven by example)
3) Don't mandate these (though maybe seperate out sources) (reduce tension: human factors/reduce imposed constraints/reduce imposed language constraints perhaps)

With all that being said, I like your ideas and I super-like that you put your ideas out in the Visi forum.  I'd love to hear from others.  I may be totally off-base with my perspective and having lots of people weigh in early allows us to make the best decisions going forward.  The only thing I ask is that you take off your "I'm a good programmer" hat (if you're coding in Scala or Haskell or OCaml or Java or Ruby then you wear that hat) and put on the "I want to computer to be an appliance and I want it to be simple now and simple when I go back to it in 6 months" hat.  Those two hats are different, although they can be served by similar technology (e.g., a powerful type system) but in different ways (e.g., type error messages that recommend an action rather than telling you why the types didn't resolve.)

</programmer_hat><architect>
 

 

DPP love Lift, love the visi idea. I can see parrallels between this
and a sysem I worked on a while back where the background was optimal
data distribution across a network of widely distributed machines. I
can totally see the spreadsheet metaphor.

Please be gentle oh great and wonderful BDFL and other interested
parties; I'm new to this, I've probably missed something and I still
want to feel brave enough to ask even more taxing questions.

Looking forward to your questions and further dialog! 

--

Visi.Pro, Cloud Computing for the Rest of Us http://visi.pro

Lift, the simply functional web framework http://liftweb.net

Follow me: http://twitter.com/dpp
Blog: http://goodstuff.im

I thought I'd bring this aspect out of line to avoid breaking the flow

DPP: "it's not legal to have an expression that references a sink"

 
However, if as said above the following becomes allowed

    "subtotal" = taxable + nonTaxable

Won't this cause the above constraint to be broken because the base example also reads

    total = subtotal + tax

Maybe?

• revert "subtotal" to just a variable.
• remove the constraint: expression can't refer to sink
• reinterpret sink to mean modifier: expose (for output)
• or other options ...?
  

Maybe there is an encompassing concern: when is a sink? not a sink? (when its a source!) (intentional bad language pun) :-)

Time for a parallel less language focused thread me thinks!