New package: JiL v0.1.0

[JuliaRegistrator]

• Registering package: JiL
• Repository: https://github.com/aptmcl/JiL.jl
• Created by: @aptmcl
• Version: v0.1.0
• Commit: 7b1030b079d7f1b8976acb428921607b6e138f47
• Reviewed by: @aptmcl
• Reference: aptmcl/JiL.jl@7b1030b#commitcomment-149868785
• Description: The JiL programming language: a Lisp dialect on top of Julia.

[github-actions]

Hello, I am an automated registration bot. I help manage the registration process by checking your registration against a set of AutoMerge guidelines. If all these guidelines are met, this pull request will be merged automatically, completing your registration. It is strongly recommended to follow the guidelines, since otherwise the pull request needs to be manually reviewed and merged by a human.

1. New package registration

Please make sure that you have read the package naming guidelines.

2. AutoMerge Guidelines which are not met ❌

• Name is not at least 5 characters long

• Package name similar to 18 existing packages.

  Similar package names

  1. Similar to Jin. Damerau-Levenshtein distance 1 is at or below cutoff of 2. Damerau-Levenshtein distance 1 between lowercased names is at or below cutoff of 1. Normalized visual distance 1.88 is at or below cutoff of 2.50.
  2. Similar to ISL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  3. Similar to JLD. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  4. Similar to Bio. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  5. Similar to Air. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  6. Similar to GSL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  7. Similar to Git. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  8. Similar to VSL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  9. Similar to JDF. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  10. Similar to LSL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  11. Similar to Jive. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  12. Similar to HSL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  13. Similar to JOLI. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  14. Similar to JET. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  15. Similar to XML. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  16. Similar to MKL. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  17. Similar to QML. Damerau-Levenshtein distance 2 is at or below cutoff of 2.
  18. Similar to KML. Damerau-Levenshtein distance 2 is at or below cutoff of 2.

3. Needs action: here's what to do next

1. Please try to update your package to conform to these guidelines. The General registry's README has an FAQ that can help figure out how to do so.
2. After you have fixed the AutoMerge issues, simply retrigger Registrator, the same way you did in the initial registration. This will automatically update this pull request. You do not need to change the version number in your Project.toml file (unless the AutoMerge issue is that you skipped a version number).

If you need help fixing the AutoMerge issues, or want your pull request to be manually merged instead, please post a comment explaining what you need help with or why you would like this pull request to be manually merged. Then, send a message to the #pkg-registration channel in the public Julia Slack for better visibility.

4. To pause or stop registration

If you want to prevent this pull request from being auto-merged, simply leave a comment. If you want to post a comment without blocking auto-merging, you must include the text [noblock] in your comment.

Tip: You can edit blocking comments to add [noblock] in order to unblock auto-merging.

[goerz]

For this type of package, I think a name like JiL should be fundamentally okay. However, you'll have to convince a registry maintainer to merge it manually. Since names like JiL are somewhat scarce, it is probably much easier to do this if the project is already pretty mature, with full documentation, and there's some community discussion about it. Maybe it would be good to make some kind of "pre-announcement" on Discourse to introduce the package and explain your background and motivation for developing this

[aptmcl]

I'm not sure I understand what is being requested from me.

Are you saying that either I change the name of the package to something that has five characters or else I need to ask a registry maintainer to manually merge it?

I rather prefer the second option, so can you tell me the proper way to contact a registry maintainer?

[goerz]

Yes, that is correct. As the bot message indicates, you have to post on the #pgk-registration channel on Slack

[MasonProtter]

If I understand this package correctly, during initialization, it globally replaces the runtime-wide parser with a new parser that tries to figure out if a piece of code looks lispy, and if it is lispy, it parses using a lisp parser and if not, it'll use julia's parser.

I must say that even as a lisp enthusiast, this makes me pretty uncomfortable and I don't think this is something that a package in the general registry should be doing, as this behaviour can have profoundly far reaching implications.

I'd be much more comfortable if instead you had a lispinclude function that includes code parsed using your lisp parser, and then made a special repl mode (like what REPLMaker.jl does) that lets people use lisp syntax in the REPL if they opt into it.

As it is currently, simply using this package in a sub-dependancy can have highly non-local disruptive effects in completely different modules...

[aptmcl]

I understand your discomfort and, clearly, this package is an experiment on making Julia more like Racket, not only in the use of fully-parenthesized prefix syntax, but also in the support for program files written in different syntaxes, including the original Julia syntax. Those who will use it should expect the parser to change, hopefully, in a backwards-compatible way.

I don't know what is expected from me at this moment. Can you tell me which of the following is needed for the package to be registered?

1. Change the name of the package so that it complies with the automatic merge guidelines?
2. Change the implementation of the package, providing the lispinclude function that you mention, along with the special REPL mode?
3. Something else?

Thanks in advance.

[MasonProtter]

Those who will use it should expect the parser to change, hopefully, in a backwards-compatible way.

What I mean though is that since you're calling Core._setparser!(lang_parse), you're changing the parser used by all packages in the session non-locally, not just in the namespace or file where the user intends to use JiL (this would even affect Base if something got includeed after this package was loaded!) . That's what makes me a bit hesitant about this being in the general registry, because then it can be made a dependancy of a package and if someone loads some other random package, this could cause weird and hard to debug parsing errors even though the user might not have loaded JiL themselves.

I don't know what is expected from me at this moment. Can you tell me which of the following is needed for the package to be registered?

Sorry, I should have been more clear. I am also not a registry maintainer and I don't have the rights to approve or deny your package. I am just giving my feedback as to why I am a bit uncomfortable with the implementation itself so that you can consider that feedback, and so that whichever registry maintainer ends up looking at this knows about that extra context (i.e. that this is potentially not just a naming issue).

That said, we usually don't block packages from registration just because they're doing something that a rando like me thinks is a bad idea. I just thought I'd flag it just in case it is important.

---

Separately, I should also say this is a really cool package and I love to see people playing around with this stuff! It's very neat, (I'm just not totally sure it is a good fit for the general registry -- but I'm also not convinced it shouldnt be registed)

[github-actions]

This pull request has been inactive for 30 days and will be automatically closed 7 days from now. If this pull request should not be closed, please either (1) fix the AutoMerge issues and re-trigger Registrator, which will automatically update the pull request, or (2) post a comment explaining why you would like this pull request to be manually merged. [noblock]

[github-actions]

This pull request has been inactive for more than 30 days and has automatically been closed. Feel free to register your package or version again once you fix the AutoMerge issues. [noblock]