Arc Forumnew | comments | leaders | submit | nex3's commentslogin
2 points by nex3 6462 days ago | link | parent | on: On the naming of $

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.

-----

7 points by CatDancer 6462 days ago | link

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.

-----

1 point by nex3 6462 days ago | link

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.

-----

5 points by nex3 6462 days ago | link

Okay, I've gone ahead and done this. Stable no longer references $ at all.

-----

2 points by CatDancer 6462 days ago | link

Well, I take that back. I'm not sure yet what I do want to do, but applying patches over other people's patches isn't it.

-----

2 points by eds 6462 days ago | link

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.

-----

3 points by nex3 6462 days ago | link

I'm not sure why this would be any better than using $. I'd rather just add library functions and be done with it.

-----

0 points by CatDancer 6462 days ago | link

ok

-----

2 points by nex3 6462 days ago | link | parent | on: Macros: Arc internals part 2

This was cause by the REPL-variable stuff. It's been fixed now.

-----

1 point by babo 6462 days ago | link

Thanks!

-----

1 point by nex3 6462 days ago | link | parent | on: Anarki Stable

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.

-----

1 point by nex3 6462 days ago | link | parent | on: Anarki Stable

Yep, looks great.

-----

1 point by nex3 6462 days ago | link | parent | on: Anarki Stable

Fixed and fixed. Thanks :-).

-----

1 point by CatDancer 6462 days ago | link

  arc> (mkdir "foo")
  Error: "Function call on inappropriate object nil (\"foo\")"

-----

1 point by almkglor 6462 days ago | link

Fixed on master branch. Sorry nex-3, I don't develop on stable branch at all, and I'm pretty much just using git as a glorified CVS ^^

-----

1 point by nex3 6462 days ago | link

Would you be willing to try using stable? It's really not that hard, and it keeps the history so neat.

-----

1 point by almkglor 6462 days ago | link

Will try later, anyhow how to do changes on both stable and master?

-----

1 point by nex3 6462 days ago | link

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.

-----

1 point by nex3 6462 days ago | link | parent | on: Anarki Stable

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.

-----

3 points by jbert 6462 days ago | link

> 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.

-----

1 point by nex3 6462 days ago | link

Good points. I've merged stable and updated the instructions.

-----


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?

-----

2 points by almkglor 6462 days ago | link

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?

-----

1 point by sacado 6462 days ago | link

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.

-----

3 points by almkglor 6462 days ago | link

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.

-----

3 points by sacado 6462 days ago | link

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.

-----

1 point by eds 6462 days ago | link

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.

-----

2 points by eds 6462 days ago | link

Me? I'd be fine with that.

-----


"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.

-----

1 point by tokipin 6463 days ago | link

could it be related to the license he's using?

-----

4 points by nex3 6463 days ago | link

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...

-----

3 points by antiismist 6462 days ago | link

IAAL--Arc is under the Perl Artistic License, see http://www.opensource.org/licenses/artistic-license-2.0.php

PG can roll in changes per part 4.a

-----

4 points by nex3 6462 days ago | link

I don't think I've ever seen the term "IAAL" used before.

-----


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.

-----

2 points by sacado 6463 days ago | link

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)

-----

3 points by nex3 6463 days ago | link

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.

-----

2 points by sacado 6463 days ago | link

For example, arc-call was change a little, for performance reasons I guess :

  (define (ac-call fn args env)
   (let ((macfn (ac-macro? fn)))
    (cond (macfn
           (ac-mac-call macfn args env))
          ((and (pair? fn) (eqv? (car fn) 'fn))
           `(,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 0)
           `(ar-funcall0 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 1)
           `(ar-funcall1 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 2)
           `(ar-funcall2 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 3)
           `(ar-funcall3 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          ((= (length args) 4)
           `(ar-funcall4 ,(ac fn env) ,@(map (lambda (x) (ac x env)) args)))
          (#t
           `(ar-apply ,(ac fn env)
                      (list ,@(map (lambda (x) (ac x env)) args)))))))
Instead of the code currently in anarki, taken from arc1 :

  (define (ac-call fn args env)
  (let ((macfn (ac-macro? fn)))
    (if macfn
      (ac-mac-call macfn args env)
      (let ((afn (ac fn env))
            (aargs (map (lambda (x) (ac x env)) args))
            (nargs (length args)))
        (cond
          ((eqv? (xcar fn) 'fn)
           `(,afn ,@aargs))
          ((and (>= nargs 0) (<= nargs 4))
           `(,(string->symbol (string-append "ar-funcall" (number->string nargs)))
              ,afn ,@aargs))
          (#t
           `(ar-apply ,afn (list ,@aargs))))))))
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.

-----

5 points by nex3 6463 days ago | link

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.

-----

2 points by nex3 6463 days ago | link

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.

-----

1 point by nex3 6463 days ago | link | parent | on: Suggest PG: Settable Function objects

You could always define a macro to abstract out the nastiness...

-----

1 point by almkglor 6463 days ago | link

^^ 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"))

-----

More