Re: Handling extensions of programming languages (Perl)

[Stefan Monnier <monnier@iro.umontreal.ca>]

>> E.g. for an extension which doesn't collide with any other known Perl
>> extension, you could imagine enabling it by default (and maybe even
>> forego offering a way to disable it).
> I would prefer this behavior (not being able to disable it) for things
> that come with new Perl versions, but not for extensions.

I wasn't recommending any particular choice.
Just mentioning what I would consider as acceptable.

>> And as for where to put the code, it could be in a completely separate
>> file, or directly in `perl-mode.el` (which `cperl-mode.el` could
>> require: it's a mere 50kB compared to `cperl-mode.el`s 300kB).
> I am leaning towards a completely separate file, but maybe not right
> now.  In both cases the adventurous users who're using cperl-mode
> directly from the repository will then need to pick two files instead of
> one.  If, one day, cperl-mode is made available via ELPA, this should
> not necessary require moving perl-mode to elpa as well.

I don't see any problem with a :core `cperl-mode` package which comes
bundled with its own version of `perl-mode.el` (nor would I find it
problematic to export `perl-mode.el` into its own :core GNU ELPA
package).

> That was my first thought as well.  But then, the declarators appear in
> places where other languages have their types.

[ I think you use a very restricted definition of "other languages" here.
  It's definitely not the case for most of the statically typed languages
  I've used, except for C.
  I'm thinking of OCaml, SML, Haskell, Agda, Coq, Modula-2, Pascal, Ada, ... ]


        Stefan