Re: A couple of questions about goops method parameters

2014-09-07 Thread Neil Jerram
Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com writes:

 Panicz Maciej Godek godek.mac...@gmail.com writes:

 [...] 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). [...]

 An off-topic remark:

 I don't know about *functional* reactive programming but from my
 experience so far as an iOS developer, I've been *longing* for a
 reactive programming system that automates state changes even if not
 fully hiding them.  It would be invaluable being able to say
 button2.leftEdge = button1.rightEdge + 20px and have this equation be
 held automatically on changes to the layout of button1 (which might
 happen because it itself reacts to other layout changes), or to be able
 to say button.disabled = condition1 or condition2 and have the
 disabled status of button update automatically as the truthiness of the
 conditions changes.  (The former use-case is actually covered by layout
 constraints, but that's strictly limited to layouting.)

IIRC, Metafont does that; but obviously it isn't intended as a general
language.  Are there more general languages that solve equations like
this?

Regards,
Neil



Re: A couple of questions about goops method parameters

2014-09-07 Thread Taylan Ulrich Bayirli/Kammer
Neil Jerram n...@ossau.homelinux.net writes:

 IIRC, Metafont does that; but obviously it isn't intended as a general
 language.  Are there more general languages that solve equations like
 this?

From what I know, Prolog.

Other than that, Scheme. ;)

Apart from David's FRP implementation, I worked on the following a
little:

https://gitorious.org/taylan-guile/reactive/

(Warning: I might force-push commits to that repo at times.  It's not
ready for consumption.)

I don't consider it complete, and it might be broken.  Some simple
examples work:

guile ,use (reactive base)
guile (define x 0)
guile (define v (make-value () x))
guile (define v2 (make-value (v) (display recalculated\n) (+ v 5)))
guile (get/tainted v2)
recalculated
$2 = 5
guile (get/tainted v2)
$3 = 5
guile (set! x 1)
guile (taint! v)
guile (get/tainted v2)
recalculated
$4 = 6
guile

As you see, it's not purely-functional, and it requires explicit
tainting of root values.  After that, though, requesting any value
which directly or indirectly depends on that root will ignite a
recalculation of the graph of dependent values up to the requested one.

I continuously get confused while trying to reason about the precise
behavior of this system (even though it's very small), and had grave
bugs in it at times (actually I just fixed one while writing this
because I did a wholesale clean-up on the repo and re-uploaded it at the
above link).  Therefore, please don't trust that module for real
usage.

Taylan



Re: A couple of questions about goops method parameters

2014-09-07 Thread Taylan Ulrich Bayirli/Kammer
Marko Rauhamaa ma...@pacujo.net writes:

 It's perfectly fine to avoid errors by generalizing semantics so I
 wouldn't mind if you did what you propose. However, the dynamic type
 system is necessary for the simple fact that you will need to define
 runtime semantics.

Oh, I was rather looking at things from a low-level perspective.  E.g.
the foo string in my example was meant as a pointer, whose numeric
value plus 5 resulted in an integer whose underlying byte sequence is
then interpreted as an IEEE double.

In other words I was suggesting that by default there are only byte
sequences, and type systems help to work with these conveniently.

 No, the primary objective is not to prevent errors but to have
 well-defined semantics. Scheme, Python, C or Java would function
 perfectly well without any type error checking, static or dynamic. The
 results could be undefined or a burning computer, that doesn't matter.
 What matters is that you know what a well-defined program is supposed
 to do.

I think I understand your viewpoint, and it also makes sense: types
might not be essential to bit-crunching, but they are to abstract models
of computation.

 However, in my extensive practical experience, a static type system,

  [...]

Does that experience cover languages like SML, Ocaml, and Haskell?  (Not
a rhetorical question, though I suspect it doesn't; at least not as much
as languages like C, C++, and Java.)

Taylan



Re: A couple of questions about goops method parameters

2014-09-07 Thread Marko Rauhamaa
Taylan Ulrich Bayirli/Kammer taylanbayi...@gmail.com:

 Marko Rauhamaa ma...@pacujo.net writes:
 However, in my extensive practical experience, a static type system,

  [...]

 Does that experience cover languages like SML, Ocaml, and Haskell?

I have had superficial experience with SML way back (late 80's). No idea
how the languages would work in practice. However, I don't feel I'm
missing anything in Scheme.

 (Not a rhetorical question, though I suspect it doesn't; at least not
 as much as languages like C, C++, and Java.)

Not anywhere near as much. What do you have to say about those
languages?


Marko



Re: A couple of questions about goops method parameters

2014-09-07 Thread Taylan Ulrich Bayirli/Kammer
Marko Rauhamaa ma...@pacujo.net writes:

 Not anywhere near as much. What do you have to say about those
 languages?

Just what I said previously: many users of languages with more
sophisticated static type systems like Ocaml or Haskell say they prefer
that over dynamic typing.  I don't have much experience myself, though
at times I also felt positive about the ability to encode some logic in
a static type system.

Taylan