Re: org-babel -- Improper syntax error in session mode?

[Eric Schulte <schulte.eric@gmail.com>]

Perhaps I should explain my personal view of what Babel "sessions" are,
I'm not saying this is *the* view, just my own.

Babel sessions explicitly are thin wrappers around the interactive mode
of the language in question (whatever that may be).  That is why Babel
happily doesn't implement sessions for all languages, the contract
simply is that if a language supports interactive evaluation, Babel will
try to allow access to that functionality.

If the contract was rather simply "Babel provides session based
evaluation", then we'd be on the hook for implementing session
evaluation where it doesn't already exist and may not make sense (e.g.,
C, ditaa), and normalizing everywhere else as you're suggesting here.
Which would in turn requires us to spell out Babel-specific semantics of
session based evaluation -- something we have thus-far avoided.

Some positive points *for* the "thin wrapper" approach include;

1. It is the simplest to implement
   - easier to implement support for new language
   - easier to maintain -- especially if interactive tools change
   - easier to reason about -- thinking about bug fixing here
   - works with alternate back-ends e.g., ipython

2. It is the least surprising.  I'd maintain that for users familiar
   with using Python sessions this behavior is the easiest to quickly
   understand and use.  As opposed to if we did something fancy (even if
   it was an improvement) it would be another environment for language
   users to have to familiarize themselves with -- they'd have both
   normal session rules and babel session rules

I guess that's it, I'm happy to be convinced otherwise, or simply be
outvoted.  If you want to look at the code I'm happy to help in any way
I can, my previous patch would probably be a good place to start.  Just
be careful, if you get too comfortable with Emacs Lisp you might find it
hard to go back to working with VM's extension language. :)

a few more scattered comments below...

Herbert Sitz <hsitz@nwlink.com> writes:

[...]
>
> Maybe adding the extra lines is beyond Babel's scope, strictly speaking.  I can
> think of some good reasons for doing it though:
>
> (1a)  Babel is not an interactive shell.
>

Exactly, it is a window to a language's interactive run-time as defined
by the language's tools.

>
> (1b)  It's not obvious to the Babel user that sessions are being processed using
> Python's interactive shell.

I'd disagree, to my mind this is the simplest explanation of session
evaluation.

> Even if that is known (I know it's somewhere in the docs),

Perhaps the documentation should be tweaked to make this point more
clear.

> it's not clear to a user why Babel would require a user to insert the
> extra lines (and, it turns out, _avoid_ blank lines in other cases),
> which make sense in interactive environment but not within Babel's
> non-interactive environment.  Even if this particular idiosyncrasy is
> documented somewhere it's going to cause confusion for users who skim
> the docs and just expect regular Python code to work without problems.

But any *other* behavior would be surprising to users who are familiar
with using Python's interactive shell, and think of code blocks as
simply a place to store transcripts of interactive sessions they may
want to dump back into the session at some point in the future.

> 
> (If I'm first to report the issue maybe there aren't many Org users
> trying to use :session mode with Python, though.)
>

or (if they are regular Python users) they didn't find this behavior to
be surprising.

>
> (2)  Isn't the blank-line issue an easy fix?  I think it requires just these two
> simple changes to source block before submitting to python shell:  (a)  Regex
> search replace to add a blank line before any "unindented" line that is preceded
> by an indented line (actually it may work fine to just put blank line before
> _any_ "unindented" textline in the source-block); and (b) deletion of all blank
> lines in the source-block that are followed by "indented" text on next line.  
>

I agree, it shouldn't be an overly difficult fix, but I'm worried about
precedent.  This gives me a distinct "foot in the door" feeling, and it
breaks the /thin wrapper/ contract I spelled out above.

>
>
>> Does it work for other "normal" Python interactive code blocks?  Have
>> you noticed any places where the previous version worked but the new
>> version doesn't?  If it seems safe then I would like to apply it.
>
> I think the <Results> start with a stray blank line before what should be the
> actual output.  Otherwise It does seem to be working well with the few more
> complicated things I've created to throw at it.  
>

Great, thanks.  I appreciate you testing this out.  I've just applied
the patch since, regardless of the outcome of this thread I think we're
all agreed that the patch is better than the current behavior.

>
> I'm not really a big Python user, was just doing some testing in my
> vim-Org-clone with Python when I noticed the problem.  If you end up not
> addressing the line-insertion issue I may put it on my todo-list for my first
> real adventure in learning elisp.
>

Cool, I'm happy to help, either with your digging into elisp, or by
providing Babel information/opinions for the VM clone.  It's an
incredible undertaking to re-implement something as massive as Org-mode
in a new environment and I'm excited to hear you're getting up to the
more esoteric features like Babel.

Best -- Eric

>
> Regards,
>
> Herb
>
>
>
>

-- 
Eric Schulte
http://cs.unm.edu/~eschulte/