I stopped at spliceable-list (in scan-past) which needed lib/spliceable-list.arc. I didn't want to go down the rabbit hole of loading it after I saw a redefinition of append.
The dependencies might not be incompatible but I didn't try.
But yes, it might make sense to avoid pulling in spliceable-list. As long as you can see what it's being used for, there are other ways to get the behavior it provides, though the easy alternatives will be slower.
But as you're finding out, it's work. You can't just pull in dependencies willy-nilly. Fundamentally, arc3.1 and anarki are both about sharing code as ideas, not code as functionality. We've repeatedly mentioned how neither makes promises of compatibility. You can't treat them as interchangeable lego blocks and expect them to just snap into place. No matter how similar they look, they're not close to each other. They're really more like separate universes that you're 'wormholing' matter and energy through. Start with the assumption that that will cause some annihilation unless you're willing to be careful and detail-oriented. How much time should it take? Maybe "dawn to midnight" is reasonable. There's no way to tell until you try to do it. You're in terra incognita with every single little task like this.
Anarki tries to make such wormholing easier by providing tests. Tests are a better "unit of transplanting" than functions or something else. Try to first understand what's involved in making a test pass, then copy the test over, then make it pass. Think of the file upload code in anarki as merely an exposition to help guide you when creating your own version.
But this is harder when transplanting to arc3.1 because it has no tests. Honestly I have no idea why you stick with it. Imagine I'm a villain in a superhero movie or a bollywood movie: "where is your savior now? How long will you be faithful to him?" :) Stay with one repo and you'll be out on a limb less. Pick a repo with tests, and you won't be locked in to it when you do need to go out on a limb and transplant code from somebody else.
I feel bad that you struggled for so long by yourself. If you'd ask for help sooner, and if you provide more information, I think your path could be much eased. For starters, it sounds like you've added to arc3.1 over the years. It makes it harder for me to be sure that any code I suggest won't harm you. I recently made a suggestion to tvvocold over email that caused problems because it turned out he'd made changes I wasn't aware of. I'd prefer not to have more of that on my conscience. Can you share the current state of your codebase?
The final thing that helps us help you: forget about compatibility. Programming gets harder the more constraints you add, so try to focus on concrete issues rather than imaginary abstractions. How do you know your existing changes to arc 3.1 are "compatible"? If someone not called pg magically included file upload atop arc3.1, how would you be sure it was "compatible"? In my opinion the reason that "sending anything to a server requires this whole complicated way of multipart encoding/decoding stuff" is the expectation that things just work when you transplant them from one setting to another. I'll make a moral judgement as kindly and respectfully as I can: To the extent that you care about compatibility, you're part of the problem. Uploads are complicated because somebody else decided they didn't want to know about the details and just wanted uploads to work. Add thousands of such people with slightly different scenarios and vague fears of breaking each other, and you end up with all this complexity.
This is your main point really. Compatibility is nowhere close in importance.
I stick with Arc because one of its premises is following an axiomatic approach to building up a language. I don't know enough about Anarki to know if it does the same thing. I could be poorly informed. An admittedly casual survey of the source didn't make me confident that it does. I thought Anarki had logic it didn't need. It was also suspicious how little I ended up needing to add to Arc 3.1, at least until the issue of uploads.
I also stick with Arc because HN is written in it while I don't know of applications written in Anarki. I don't know if even Anarki's primary contributor uses it for web apps (do you use Anarki?) If they don't, that's a dangerous sign of building out of love for building, not need. It can be a good way to explore ideas, but not as good of a way to pick a language to write a web application in.
I do see the savior argument though. Pg admits Arc is missing a lot and doesn't recommend people use it, and he's the one who wrote it.
> Pick a repo with tests, and you won't be locked in to it
What also prevents someone from being locked in is compatibility, not just tests. Having tests for an incompatible language doesn't help a user when switching the language. They have to rewrite their program, and what they have in their head is the source of their program, not the source of the language. It's harder to switch.
> How do you know your existing changes to arc 3.1 are "compatible"?
They added to Arc 3.1, but they did not remove from it or modify semantics.
> If someone not called pg magically included file upload atop arc3.1, how would you be sure it was "compatible"?
I wouldn't be sure, it would need testing. But I know without testing Anarki is not compatible with Arc 3.1.
If pg released Arc 3.2, I know I only need to modify my application to account for the diff between Arc 3.1 to Arc 3.2. That should be a smaller changeset than the changeset between Arc3.1 to Anarki.
> The final thing that helps us help you: forget about compatibility.
This isn't your main argument. Whether I used Arc 3.1 or Anarki, the compatibility issue would still be an issue. I agree that breaking compatibility helps, by the way. Me complaining about multipart data in HTTP is, you guessed it, a result of not breaking compatibility. If there was a new version of HTTP that was not compatible with the older ones but communicated with sexps, I'd switch.
But what you really want from me is to use Anarki.
What I really want from you is exactly nothing. I couldn't give a rat's ass what you choose. I'm pointing out that the chains you find yourself shackled in are of your own creation, in your own imagination.
I mean, I did say I'd help you with whatever your repo was, didn't I? What an ungracious insinuation!
> If pg released Arc 3.2, I know I only need to modify my application to account for the diff between Arc 3.1 to Arc 3.2. That should be a smaller changeset than the changeset between Arc3.1 to Anarki.
You're making some big assumptions about Paul Graham's lack of productivity in the last five years.
> They added to Arc 3.1, but they did not remove from it or modify semantics.
If you define a new function and arc 3.2 happens to define the same name, is that incompatible?
> I also stick with Arc because HN is written in it while I don't know of applications written in Anarki.
I don't understand. Anarki provides the HN codebase just like the arc codebase that constitutes 99% of its code.
> What also prevents someone from being locked in is compatibility, not just tests. Having tests for an incompatible language doesn't help a user when switching the language.
I have no idea what the words you use mean. Tests help you if you're willing to, you know, open a file and write code to make them pass.
This is an unproductive discussion. I'll leave you to keep searching for "compatible" additions to a language that never promised compatibility, where that very concept is utterly meaningless.
I'm sorry I insinuated you want something from me. You've done a lot to selflessly help Arc since it was released, probably more than its own authors and I appreciate that. I'm also sorry I upset you.
