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. >> >> On Mon, Sep 9, 2013 at 3:47 PM, John Carlson <[email protected]> wrote: >> >>> One thing you can do is create a bunch of named widgets that work >>> together with copy and paste. As long as you can do type safety, and can >>> appropriately deal with variable explosion/collapsing. You'll probably >>> want to create very small functions, which can also be stored in widgets >>> (lambdas). Widgets will show up when their scope is entered, or you could >>> have an inspect mode. >>> On Sep 9, 2013 5:11 PM, "David Barbour" <[email protected]> wrote: >>> >>>> I like Paul's idea here - form a "pit of success" even for people who >>>> tend to copy-paste. >>>> >>>> I'm very interested in unifying PL with HCI/UI such that actions like >>>> copy-paste actually have formal meaning. If you copy a time-varying field >>>> from a UI form, maybe you can paste it as a signal into a software agent. >>>> Similarly with buttons becoming capabilities. (Really, if we can use a >>>> form, it should be easy to program something to use it for us. And vice >>>> versa.) All UI actions can be 'acts of programming', if we find the right >>>> way to formalize it. I think the trick, then, is to turn the UI into a good >>>> PL. >>>> >>>> To make copy-and-paste code more robust, what can we do? >>>> >>>> Can we make our code more adaptive? Able to introspect its environment? >>>> >>>> Can we reduce the number of environmental dependencies? Control >>>> namespace entanglement? Could we make it easier to grab all the >>>> dependencies for code when we copy it? >>>> >>>> Can we make it more provable? >>>> >>>> And conversely, can we provide IDEs that can help the "kids" understand >>>> the code they take - visualize and graph its behavior, see how it >>>> integrates with its environment, etc? I think there's a lot we can do. Most >>>> of my thoughts center on language design and IDE design, but there may also >>>> be social avenues - perhaps wiki-based IDEs, or Gist-like repositories that >>>> also make it easy to interactively explore and understand code before using >>>> it. >>>> >>>> >>>> On Sun, Sep 8, 2013 at 10:33 AM, Paul Homer <[email protected]>wrote: >>>> >>>>> >>>>> These days, the "kids" do a quick google, then just copy&paste the >>>>> results into the code base, mostly unaware of what the underlying 'magic' >>>>> instructions actually do. So example code is possibly a bad thing? >>>>> >>>>> But even if that's true, we've let the genie out of the bottle and he >>>>> is't going back in. To fix the quality of software, for example, we can't >>>>> just ban all cut&paste-able web pages. >>>>> >>>>> The alternate route out of the problem is to exploit these types of >>>>> human deficiencies. If some programmers just want to cut&paste, then >>>>> perhaps all we can do is too just make sure that what they are using is >>>>> high enough quality. If someday they want more depth, then it should be >>>>> available in easily digestible forms, even if few will ever travel that >>>>> route. >>>>> >>>>> If most people really don't want to think deeply about about their >>>>> problems, then I think that the best we can do is ensure that their hasty >>>>> decisions are based on as accurate knowledge as possible. It's far better >>>>> than them just flipping a coin. In a sense it moves up our decision making >>>>> to a higher level of abstraction. Some people lose the 'why' of the >>>>> decision, but their underlying choice ultimately is superior, and the >>>>> 'why' >>>>> can still be found by doing digging into the data. In a way, isn't that >>>>> what we've already done with micro-code, chips and assembler? Or >>>>> machinery? >>>>> Gradually we move up towards broader problems... >>>>> >>>>>> >>>>>> >>>> _______________________________________________ >>>> fonc mailing list >>>> [email protected] >>>> http://vpri.org/mailman/listinfo/fonc >>>> >>>> >>> _______________________________________________ >>> fonc mailing list >>> [email protected] >>> http://vpri.org/mailman/listinfo/fonc >>> >>> >> >> _______________________________________________ >> fonc mailing list >> [email protected] >> http://vpri.org/mailman/listinfo/fonc >> >> > > _______________________________________________ > fonc mailing list > [email protected] > http://vpri.org/mailman/listinfo/fonc > >
_______________________________________________ fonc mailing list [email protected] http://vpri.org/mailman/listinfo/fonc
