Yes, sum (x + y) vs. product (x * y) corresponds to 'or vs. and' or 'union
vs. struct'.
For many purposes, they are very similar: associative, commutative,
identity elements, ability to focus attention and operations on just x or
just y. We can model zippers and lenses for each, which is kind of cool.
In widget form, products are obvious (typical hbox or vbox). Sums, OTOH,
are rarely represented directly because we tend to hide the inactive
values. One might model a sum in terms of a radio-button with an associated
active form - i.e. instead of hiding the inactive values, they're marked
inactive - but still accessible for manipulations. (We could have optional
views that hide the inactive forms.)
There are differences between sums and products:
products have `copy` x -> (x * x) (adding 1 bit of info)
sums have `merge` (x + x) -> x (losing 1 bit of info)
And in general we want to deal with cases like:
factoring :: (x*y) + (x*z) -> x*(y+z)
distribution :: x * (y + z) -> (x * y) + (x * z)
The problem with if/then/else statements is that they're closed to
extension: they force the merge, and any intermediate decisions, to be
syntactically local. This is inflexible. It is also, often, very
inefficient - i.e. in some cases it means we repeatedly branch our behavior
by observing the same values, rather than just keeping the same branch
available for extension.
I'm not sure what you were trying to explain with "the same number of
factors for each term" or what you mean by "true" as a factor. (My thought
is that you're using 'true' like I might have used the unit type, 1.) But I
think the main difficulties for sum vs. product regard something else
entirely: distribution, in a distributed system. An issue is that `x*(y+z)`
cannot really be distributed unless we know whether we are in y or z at the
*same place and time* as we know x. Perhaps this isn't as much a problem in
a UI, since we may be forced to move values to the same place and time to
get them into the same UI in the first place.
In other thoughts...
One PL concept you didn't mention is promises/futures. How might those be
realized in a UI?
In the type system of a PL, promises can be modeled as a pair:
makePromise :: 1 -> (resolver * future)
Or we can potentially model promises using fractional or negative types, as
developed by Amr Sabry, which has an advantage of addressing sums in a
symmetric manner:
receive :: 1 -> (1/a * a)
return :: (1/a * a) -> 1
receive+ :: 0 -> (-a + a)
return+ :: (-a + a) -> 0
But what would this look like in a UI model? My intuition is leaving some
sort of IOU where a value is needed then going to some other location to
provide it (perhaps after a copy and a few transforms). I suspect this
behavior might be convenient for a user, but it potentially leaves parts of
the UI or system in an indefinite limbo state while a promise is
unfulfilled. Though, perhaps that could be addressed by requiring the
promises to be fulfilled before operations will 'commit' (i.e. enforcing
type-safe UI transactions).
On Tue, Sep 10, 2013 at 7:45 PM, John Carlson <[email protected]> wrote:
> If your sum/product is or/and, I tend to agree there is difficulty. We
> chose to use a normalized representation: the same number of factors for
> each term, "true" used liberally as a factor. In many cases, there were
> only two branches to take. I spent a great deal of time coming up with a
> table which handled repetition, mandatory, optional and floating components
> in the product, but it got so difficult to be implemented and tested
> especially, that I gave up and implemented 997 acknowledgements in C++. I
> think our translation analyst may have been unique among EDI/X12 analysts
> for not using components designed specifically for X12 beyond the 997
> acknowledge code. Instead we used something like tab-separated values to
> parse the X12...which was much less flexible...we couldn't read the
> separators from X12 file--they had to be constants in the code. However,
> it might be possible that he used my fancy table, but I never heard of any
> bug reports, so I doubt it. That's where I learn the rule don't make
> anything so complex you can't debug it, or automate tests for it. This is
> likely why we see much more XML than X12 these days. If you don't know
> what X12 is, think of a mixture between s-expressions and comma separated
> values.
> On Sep 10, 2013 7:13 PM, "David Barbour" <[email protected]> wrote:
>
>> This is a good list of concept components.
>>
>> I think branching should be open - I.e. modeled as a collection where
>> only one item is 'active' at a time. There is a clear duality between sums
>> and products, and interestingly a lot of the same UIs apply (i.e.
>> prisms/lenses, zippers for sum types). (But there can be some awkwardness
>> distributing sums over products.)
>>
>> Recursion is an interesting case. One can model it as a closed value, or
>> as a fixpoint combinator. But to keep the UI/PL extensible, it might be
>> better to avoid closed loops (especially if they maintain state). Open loop
>> recursion happens easily and naturally enough if we have any shared state
>> resources, such as a database or tuple space... or the world itself (via
>> sensors and actuators).
>>
>> Exceptions: in general, exceptions are not difficult to model as
>> choices/branches (a path of a sum type). I've usually considered this a
>> better way to model them. This can be combined with searching the
>> environment for some advice on how to handle the condition - I.e. in terms
>> of a dynamic scoped 'special' variable, or (in a concatenative language)
>> literally searching a stack or other environment model.
>>
>> Keyboard/video/mouse/audio would be a good start for signals on the UI
>> side. I've been wondering how to get a lot of useful control signals
>> quickly... Maybe integrate with ROS from WillowGarage?
>> On Sep 10, 2013 10:54 AM, "John Carlson" <[email protected]> wrote:
>>
>>> To unify PL and UI:
>>>
>>> values: Date Calculator, String Calculator, Numeric Calculator,
>>> Zipper/Document Visualizer
>>> behavior, code: Recorder (the container), Script,
>>> Branch/Table/Conditional/Recursion/Procedure/Function/Method (Unified
>>> Control Structure)
>>> Also, Exceptions (has anyone seen a UI for this?)
>>> signals: Mouse, along with x,y coordinates
>>> Keyboard and Keystrokes
>>> Audio: waveform and controls
>>> Webcam: video and controls
>>> Networking: the extend/receive I/O operation
>>> System interface: pipes, command prompt
>>>
>>>
>>>
>>> On Tue, Sep 10, 2013 at 12:25 PM, David Barbour <[email protected]>wrote:
>>>
>>>> I think we cannot rely on 'inspection' - ability to view source and so
>>>> on - except in a very shallow way - e.g. to find capabilities directly
>>>> underlying a form. Relying on deep inspection seems to have several
>>>> problems:
>>>>
>>>> 1) First it would take a lot more study and knowledge to figure out the
>>>> intention of code, to distinguish the significant behavior from the
>>>> insignificant. Intentions could be easily obfuscated.
>>>>
>>>> 2) Since it would be difficult to embed this 'study and knowledge' into
>>>> our programs, it would become very difficult to automate composition,
>>>> transclusion, view-transforms, and programmatic manipulation of UIs. We
>>>> would rely on too much problem-specific knowledge.
>>>>
>>>> 3) When so much logic is embedded in the surface of the UI, it becomes
>>>> easy for widgets to become entangled with the ambient logic and state. This
>>>> makes it infeasible to extract, at a fine granularity, a few specific
>>>> signals and capabilities from one form for use in another.
>>>>
>>>> 4) Relying on deep inspection can violate encapsulation and security
>>>> properties. It would be difficult to move beyond a closed system into the
>>>> wider world - cross-application mashups, agents that integrate independent
>>>> services, and so on.
>>>>
>>>> If I'm to unify PL with UI, I cannot assume that I have access to the
>>>> code underlying the UI. Instead, I must ensure that the UI is a good PL at
>>>> the surface layer. We can understand UIs to be programming languages, but
>>>> often they are not very good languages with respect to composition,
>>>> modularity, appropriate level of abstraction. That's the problem to solve -
>>>> at the surface layer, not (just) under-the-hood.
>>>>
>>>> In such a system, "copy-and-paste code" could be *exactly the same* as
>>>> "copy-and-paste UI", though there may be different types of values
>>>> involved. We could have blocks of code that can be composed or directly
>>>> applied to UI elements - programmatically transforming or operating on
>>>> them. The moment users are forced to 'look under the hood' and extract
>>>> specification, the ideal fails. UI and PL are separated. There are now two
>>>> distinct surface syntaxes, two distinct meanings and semantics, and a gap
>>>> between them bridged with arcane logic.
>>>>
>>>> To unify PL and UI, widgets must *be* values, behaviors, signals, code.
>>>>
>>>> And any "looking under the hood" must be formally represented as
>>>> reflection or introspection, just as it would be in a PL.
>>>>
>>>>
_______________________________________________
fonc mailing list
[email protected]
http://vpri.org/mailman/listinfo/fonc
