[ELPA] New package: ob-haxe

[ELPA] New package: ob-haxe

[ian martins]

Hello. I'd like ob-haxe [1] to be added to gnu elpa. It is an
org-babel integration for the haxe programming language [2]. I don't
have push access to ELPA.

[1] https://github.com/ianxm/ob-haxe.el
[2] https://haxe.org

Re: [ELPA] New package: ob-haxe

[Stefan Monnier]

Hi Ian,

> Hello. I'd like ob-haxe [1] to be added to gnu elpa. It is an
> org-babel integration for the haxe programming language [2]. I don't
> have push access to ELPA.

I'd be happy to do that, but just to be sure, I'd like to understand
something first.  AFAICT, all other `ob-<LANG>.el` files are currently
bundled with Org.  Personally, I'd tend to consider that the
language-specific info for org-babel should belong with the major mode
(just like the language-specific support for indentation, highlighting,
flymake, imenu, etc.. belong to it).
[ Side note: I'm not sufficiently familiar with org-babel to know if
  bundling the info with the major mode is currently technically
  realistic.  ]

So based on the above, I'd expect `ob-haxe` to be distributed either
with Org or with `haxe-mode` rather than separately.

What do you (and the Org maintainers and the haxe-mode
maintainers) think?


        Stefan

Re: [ELPA] New package: ob-haxe

[ian martins]

On Sun, Jan 17, 2021 at 5:41 PM Stefan Monnier <monnier@iro.umontreal.ca> wrote:

> > Hello. I'd like ob-haxe [1] to be added to gnu elpa. It is an
> > org-babel integration for the haxe programming language [2]. I don't
> > have push access to ELPA.
>
> I'd be happy to do that, but just to be sure, I'd like to understand
> something first.  AFAICT, all other `ob-<LANG>.el` files are currently
> bundled with Org.

Thanks for responding. No, actually there are many that are maintained
outside of Org.  If you search github for "org babel" some will come
up. I see 46 packages that start with "ob-" in my `list-packages'.

Of the ones that are bundled with Org, there are some that are
considered "core" and others that are "contrib." I offered ob-haxe on
the Org list and the maintainers said they didn't think it was
appropriate for core and also that they were moving to shift more of
the "contrib" language integrations out of the Org repo and into
separate packages and suggested GNU ELPA for this.

> Personally, I'd tend to consider that the
> language-specific info for org-babel should belong with the major mode
> (just like the language-specific support for indentation, highlighting,
> flymake, imenu, etc.. belong to it).
> [ Side note: I'm not sufficiently familiar with org-babel to know if
>   bundling the info with the major mode is currently technically
>   realistic.  ]

I don't know if there's a technical problem with that approach, but
I'm not aware of any case where it's done that way. All of the Org
Babel language integrations I've seen have been bundled with Org or
distributed as a separate package.

I wasn't aware that usually language major modes came with more than
indentation and highlighting.

If there's more than one package to choose from for a language's major
mode, would the Org Babel functions have to be included in both of
them?

Re: [ELPA] New package: ob-haxe

[ASSI]

Stefan Monnier writes:
> I'd be happy to do that, but just to be sure, I'd like to understand
> something first.  AFAICT, all other `ob-<LANG>.el` files are currently
> bundled with Org.

They aren't, there's quite a bunch of them that aren't properly inside
Org and of those that are, just a selected set is in Org core (only
those should be in Emacs by default).  The reasons are diverse, but for
a package to considered for core it must have copyright assigned to FSF,
suppport the complete feature set as far as the underlying language or
interpreter allows for it (i.e. session mode) and have an active
maintainer (Bastien or Nicolas can give you the "official" line on
that).  Secondary considerations are how common the language supported
really is and what it takes to set up an environment where you can
actually run tests.

> Personally, I'd tend to consider that the
> language-specific info for org-babel should belong with the major mode
> (just like the language-specific support for indentation, highlighting,
> flymake, imenu, etc.. belong to it).
> [ Side note: I'm not sufficiently familiar with org-babel to know if
>   bundling the info with the major mode is currently technically
>   realistic.  ]

Let's put it this way: I haven't seen any major mode that does that so
far.  I think the idea merits consideration, but as long as nobody tries
we don't really know what the pitfalls are.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

Waldorf MIDI Implementation & additional documentation:
http://Synth.Stromeko.net/Downloads.html#WaldorfDocs

Re: [ELPA] New package: ob-haxe

[Stefan Monnier]

>> I'd be happy to do that, but just to be sure, I'd like to understand
>> something first.  AFAICT, all other `ob-<LANG>.el` files are currently
>> bundled with Org.
>
> Thanks for responding. No, actually there are many that are maintained
> outside of Org.  If you search github for "org babel" some will come
> up. I see 46 packages that start with "ob-" in my `list-packages'.
>
> Of the ones that are bundled with Org, there are some that are
> considered "core" and others that are "contrib." I offered ob-haxe on
> the Org list and the maintainers said they didn't think it was
> appropriate for core and also that they were moving to shift more of
> the "contrib" language integrations out of the Org repo and into
> separate packages and suggested GNU ELPA for this.

Good, thanks.

>> Personally, I'd tend to consider that the
>> language-specific info for org-babel should belong with the major mode
>> (just like the language-specific support for indentation, highlighting,
>> flymake, imenu, etc.. belong to it).
>> [ Side note: I'm not sufficiently familiar with org-babel to know if
>>   bundling the info with the major mode is currently technically
>>   realistic.  ]
>
> I don't know if there's a technical problem with that approach, but
> I'm not aware of any case where it's done that way. All of the Org
> Babel language integrations I've seen have been bundled with Org or
> distributed as a separate package.
>
> I wasn't aware that usually language major modes came with more than
> indentation and highlighting.

Historically, major modes came with very little support, and over time
this set of supported facilities grows.

E.g. font-lock came with its own support for some major modes, and then
it quickly became clear that font-lock support for a particular language
is better placed in the major mode than in font-lock.el.

The same applies to most other such features: it's impractical for
flymake/flycheck/company/org-babel/... to come with support for all
languages, but it's also inconvenient for the user to have to install

    FOO
    ob-FOO
    company-FOO
    flymake-FOO
    younameit-FOO

before Emacs provides adequate support for the language FOO.  So as much
as possible, I think it makes sense to include those things along with
the language's major mode.

> If there's more than one package to choose from for a language's major
> mode, would the Org Babel functions have to be included in both of
> them?

Good question.  As a general rule "more than one package to choose from
for a language's major mode" is itself a problem (especially because
more often than not, it means none of the options are really maintained
and the choice is really between different sets of shortcomings).

So, IIUC you're saying that there is no main `haxe-mode` anyway into
which we could integrate `ob-haxe`?  If so, and since Org doesn't want
it, we should add it as a separate package, indeed.

[ Side note: if noone has come up to develop&maintain "the one and only"
  haxe-mode (which combines the good parts of the existing haxe modes),
  would you be willing to do that?  ]


        Stefan

Re: [ELPA] New package: ob-haxe

[Stefan Monnier]

> Let's put it this way: I haven't seen any major mode that does that so
> far.  I think the idea merits consideration, but as long as nobody tries
> we don't really know what the pitfalls are.

Someone has to be the first.


        Stefan

Re: [ELPA] New package: ob-haxe

[Richard Stallman]

[[[ To any NSA and FBI agents reading my email: please consider    ]]]
[[[ whether defending the US Constitution against all enemies,     ]]]
[[[ foreign or domestic, requires you to follow Snowden's example. ]]]

Before we install ob-haxe, how about giving it a longer name
that more clearly suggests what it does?

-- 
Dr Richard Stallman
Chief GNUisance of the GNU Project (https://gnu.org)
Founder, Free Software Foundation (https://fsf.org)
Internet Hall-of-Famer (https://internethalloffame.org)

Re: [ELPA] New package: ob-haxe

[Stefan Monnier]

> Before we install ob-haxe, how about giving it a longer name
> that more clearly suggests what it does?

Note a chance.  `ob-[LANGUAGE]` is the standard name used for that.


        Stefan

Re: [ELPA] New package: ob-haxe

[ian martins]

> it's impractical for
> flymake/flycheck/company/org-babel/... to come with support for all
> languages, but it's also inconvenient for the user to have to install
>
>     FOO
>     ob-FOO
>     company-FOO
>     flymake-FOO
>     younameit-FOO
>
> before Emacs provides adequate support for the language FOO.  So as much
> as possible, I think it makes sense to include those things along with
> the language's major mode.

This makes sense to me, but I don't see why the solution has to be to
combine them all into a single package.

If putting everything related to flymake doesn't work, couldn't the
same problems arise if we clump together everything related to a
language? It's the same solution (partitioning functionality into
packages based on relatedness), but now we're slicing it on a
different axis [language] than before [feature]. I may be missing the
main issue, but suspect the problem with keeping all languages in
flymake is that users don't want to install flymake implementations
for languages they don't use and maintainers don't want to maintain
code they aren't familiar with.  Both of these problems would apply to
major modes that include everything related to that language. There
are probably many people who use haxe but don't use Org.

Another option is to have small packages with specific functions, and
use dependencies to build up larger chunks of functionality. Would it
solve the problem if we had a haxe-bundle package with dependencies on
haxe-mode and ob-haxe? Then users only have to find one package to
install all haxe functionality if they want it, but if they don't want
it all they can pick individual packages instead.  Also that way all
of the code is maintained by those who know it best.  Also, parent
packages can be created today to encompass existing languages
relatively easily, but merging all of the existing packages for each
language together into major modes would be a large effort and
significant disruption to those projects.

> > If there's more than one package to choose from for a language's major
> > mode, would the Org Babel functions have to be included in both of
> > them?
>
> Good question.  As a general rule "more than one package to choose from
> for a language's major mode" is itself a problem (especially because
> more often than not, it means none of the options are really maintained
> and the choice is really between different sets of shortcomings).

I'm not sure about this rule. How can we know that two competing
packages won't be maintained? Doesn't it depend on relative interest
and the size of the community using them?

Even if competing packages don't co-exist for long, there can be some
time after someone clones a package to try it another way and the
community has two options. If someone cloned haxe-mode and it included
ob-haxe, then for as long as they both existed, updates to ob-haxe
would have to be pushed to both haxe-modes.

> So, IIUC you're saying that there is no main `haxe-mode` anyway into
> which we could integrate `ob-haxe`?  If so, and since Org doesn't want
> it, we should add it as a separate package, indeed.

No, sorry, I was asking hypothetically. Actually I think there were
multiple haxe major modes at one point but I checked yesterday and saw
only one (there are a couple other haxe packages, but just one major
mode). I asked because if ob-haxe should be a separate package in this
case, then should we follow that pattern in the general case, since
any major mode can have two packages at some point in time?

Re: [ELPA] New package: ob-haxe

[Stefan Monnier]

>> it's impractical for
>> flymake/flycheck/company/org-babel/... to come with support for all
>> languages, but it's also inconvenient for the user to have to install
>>
>>     FOO
>>     ob-FOO
>>     company-FOO
>>     flymake-FOO
>>     younameit-FOO
>>
>> before Emacs provides adequate support for the language FOO.  So as much
>> as possible, I think it makes sense to include those things along with
>> the language's major mode.
>
> This makes sense to me, but I don't see why the solution has to be to
> combine them all into a single package.
>
> If putting everything related to flymake doesn't work, couldn't the
> same problems arise if we clump together everything related to
> a language?

In theory, yes.

> It's the same solution (partitioning functionality into packages based
> on relatedness), but now we're slicing it on a different axis
> [language] than before [feature].

Indeed.  In practice it tends to work much better, but there's no
guarantee: one size never fits all.

> I may be missing the main issue, but suspect the problem with keeping
> all languages in flymake is that users don't want to install flymake
> implementations for languages they don't use and maintainers don't
> want to maintain code they aren't familiar with.

Not only that.  Typically, the code that provides flymake support for
a given language will need to know something about that language and
some of that info is also needed in the major-mode (e.g. the name of the
compiler), so the two will usually want to share some
defconst/defcustom, but you can't have flymake *depend* on all those
major modes, so you typically end up with duplication.

> Both of these problems would apply to major modes that include
> everything related to that language.

I think part of the reason why the tradeoffs are different is that the
number of "infrastructure" packages (font-lock, imenu, flymake, company,
eglot, org-babel, smie, ...) tends to be much smaller and grow much less
frequently than the number of languages.

> Another option is to have small packages with specific functions, and
> use dependencies to build up larger chunks of functionality.

Of course.

> Would it solve the problem if we had a haxe-bundle package with
> dependencies on haxe-mode and ob-haxe?

I don't think there's really a problem to solve, really.

> Then users only have to find one package to install all haxe
> functionality if they want it, but if they don't want it all they can
> pick individual packages instead.

If there is an actual choice for the user, that's good.  But if the
choice is only "include org-babel support or not" then I think this is
actually detrimental for the user: the gain of not having org-babel
support for those users not using org-babel *should* be negligible
(i.e. it should not incur extra dependencies and the increase in size
should be irrelevant).

> Also that way all of the code is maintained by those who know it best.
> Also, parent packages can be created today to encompass existing
> languages relatively easily, but merging all of the existing packages
> for each language together into major modes would be a large effort
> and significant disruption to those projects.

Nobody is forcing them to be merged.  I'm just saying that history tells
us that they tend to merge that way, and that it's usually a good thing
both for the users and for technical reasons.  So we may as well
consciously move in that direction whenever convenient.

>> Good question.  As a general rule "more than one package to choose from
>> for a language's major mode" is itself a problem (especially because
>> more often than not, it means none of the options are really maintained
>> and the choice is really between different sets of shortcomings).
> I'm not sure about this rule.

I am.

> How can we know that two competing packages won't be maintained?

We don't (and nowhere did I say that we do).

>> So, IIUC you're saying that there is no main `haxe-mode` anyway into
>> which we could integrate `ob-haxe`?  If so, and since Org doesn't want
>> it, we should add it as a separate package, indeed.
> No, sorry, I was asking hypothetically.  Actually I think there were
> multiple haxe major modes at one point but I checked yesterday and saw
> only one (there are a couple other haxe packages, but just one major
> mode).

Good.  Then I think it would be good to try and work with the
major-mode's maintainer and merge the two packages.

In the mean time, I'll do the initial addition of `ob-haxe` to GNU ELPA.


        Stefan

Re: [ELPA] New package: ob-haxe

[ian martins]

> > I may be missing the main issue, but suspect the problem with keeping
> > all languages in flymake is that users don't want to install flymake
> > implementations for languages they don't use and maintainers don't
> > want to maintain code they aren't familiar with.
>
> Not only that.  Typically, the code that provides flymake support for
> a given language will need to know something about that language and
> some of that info is also needed in the major-mode (e.g. the name of the
> compiler), so the two will usually want to share some
> defconst/defcustom, but you can't have flymake *depend* on all those
> major modes, so you typically end up with duplication.

That makes sense. Where there is shared code or variables it makes
sense to keep the implementations together.  For the ob-haxe and
haxe-mode case the implementations are independent of each other.  I
guess if haxe had a flymake integration it would want to share the
compiler name variable with ob-haxe, though.

> > Both of these problems would apply to major modes that include
> > everything related to that language.
>
> I think part of the reason why the tradeoffs are different is that the
> number of "infrastructure" packages (font-lock, imenu, flymake, company,
> eglot, org-babel, smie, ...) tends to be much smaller and grow much less
> frequently than the number of languages.

That's a good point.

> Nobody is forcing them to be merged.  I'm just saying that history tells
> us that they tend to merge that way, and that it's usually a good thing
> both for the users and for technical reasons.  So we may as well
> consciously move in that direction whenever convenient.
> ...
> Good.  Then I think it would be good to try and work with the
> major-mode's maintainer and merge the two packages.

I am not yet convinced of it, smaller packages and dependencies seem
neater and more flexible to me.  But as you say, history tells us that
is what tends to happen, so maybe it will be.

Do you think it would be better to merge the packages or just add a
dependency from haxe-mode to ob-haxe? Does it make a difference?

> In the mean time, I'll do the initial addition of `ob-haxe` to GNU ELPA.

Thank you.

Re: [ELPA] New package: ob-haxe

[Stefan Monnier]

> That makes sense. Where there is shared code or variables it makes
> sense to keep the implementations together.  For the ob-haxe and
> haxe-mode case the implementations are independent of each other.

That's inevitably the case, given that they were developed separately.

> I guess if haxe had a flymake integration it would want to share the
> compiler name variable with ob-haxe, though.

Yup, same thing if there was a REPL with an inferior-haxe-mode.

> Do you think it would be better to merge the packages or just add a
> dependency from haxe-mode to ob-haxe? Does it make a difference?

The difference is the ease with which the two parts can share code.


        Stefan