I’ve been using ob-ipython in
org-mode lately with ijulia as the kernel. In general, it works pretty well and
papers over some of the current issues with ob-julia. The one thing it doesn’t
do natively is formatting the results as org-mode tables when an array or
dataframe is returned. To get around this, I currently have the following
snippet in my .juliarc.jl (definition for orgify not shown but can be shared
if interest).
"Tries to represent arrays as an org-table"
function Base.show(st::IO, ty::MIME"text/org", x::AbstractArray)
stringrepresentations = map(string,x)
write(st, orgify(stringrepresentations))
end
"Tries to represent as an org-table"
function Base.show(st::IO, ty::MIME"text/org", x)
write(st, orgify(x))
end
This works fairly well for my purposes, but it occurred to me that this is
functionality probably worth sharing (whether shared as julia package or emacs
package yet to be determined). However, I shouldn’t really be publishing a package
anywhere that has this kind of type-piracy. Any ideas how to avoid the
type-piracy here?
Sorry, I was confused and thought that MIME"text/org" types are used in Base. If they are not, I don’t think type piracy is an issue (recall that MIME is a parametric type). I would just put it wherever orgify is.
Issue is that AbstractArray is defined in Base even if you’re right about the
thing where parametric types don’t count as type-piracy so long as the specific
parameter isn’t used in the original package. Or maybe I’m just totally
misunderstanding what is meant by “type-piracy”.
I would make this suggestion again — if there is at least one type in the signature that you “own”, defining a method it is not type piracy.
I understand the concern about MIME — “ownership” can be hazy with parametric types — but I think that the idea behind it is precisely that people should extend it.