Panicz Maciej Godek <godek.mac...@gmail.com> writes: > 2014-09-05 21:12 GMT+02:00 David Thompson <dthomps...@worcester.edu>: >> Panicz Maciej Godek <godek.mac...@gmail.com> writes: >>> >>> So perhaps you could tell me how to design a GUI framework in FP and >>> without OOP. To me it seems that GUI is the main domain the OOP was >>> crafted for, but if you have some nice functional ideas, perhaps you >>> could help me to redesign my framework. >>> >> >> Are you familiar with functional reactive programming? >> >> http://elm-lang.org/learn/What-is-FRP.elm >> >> Using FRP, we can model with mutable state in a pure, functional way. >> That is, the necessary mutation is hidden behind the runtime of the FRP >> implementation. >> >> Just some food for thought. > > Sure, I've been reading a lot, but I didn't manage to get much of it. > I mean, the toy examples are really nice, but it's hard for me to see > the advantage of FRP over OOP in practical systems (e.g. windowed > applications with buttons and so on). Although I see value in > encapsulating state mutations, the notion of state seems inevitable in > describing such applications (like the mere fact that a checkbox can > be checked or not -- so it's a state which is a part of the > description). >
Yes, it's state, and state will always be there in a realtime application. However, you can still model it in a functional way with procedures that are idempotent and objects that are immutable. You just need to glue it all together with something that tracks the current state of the application. > BTW I recently ran into a problem with your signal propagation > framework from (guile 2d). Namely, if a signal is itself a mutable > object (like a vector or an array), then changing the value of that > object doesn't propagate (because it happens only when you use > slot-set!, and not (vector-set! (slot-ref ...)...)). > I can't find any workaround for that. I don't consider it a problem because the values stored signals are intended to be immutable. I will make that clear when I get around to documenting things better. If you mutate an object within the signal graph, bad things are bound to happen. The only reasonable side-effects are those that do not change values stored within signals, like writing to a log file or playing a sound. I have intentionally kept mutation at lowest layer of the system, abstracted away from the user. -- David Thompson Web Developer - Free Software Foundation - http://fsf.org GPG Key: 0FF1D807 Support the FSF: https://fsf.org/donate
