Initialization blocks for REPLoid

[ttuegel]

I like to call out to R with inline-r from my Haskell buffers. This requires that I initialize R in a particular way, so I have a code block at the top of the file with the appropriate commands. But, that requires that I remember to run that block before I try to evaluate any other code blocks! It would be nice to be able to designate an "initialization" block that is guaranteed to be run before any other code blocks in a buffer.

[jyp]

This feature requires some design. It may also be generalized in some directions (sessions, general notion of state, etc.). I think that we should use this ticket to have a discussion before diving into an implementation.

[jyp]

I've just added multi-stanza blocks. Let me know if that helps.

[jyp]

I'm thinking at the moment to drop the idea of having long-term sessions and state. The reason is that for flychecking purposes dante loads and reloads modules constantly. Keeping a session open would require a nother ghci instance running (like intero does) and I believe that the price/performance ratio is too high. (@dabro)

I may get into implementing plain initialization blocks later.

[dabro]

@jyp I think the 2nd GHCi session cost is already being paid somewhere. Either we're using the haskell-interactive-mode repl, or opening one up somewhere else. Who doesn't have a need for sessions during development?

Maybe integrating the haskell-mode repl?

On the upside of the current setup, the user does make the choice as to whether to load and use that 2nd repl, and which modules to load (and when).

[jyp]

The cost is in me maintaining the complexity :) Another reason for not having a state is that IMO, the style of interaction which dante has does not make obvious that there is a session open and what happens in it at any time. In fact it tries hard to hide the prompt, etc. I would encourage users to use a simple comint-based mode for ghci if there goal is to maintain long-lived sessions.

…

On Mon, Oct 2, 2017 at 4:21 PM, dabro ***@***.***> wrote: @jyp <https://github.com/jyp> I think the 2nd GHCi session cost is already being paid somewhere. Either we're using the haskell-interactive-mode repl, or opening one up somewhere else. Who doesn't have a need for sessions during development? Maybe integrating the haskell-mode repl? On the upside of the current setup, the user does make the choice as to whether to load and use that 2nd repl, and which modules to load (and when). — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AABsY36AKAVttrNYIoJD98ctIBgEoOv5ks5soPF1gaJpZM4NJC0e> .

[dabro]

All makes lots of sense. Thanks. Awesome product.

…

On Oct 2, 2017, at 9:28 AM, Jean-Philippe Bernardy ***@***.***> wrote: The cost is in me maintaining the complexity :) Another reason for not having a state is that IMO, the style of interaction which dante has does not make obvious that there is a session open and what happens in it at any time. In fact it tries hard to hide the prompt, etc. I would encourage users to use a simple comint-based mode for ghci if there goal is to maintain long-lived sessions. On Mon, Oct 2, 2017 at 4:21 PM, dabro ***@***.***> wrote: > @jyp <https://github.com/jyp> I think the 2nd GHCi session cost is > already being paid somewhere. Either we're using the > haskell-interactive-mode repl, or opening one up somewhere else. Who > doesn't have a need for sessions during development? > > Maybe integrating the haskell-mode repl? > > On the upside of the current setup, the user does make the choice as to > whether to load and use that 2nd repl, and which modules to load (and when). > > — > You are receiving this because you were mentioned. > Reply to this email directly, view it on GitHub > <#15 (comment)>, or mute > the thread > <https://github.com/notifications/unsubscribe-auth/AABsY36AKAVttrNYIoJD98ctIBgEoOv5ks5soPF1gaJpZM4NJC0e> > . > — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#15 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AInFRVCJfe8rFNr8m4ThDPE6OZPOdvTaks5soPMUgaJpZM4NJC0e>.

[sboosali]

should we close this as wontfix? I think I agree with @jyp about keeping the block evals simple.

maybe we can make a dante-yank-block command, so the block can then be pasted into your own ghci buffer. since it already exists internally, and it let's you write doctests with the same formatting, whether or not they need initialization.

[jyp]

@sboosali I'm thinking that an initialization block per file is a good idea, in fact. This could be implemented by running the initialization block every time that a reploid block is evaluated. (And so there is little complexity overhead)

[jyp]

This feature should follow the https://github.com/sol/doctest spec.

[sboosali]

By spec, you mean the syntax and behavior of stuff like

$setup

right? Doesn't that require some parsing of the source, like the comments and imports?

[jyp]

I am plannig to simply regexp search "-- $setup" or similar.

[sboosali]

yeah, same :-)