Arc Forum | Anonymous macros

Arc Forum

	Anonymous macros
	2 points by shader 5745 days ago \| 7 comments
	Currently arc supports anonymous functions both through the "fn" form and the [] form. These allow us to quickly generate functions by functions, and also save typing when typing in short function objects. Do you think that there could be some use in having "anonymous macros"? A posible alternative to the brackets would be braces {}, and depending on how we like them they could auto backquote their contents.

2 points by conanite 5744 days ago | link

It would be interesting to see an example of how you would use this.

One difficulty is that the only macros used to expand a given expression are the macros that are already known at read-time for that expression. Are you thinking of a shortcut to macex, to expand expressions at runtime?

-----

2 points by shader 5744 days ago | link

> Are you thinking of a shortcut to macex, to expand expressions at runtime?

I guess so. I don't really know what I'm thinking, to be honest. I think that anon. macros would be useful in cases where you want a little bit of syntax modification, but not make a whole macro out of a function.

For instance, I have found it difficult to make a set of functions taking rest parms built on top of a base function that also takes rest parm. In order not to get the extra layer of cons around it, I end up having to make a macro for calling that base function, to splice the arguments into the list. Maybe I'm doing it wrong, and there's a better way, but it seems like it might be an application for a short anon. macro.

-----

3 points by cchooper 5743 days ago | link

Can't you just use apply?

-----

2 points by shader 5743 days ago | link

I think apply only works as long as there are no other arguments besides the rest arg. Otherwise you need to use macro with ,@. I think.

-----

2 points by absz 5743 days ago | link

That's not the case; apply doesn't care how many arguments the function takes. Take map (which takes a mandatory argument and a rest parameter) and map1 (which takes two mandatory arguments):

  arc> (help map)
  (from "arc.arc")
  [fn]  (map f . seqs)
   Applies the elements of the sequences to the given function.
      Returns a sequence containing the results of the function.
      See also [[each]] [[mapeach]] [[map1]] [[mappend]] [[andmap]]
      [[ormap]] [[reduce]] 
  arc> (map list '(1 2 3) '(4 5 6))
  ((1 4) (2 5) (3 6))
  arc> (apply map list '((1 2 3) (4 5 6)))
  ((1 4) (2 5) (3 6))
  arc> (apply map (list list '(1 2 3) '(4 5 6)))
  ((1 4) (2 5) (3 6))
  
  arc> (help map1)
  (from "arc.arc")
  [fn]  (map1 f xs)
   Return a sequence with function f applied to every element in sequence xs.
      See also [[map]] [[each]] [[mappend]] [[andmap]] [[ormap]] 
  arc> (map1 [* 2 _] '(1 2 3))
  (2 4 6)
  arc> (apply map1 (list [* 2 _] '(1 2 3)))
  (2 4 6)

As long as the last argument to apply is a list, you're golden.

-----

2 points by shader 5743 days ago | link

Interesting. I was wondering if that might be the case.

So I guess that we don't need an anon. macro for that ;)

I'm also wondering whether we would ever actually want an anonymous macro, since often they turn out to be so general purpose that you might want to make a utility out of it.

Does arc have symbol macros?

-----

4 points by absz 5742 days ago | link

I'm not really clear on what an anonymous macro would do. Transform code? If we're writing it in one place, we can just transform it right there. Can you give a usage example?

And no, Arc only has ordinary macros and ssyntax. Though actually---and this just occurred to me now---you can use ssyntax to create symbol macros. For instance, I have the following in a library file

  (= mac-seval $)
  
  (add-ssyntax-bottom
    @    (par apply R)
    $    (fn lists (apply map R lists))
    @    apply
    $    mac-seval)

The first two let me write (@func arg1 restargs) instead of (apply func arg1 restargs) and ($func xs) instead of (map xs). However, this $ makes the $ macro misbehave, and so I added ssyntax turning @ into apply and $ into the original $ macro. It turns out that this technique is fully generic, since ssyntax essentially does a find-and-replace on symbols:

  arc> (= defsym add-ssyntax-top)
  #3(tagged mac #<procedure>)
  arc> (defsym RANDOM (rand))
  t
  arc> RANDOM
  0.5548165450808223
  arc> RANDOM
  0.15745063842035198
  arc> (= things '(alpha beta gamma))
  (alpha beta gamma)
  arc> (defsym THING1 (car things))
  t
  arc> THING1
  alpha
  arc> (= THING1 'one)
  one
  arc> things
  (one beta gamma)
  arc> (defsym NOISY (do (prn 'HI) nil))
  t
  arc> NOISY
  HI
  nil
  arc> (car NOISY)
  HI
  nil

This is actually really nifty, even if it's an unintended side effect. On some level, though, I'm not fully convinced of the value of this---it seems a bit omnipresent. Then again, Common Lisp works fine with them, so perhaps they're fine for Arc too. Are there naming conventions for symbol macros in Common Lisp? I used capital letters above just because I wanted some distinguishing mark.

There are a couple of caveats: first, every time you run add-ssyntax-top, you'll add another entry to the ssyntax table instead of overwriting the old one, so redefinition will make ssyntax slower if it's done too much. Second, the five tokens R, r, L, l, and ... are all unavailable, even if quoted; they turn the given string into modifying ssyntax, not standalone ssyntax. Still, this is a new option I hadn't thought about yet.

-----