[racket] An elm-like racket language?

Nothing really *stops* you (-:, but you should be careful to make sure
you really are writing a reactive program (ie, importing it into a
random Racket module may cause strange behavior). But for sure, please
give it a try and let us know how it's working out!

Shriram

On Wed, Nov 13, 2013 at 2:37 AM, Philip Monk <pcmonk at asu.edu> wrote:
> I don't think I'll need the GUI bindings, since I'm mostly using my own GUI
> system (just a big openGL canvas%).  I imagine that I could just have my
> system generate events and create behaviors on its own and just use the
> update model.  Is there anything stopping me from being able to just
> `(require frtime)` and use all the reactive stuff?
>
> Philip Monk
>
>
> On Wed, Nov 13, 2013 at 12:01 AM, Gregory Cooper <ghcooper at gmail.com> wrote:
>>
>> Similarly to what Shriram said, I think a big problem with FrTime is that
>> it's monolithic. It could (in my opinion) be greatly improved if the core
>> update model were decoupled from any language extensions, global state, or
>> threads, i.e., made into something that could be independently instantiated,
>> tested, and combined with other libraries. This would make it more modular,
>> easier to understand and maintain, etc.
>>
>> Greg
>>
>> PS. As far as I know the GUI bindings do still work...  :-)
>>
>>
>>
>> On Tue, Nov 12, 2013 at 10:31 PM, Shriram Krishnamurthi <sk at cs.brown.edu>
>> wrote:
>>>
>>> I think the core stuff will continue to work fine; I imagine the GUI
>>> bindings have ossified by now.
>>>
>>> You may actually find it useful to look at some of the examples on the
>>> Flapjax site (www.flapjax-lang.org). There, we were actively trying to
>>> convey an idea to a community that thought didn't think that way.
>>> FrTime was written for Schemers, the first cousins of functional
>>> programmers, so we didn't think we needed to explain much. (Though
>>> there are still some interesting demos in the distro.)
>>>
>>> The one thing I wish we'd done was figured out a really, really clean
>>> way to have just a part of the program be reactive, and the rest of it
>>> be normal. We talked about this, and at some point Greg even
>>> implemented a macro that let you "inject reactivity" into an
>>> expression (so to speak). I don't know it's status. It's a question
>>> I'm starting to reopen in my head in Pyret.
>>>
>>> Shriram
>>>
>>> On Tue, Nov 12, 2013 at 11:58 PM, Philip Monk <pcmonk at asu.edu> wrote:
>>> > I've been interested in FRP for a while, but I haven't yet found a way
>>> > to
>>> > learn it, and I'm thinking FrTime might be a good way.  I'm the kind of
>>> > guy
>>> > who learns stuff best by integrating them into my projects, and I'm
>>> > working
>>> > on a project in Racket right now that seems like it could benefit.  How
>>> > hard
>>> > would it be to integrate frtime into an existing project?  I assume
>>> > that I
>>> > would create most of my own signals and whatnot, but it looks like I
>>> > should
>>> > be able to use the same update mechanism even without using #lang
>>> > FrTime.
>>> >
>>> > Are there any particular docs and/or code I should read (aside from the
>>> > basic docs online and your paper)?  Any tips?
>>> >
>>> > Philip Monk
>>> >
>>> >
>>> > On Tue, Nov 12, 2013 at 2:54 PM, Shriram Krishnamurthi
>>> > <sk at cs.brown.edu>
>>> > wrote:
>>> >>
>>> >> Hi Dan,
>>> >>
>>> >> I don't think anyone is using FrTime, because nobody in the Racket
>>> >> community really expressed much interest in it, so it didn't gain
>>> >> enough momentum. I concluded that the kind of person who likes Racket
>>> >> is perfectly happy with Racket's existing GUI libraries, and FrTime
>>> >> was solving a non-problem for them.
>>> >>
>>> >> That said, a few people have given it a whirl, suggested a bug, or
>>> >> provided an enhancement. It just hasn't had anywhere near the level of
>>> >> sustained interest as Racket.
>>> >>
>>> >> Does that make sense?
>>> >>
>>> >> Shriram
>>> >> ____________________
>>> >>   Racket Users list:
>>> >>   http://lists.racket-lang.org/users
>>> >
>>> >
>>
>>
>