Arc Forumnew | comments | leaders | submitlogin
Problems with arc
3 points by ylando 5296 days ago | 20 comments
I like arc. It is a good attempt to fix Common lisp api. I think that most of Paul Graham ideas are good But it still need some improvement as a language.

   1) The = assignment function is unsafe,
      We should learn the lesson from javascript.
      We need a function like defvar
      for defining variables.
   2) Lack of namespace.
   3) It need reference or alias or symbol-macro-let


3 points by fallintothis 5296 days ago | link

1) I'm not sure what your exact objection is, but it's easy to fix (the CLHS even gives a macro definition for defvar: http://www.cs.cmu.edu/Groups/AI/html/hyperspec/HyperSpec/Bod...).

  (mac defvar (var val)
    `(unless (bound ',var)
       (= ,var ,val)))
This can be extended to several variables & values.

  (mac defvar vars/vals
    `(do ,@(map (fn ((var val))
                  `(unless (bound ',var)
                     (= ,var ,val)))
                (pair vars/vals))))
2) Agreed.

3) I don't know what you mean. Could you explain more?

-----

3 points by ylando 5296 days ago | link

   I will explain:
   1) I think we should separate the definition and the
   assignment some thing like:
   use strict; 
   my x; # declare var for the first time
   x=3;  # assign a value to a var
   in perl.
   3) Suppose we want to make an object oriented
   function; we can write a function
   (def myfunc (this arg1 arg2) ...)
   If we had alias we could write a macro that expand to
   (w/alias (var this.var var2 this.var2)
   (def myfunc (this arg1 arg2) ...))

-----

3 points by rocketnia 5296 days ago | link

1) I think you're missing the whole point of 'let.

  arc> (= x 5)
  5
  arc>
    (let x 3         ; "declare" a var with value 3
      (= x (* x x))
      (+ x 2))
  11
  arc> x
  5
If you want to separate the declaration from the initial value... why? What happens if you use the variable in between those two times?

2) For what it's worth, my Lathe library provides a certain sort of namespaces, and I've been using those pretty happily. (http://arclanguage.org/item?id=11610) But of course I'd be happy with them, 'cause I'm their author. :-p

3) Why would you need a macro to expand to...

  (w/alias (var this.var var2 this.var2)
    (def myfunc (this arg1 arg2)
      ...))
...when it could already expand to something like this?

  (def myfunc (this arg1 arg2)
    (with (var this!var var2 this!var2)
      ...))
That said, I think 'symbol-macro-let would be nifty. I wonder if it could be even more useful to have some way to build a lambda whose free variables were treated in a custom way (as opposed to just being globals). Either one of these could be a basis for scoped importing of namespaces.

-----

4 points by zck 5296 days ago | link

So w/alias is like let, but any changes are shadowed back to where the alias came from?

So

  (let var (cons 1 2)
    (w/alias head car.var
      (= head 2))
    var)
would output

  (2 . 2)
This seems related to macros and backquoting, although I can't quite explain it.

-----

4 points by projectileboy 5295 days ago | link

The lack of namespaces bugged me initially, but now I'm not so sure. I'm not convinced having namespaces doesn't encourage bloat. Perhaps some high-level mechanism at the library level would be useful, however. What would a good namespace mechanism look like?

-----

1 point by fallintothis 5294 days ago | link

I'm not convinced having namespaces doesn't encourage bloat.

Even if they did, what's the alternative? Implementation details leak all over the place in a single namespace. And if your project is large enough, you're going to wind up with many little functions & macros (lest you have one giant main function). Even arc.arc winds up exposing things like parse-format, insert-sorted, and reinsert-sorted.

I don't care if it's implemented library-level: I just need a way to keep innards internal. Thus far, I've been using ad hoc methods like

  (mac provide (public . body)
    (let (locals new-body) nil
      (each expr body
        (case (acons&car expr)
          def (let (name . rest) (cdr expr)
                (unless (mem name public)
                  (push name locals)
                  (= expr `(assign ,name (fn ,@rest)))))
          =   (each (var val) (pair (cdr expr))
                (if (~mem var public)
                    (push var locals))))
        (push expr new-body))
      `(let ,locals nil
         ,@(rev new-body))))
But this breaks on macros -- both their local binding (cf. http://arclanguage.org/item?id=11685) and (since it's ad hoc) those that might expand into assignment forms, like defmemo or defs or def inside of a let.

-----

3 points by rocketnia 5293 days ago | link

At the risk of sounding like a broken record, I think Lathe's namespaces already embody lots of the ideas people are talking about here. :-p

In this case, Lathe provides two forms in its more-module-stuff.arc module, 'packing and 'pack-hiding, which work like 'packed but only put certain parts of the "my" namespace into the package object. That way, the internals don't get imported.

The 'packing and 'pack-hiding forms are in a separate module only because they aren't fundamental to Lathe, but in fact, I've never actually wanted to use them. Just having separate namespaces is enough for me, 'cause when I want to have unobtrusive definitions, I can just create a throwaway namespace to put them in.

-

@evanrmurphy http://arclanguage.org/item?id=11975

For what it's worth, Lathe's namespaces are used like this, generally:

  (--specify-what-creates-the-namespace--
    --specify-functions-etc-using-the-namespace--)
The main point of this in Lathe is so that the form can clean up after itself using an 'after form. The return value capability is also nice.

An alternate namespace implementation might take this format so that it could search-and-replace names in its body at macro-expansion time. That was my original plan for Lathe's namespaces, but I soon realized a simplistic code walker wouldn't do, and I didn't really want to write a sophisticated code walker unless I had a whole new language in mind. Also, I doubt this approach would translate very well to the REPL.

-----

3 points by akkartik 5293 days ago | link

(paraphrasing)

"I'm not convinced having namespaces doesn't encourage bloat."

"Even if they did, what's the alternative? If your project is large enough.."

I think the point is that if you don't have namespaces you'll be more careful to keep projects concise. It's not always a good response, but the skunkworks ethos pretty much permeates all of arc.

-----

3 points by fallintothis 5292 days ago | link

Paraphrasing: if you don't have chocolate, you'll be more careful to keep cakes not-chocolatey.

Having one namespace isn't about concision any more than large == bloated (largeness is necessary but insufficient for bloat). Some code (short or long) lends itself to one namespace, some doesn't. And bashing the latter into one namespace doesn't make it concise.

Take arc.arc. It has a lot of code, but fits in one namespace because it rarely defines a function for another's sake. Functions/macros are usually either mutually exclusive library utilities, or were supposed to be exposed anyways (e.g., loop is used to define for, but it's okay, because we wanted loop anyways). Even so, there are cases like =, whose logic is spread across expand=, expand=list, setforms, metafn, and expand-metafn-call.

This versus http://arclanguage.org/item?id=11179, which provides (essentially) just sscontract, but is still large enough to naturally spread across functions that shouldn't be exposed (much like =). What would a "concise" sscontract be? One giant if statement with copy/pasted afns? At least with that method, all of the "bloat" like

  (def priority (c)
    (or (pos [find c _] '("&" ".!" ":~"))
        0))
wouldn't leak and (very possibly, considering the general name) clobber someone else's priority.

-----

1 point by projectileboy 5288 days ago | link

Hmm... I'm with you. But wouldn't it best to let people define their own namespace facilities based on what they need?

-----

1 point by fallintothis 5286 days ago | link

I'm not sure what you mean. Are you suggesting that people write a namespace system each time they need one? Or that there should be some composable facilities that let people pick & choose the features they need? The latter kind of sounds like "y'know, namespaces, but done right", so I can hardly disagree with it. :P

-----

3 points by shader 5286 days ago | link

Yeah, I frequently see people hacking together their own namespace systems, and either trying to go for the most complete and cumbersome system possible (handling dependencies, versions, etc.) or something that isn't general enough to be used more than once.

Maybe we should try and design a set of very basic namespace handling tools, and then allow users to extend off of them. Basic as in "See namespace. See namespace hold names. See namespace export names for use" If we make them simple enough, and generic enough, it should be possible to add whatever other features are necessary later.

Right now the only hard part about implementing namespaces seems to me to be support for macros. Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros? Or maybe just a good way to handle first class macros themselves?

-----

1 point by rocketnia 5281 days ago | link

Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros?

Lathe's approach (where namespaces are friendly-name-to-unfriendly-global-name tables encapsulated by macros):

  arc> (use-rels-as ut (+ lathe-dir* "utils.arc"))
  #(tagged mac #<procedure: nspace-indirect>)
  arc> (macex1 '(ut (xloop a list.7 b 0 a.b)))
  (gs2012-xloop a list.7 b 0 a.b)
  arc> (macex '(ut (xloop a list.7 b 0 a.b)))
  ((rfn next (a b) a.b) list.7 0)
  arc> (ut:xloop a list.7 b 0 a.b)
  7
Maybe we should try and design a set of very basic namespace handling tools, and then allow users to extend off of them.

Funny, that's part of what I had in mind as I made Lathe's module system. :-p Is there some aspect of Lathe's namespace handling that's inconsistent with what you have in mind? The point of the Lathe module system is mainly to keep the rest of the Lathe utilities safe from name conflicts, so I'll gladly swap it out if we can come up with a better approach.

(In case you haven't heard me rant about Lathe before, you can get to my original blog post about the module system via http://arclanguage.org/item?id=11610 and see all the current Lathe code at http://github.com/rocketnia/lathe. )

-----

1 point by ylando 5280 days ago | link

Anyone have any ideas on how to allow macro indirection via namespaces without having first class macros?

You can do something similar to my class macros, see:

  http://arclanguage.org/item?id=12003
You only need to declare namespace instead of class and it will work.

-----

1 point by projectileboy 5281 days ago | link

Well, I think people could write their own to suit their tastes. It seems to me you'd only really do this once. The exception would be a big fat project which wanted to use its own namespace mechanism; if you wanted to do something within such a project you'd probably bend to the will of how that project does things.

-----

1 point by akkartik 5292 days ago | link

I don't (and didn't) disagree with any of that.

-----

2 points by ylando 5295 days ago | link

It can look like this:

  In a library file mylib.arc
  (namespace mylib)
  (def func-a ...)
  ...
In a program:

   (use mylib (func-a func-b)) or (use mylib *) or (use mylib)
   Now we can write
   (func-a ...) (func-b ...)
   and for a function that we didn't import inside the
   namespace; we can write:
   (mylib/func-c ...)

-----

3 points by evanrmurphy 5294 days ago | link

It might be more elegant to take advantage of s-expressions for this, as in

  (module mylib
    (def func-a ...))
and

  (w/module mylib
    (func-a ...))
rather than having imperative declarations that apply to an entire file.

Thinking about module/namespace systems in general, I guess as long as definitions are still global by default then they shouldn't bother anyone who doesn't want them. You might also be interested in aw's piece on library dependencies: http://awwx.ws/thinking-about-dependencies

-----

2 points by shader 5285 days ago | link

What about = is unsafe? Are you saying that you might accidentally assign to a misspelled variable?

-----

1 point by ylando 5285 days ago | link

Are you saying that you might accidentally assign to a misspelled variable?

Yes this is exactly the problem. This the reason perl has: use strict.

-----