[IPython-dev] IScala: a Scala-language backend for IPython

[Brian Granger]

> I think the IPython's notebook format is already quite language
> independent. It's the interpretation of the format that has to be
> improved (e.g. adding syntax highlight for other languages).

I think you are confusing what the notebook format handles.  It knows
nothing about syntax highlighting.  Each code cell has a language
field that can be set.  The problem right now is with the frontend,
which doesn't set that field and switch syntax highlighting
appropriately.

> I would
> invent my adhoc format (xipynb) even if I was creating notebooks with
> Python code, because editing JSON manually is not an option for me
> (for quite obvious reasons). Neither is using Notebook app for major
> editorial work (although, for running code is OK), at least until
> vim-like key bindings are supported on cell and intra-cell level (the
> other is equally important, because writing code/text vim style and
> switching to emacs style for cell manipulation would be very
> inefficient) (vim is too deeply wired in my mind). However, I may not
> like JSON, but it's good you chose an encoding of the format that has
> a (stable) specification and allows for easy automatic processing. I
> think that there should be a format that can be easily processed,
> converted etc. and understood by Notebook app, but which doesn't have
> to be easily editable without specialized tools, and then, there could
> be formats that aren't that easy to process, but allow for easy
> editing (etc.). Then, scripts for converting to/from those formats
> could be plugins to nbconvert. I don't expect Notebook app or html
> generator to understand those extra formats directly.

I can understand why you would create another format if you want to
easily be able to edit the notebook documents by hand though.  JSON is
horrlble for that.

Cheers,

Brian

> Speaking about JSON, if you have a moment, you may want to look into
> [1]. I implemented message specification there in an object-oriented
> and type safe way (there is room for improvements). Originally I just
> copied text from [2] and filled in "blanks", so the structure is
> similar and comments are in place. It may be advantageous to abstract
> the specification over JSON+Python's types. So, if there's a `list`,
> then write what kind of list it should be, e.g. `list<int>` (here
> Java/C++ style), the same for dictionaries/maps and tuples. If there
> is "MIME type" involved, then define it, because I can assume it's a
> string, but I could imagine it being a 2-tuple. Also use enumerations
> instead of strings. In my opinion this will make the specification
> much more formal and understandable and allow for removal of
> substantial number of comments, which are otherwise unavoidable.
>
> But those little issues when looking at big picture. In general my
> experience have been pleasant and finally I have an environment for
> interactive computing with Scala.
>
> [1] https://github.com/mattpap/IScala/blob/master/src/main/scala/Msg.scala
> [2] http://ipython.org/ipython-doc/dev/development/messaging.html
>
>> Cheers,
>>
>> f
>> _______________________________________________
>> IPython-dev mailing list
>> IPython-dev at scipy.org
>> http://mail.scipy.org/mailman/listinfo/ipython-dev
>
> Mateusz
> _______________________________________________
> IPython-dev mailing list
> IPython-dev at scipy.org
> http://mail.scipy.org/mailman/listinfo/ipython-dev



-- 
Brian E. Granger
Cal Poly State University, San Luis Obispo
bgranger at calpoly.edu and ellisonbg at gmail.com