I like $. I think the shortness is important, because it is used a lot - arc simply doesn't have the functionality to do a lot of the scheme stuff we need. And it looks like and S, so it's mnemonic.
Plus I think in the long run, it will phase out of use. We'll settle on a good core set of features for Scheme to provide, provide those in-Scheme, and leave it at that. Maybe then we can rename it. But for now, while we're still exploring that area, it's important to make it easy.
My more serious objection is the inclusion of $ in the "stable" branch. Whatever makes it easy for you to do experiments in the wiki is fine with me. However the stable branch is advertised as being arcn + bug fixes, and I don't think taking over a punctuation symbol in support of fixing a couple of bugs such as "date" and "mkdir" qualifies.
Yeah, I wasn't really sure about this. It seemed to be the path of least resistance, but if you want to write make-directory, which-os, and so forth (or their more primitive components) in Scheme and get rid of $, go for it.
There is still seval, right? You could use seval rather than $ in the stable branch, since it won't have to be updated except for arcn releases and bug fixes, so maintenance won't be too much of a problem. And it doesn't require writing entirely new library functions to implement.
The BUGS file in master? I know it's in master and all, but since master's sort of the main branch, it makes sense for it to have information that pertains to the whole repo. Plus we don't want to clutter up stable with extra files.
It's probably not worth worrying about for this patch, because mkdir is in a different place in stable... I'll worry about that. But for future reference, the original post has a good procedure.
Really, I don't forsee much of a synchronization problem. People can commit to whichever branch they prefer; I'll keep an eye on the RSS feed, as might others, and if a bugfix gets pushed in one branch but not cherry-picked, we'll do it. There aren't too many commits that human error is going to matter all that much.
As for merging, there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.
I'm still not all that familiar with Git, though, and I would love to have nice history. I'm all ears for suggestions.
> there are already some commits in stable that aren't in master, because their functionality was based on Anarki-only features in master. Merging would try to merge those as well, which may have unintended consequences. It might also double up a bunch of the commits in master, which would be unfortunate.
That would be a one-time headache with the first merge. After that, as long as bugfixes go into the stable branch, you won't have that problem. (Just had a quick look, it seems like it's currently a fairly trivial merge with only a few minor conflicts - I think git is doing the right thing for you here, but I don't know arc well enough to be sure).
> I would love to have nice history. I'm all ears for suggestions.
Basically, imho, splitting a tree is work and merging shouldn't be.
So by putting the commits in the right place to start with, you're avoiding work (and errors, and people checking with other people to see if that is supposed to be like that, etc).
You're essentially preserving more information as to the purpose of the fix (this is a bugfix) in a way that the tools can get hold of.
Anyway - I'm not a git expert, but that's the way I'd do it.
That would be because I defined ref, and only thought to put it in ac.scm. We should come up with a way of dealing with this. I suppose we could admonish everyone to make changes to both files, but that seems a little annoying and apt to fall victim to forgetfulness.
Would you be willing to take on the responsibility of running "git log ac.scm" periodically and copying stuff over?
Wouldn't it be possible for arc-exe to just (load "ac.scm") somewhere? Admittedly I don't know enough about the mzscheme compilation process to figure out why it won't work that way - something to do with modules not being able to use (load ...), maybe?
No, it's not possible. There are problems with mzscheme's namespaces. I had to fight with them to make arc-exe work, and simply importing ac.scm in an englobing file will just not work.
Hmm. How about a macro which reads in the code from ac.scm and inserts it into a progn form? Would that work?
(defsyntax insert-file-here ()) ; dunno, never figured out scheme macros
(module arc-exe mzscheme
(insert-file-here "ac.scm")
)
Where (insert-file-here "ac.scm") would expand to:
(progn
(provide (all-defined))
...
(define (ac s env)
...)
)
Would putting the defines in (progn ...) work? Sorry, I'm not very good at macros in scheme, never managed to grok hygiene.
The alternative is to have the macros generate the (module ...) code, and insert the code inside the modules of ac.scm and as.scm and what else arc needs.
Basically what I'm proposing is writing a macro which does what you originally did in creating arc-exe.scm. The unfortunate part is that I never managed to grok Scheme macros, otherwise I'd offer to do it for you if you describe how you built arc-exe.scm.
Looks like an excellent proposition. I'm not very good with scheme macros either, however I think mzscheme has an à la Common Lisp define-macro extension. I'll look about that more precisely.
Is it really namespaces that are a problem, or modules?
I hacked together a short version of arc-exe.scm that worked just fine importing from ac.scm. The only problem with that version was that it wasn't a module, and thus couldn't be compiled by mzc. I couldn't make it a module because scheme complained when brackets.scm tried to override read and read-syntax. (Apparently overriding imported bindings only works outside modules.) And when I tried to modify or not include brackets.scm, it would complain that it couldn't find the module ac.
So did you encounter this particular problem or something else? My guess is that if I could make brackets.scm behave, I could make the rest of it fall in line. But maybe I am mistaken about this.
"as far as I know none of the propositions made in Anarki can be found in the official versions"
There are a few bug fixes that appeared first in Anarki, were brought up on the forums, and ended up being added to arc1 or arc2. But you're right, I don't believe PG pulls changes from the repo directly.
I'm no lawyer and I haven't read the artistic license very closely, but Anarki's under the same license as the original codebase, so I'm pretty sure there shouldn't be a problem...
I don't really see Anarki as a fork of Arc, and certainly not as a competing implementation. I see it as a place to put bug-fixing patches, to experiment with crazy implementation ideas, to keep libraries and add-ons, and so forth. I keep it up-to-date with the latest arcn.tar, and we all try not to make the API incompatible. If PG ever says that there's some feature in it that he won't include in the official distribution, at least one that involves patching ac.scm, we'll get rid of it. The rest can be included as arcn-compatible libraries.
So I don't predict that there'll really be incompatibility issues in the future.
Well, as far as I know, there are some improvements (bug fixes & efficiency issues) made in ac.scm from arc2 that have been ignored on the anarki version (where other patches & fixes were previously applied). In other words, anarki's current version of ac.scm is much closer to anarki's "arc1+" version than to arc2's version. I tried to merged them a few days ago, but apparently it broke in some versions of mzscheme. I might try again later.
No big deal however, these are only minor issues, but it might get harder as pg improves his own version while we get addicted to (and improve) the cool features implemented in the version we're working on. One day or another, it will be almost impossible to merge them. (Animal species work that way btw)
There shouldn't be anything in arc2 that isn't in Anarki except maybe a couple srv.arc improvements that are more or less a subset of the improvements made earlier in Anarki.
I did a full merge of arc2 when it was released (see http://www.arclanguage.org/item?id=3427), and when there were conflicts, generally favored PG's solutions to the ones already present. If there is anything missing, I'd love to know what it is.
That one is not crucial, as it only brings a minor performance gain in most of the cases. However, I'm more skeptical about that :
(define (ac-fn args body env)
(if (ac-complex-args? args)
(ac-complex-fn args body env)
`(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
'nil
,@(ac-body body (append (ac-arglist args) env)))))
Versus the code from Anarki, still the original arc1's version :
(define (ac-fn args body env)
(if (ac-complex-args? args)
(ac-complex-fn args body env)
`(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
,@(ac-body* body (append (ac-arglist args) env)))))
Isn't it a bug fix ? The one someone told about, with '(), () and nil not being always equivalent ? If so, that's more problematic. I tried to merge these codes together, but it was obviously broken and was reverted later in the git.
Those do seem to be mistakes. It looks like this might have been caused by the Windows-newlining of ac.scm, which screwed with the Git history a little. I'll change these to the arc2 versions... if you see any other inconsistencies, let me know.
I've changed ac-call to the arc2 version, but I think you're wrong about ac-fn. The following:
(define (ac-fn args body env)
(if (ac-complex-args? args)
(ac-complex-fn args body env)
`(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
'nil
,@(ac-body body (append (ac-arglist args) env)))))
is how it's been in arc0, arc1, and arc2. The following:
(define (ac-fn args body env)
(if (ac-complex-args? args)
(ac-complex-fn args body env)
`(lambda ,(let ((a (ac-denil args))) (if (eqv? a 'nil) '() a))
,@(ac-body* body (append (ac-arglist args) env)))))
is unique to Anarki, and was added as part of a patch for MzScheme compatibility.
After getting rid of all the trailing-whitespace-removal that was clogging the diffs, I think ac-call was the only non-purposeful difference between ac.scm in Anarki and arc2. Let me know if you notice any more, though.
^^ Again, somebody has to write the nastiness ^^. The main difficulty really is the fact that you have a polymorphic function that dispatches based on number of parameters as well as their contents.
Although I suppose you could actually use --warning-blatant-self-proclamation-- my p-m: macro:
(p-m:def matrix
(,(s (is s settersym)))
writerfunction
(i j)
(readerfunction i j)
x (err "argument error"))