arclanguage / anarki

Community-managed fork of the Arc dialect of Lisp; for commit privileges submit a pull request.
http://arclanguage.github.io
Other
1.17k stars 160 forks source link

Miscellaneous fixes: omit testing demos & define the license #220

Open xgqt opened 1 year ago

rocketnia commented 1 year ago

I deeply appreciate the contributions, but I have some bad news and recommend closing this without merging:

The timeouts are probably a result of Anarki taking a long time to load, which has always been a result of Arc not having an on-disk precompiled representation the way Racket has .zo files. Since a #lang anarki module depends on Anarki, it has to read and macroexpand a whole bunch of Arc files, which apparently takes longer than 90 seconds on the package server.

A long-term approach to this might be to change #lang anarki so that it loads only whatever part of the Anarki runtime it needs. There could also be an effort to make Anarki more .zo-capable, but I think that would lead to a more thorough revamp of the language design (and one that's hard to reconcile with certain hallmarks of Arc's design like pervasive mutability and a lack of encapsulation).

With so few people actively working on Anarki, maybe we should just accept that people won't currently have a good experience developing libraries on top of it using the Racket package server's norms and techniques. (Instead, people can contribute their new libraries to the lib/ directory.)

I can try to see if I can update some documentation to communicate that state of things. At any rate, that's probably a topic for a different issue thread.

Again, thank you for contributing. :) Feel free to keep doing so whenever you'd like. I get the impression you're doing this for the license information tooling you've worked on, right? Are there some goals of yours that would conflict with leaving this package licenseless and failing?

xgqt commented 1 year ago

I get the impression you're doing this for the license information tooling you've worked on, right?

Yup, that is correct.

Are there some goals of yours that would conflict with leaving this package licenseless

Because of empty license metadata the license is assumed to be all-rghts-resereved.

Tbh you probably should also specify the used licenses in a document inside the repo.

I dont see problem with expanding the defined license set to, ie.: '(Artistic-2.0 AND (AGPL-3.0-or-later AND MIT))

[...] and failing?

Not really a huge problem, only packages that fail to build are excluded from being used by the tool I worked on.