Arc Forumnew | comments | leaders | submitlogin
Function overloading
1 point by adm 5471 days ago | 8 comments
Recently I was thinking What will it take to implement function overloading in Arc? Coincidently came across this: http://www.paulgraham.com/ilc03.html where pg mentions if wanted it can be implemented as lib(I assume by that he means outside of of language core). I tried to list down primitives required.

  ; user defined types
  (= udt* (table))
  ; all overloaded fuctions
  (= methods* (table))
 
  ; is user defined type?
  (def type? (name)
    ...)
 
  ; create a type recognizable type?
  ; and a function with same name as of typename for creating new instance
  (def mktype (name (o initfn))
    ...)
 
  ; overload a function
  (def odef (name params . body)
    ...)
 
  ; get function(name) associated with type(udt)
  (def get-odef (name udt)
    ...)
 
  ; invoke overloaded function if any else defualt to existing
  (def fn-dispatcher (fnname params)
    ...)
 
and of course type, annotate and rep(though haven't used it yet)

Is it possible to implement fn-dispatcher outside of ac.scm?

(I don't know how useful this would be but still.)



1 point by rntz 5471 days ago | link

Take a look at aw's 'extend macro: http://awwx.ws/extend

It takes a less efficient but more general approach than type-based dispatch; I find it more useful, at least in a language like arc. An older (incompatible, unfortunately; I may fix that at some point, but I'm unconvinced that labels weren't a good feature) and somewhat modified version of it is on anarki at lib/extend.arc (http://github.com/nex3/arc/blob/master/lib/extend.arc).

-----

1 point by aw 5471 days ago | link

Say, have you ever used labels? When I wrote my first version, I said, "ah, labels, good idea, I'll put them in". Then after using it for months I noticed that I wasn't ever using the label. So I took it out on my next iteration.

-----

2 points by rntz 5470 days ago | link

I have used them. Mostly I used them for debugging, rewriting, "code sketching" as it were. Without them, extending or reextending a function at the REPL is just annoying; if you ever make a mistake in the test function you have to reload the original function. I suppose it might make sense to have two macros - extend and extendl, maybe - one which doesn't take a label, and one which does.

-----

1 point by aw 5470 days ago | link

How about an undo, to undo the last extend you did?

Or a reextend macro, which undoes the last extend and then applies the new extend?

What I found annoying myself about the label was that I had to type it every time, even if it turned out that I didn't need to rewrite it.

-----

1 point by rntz 5470 days ago | link

Undo & reextend could easily be implemented on top of labeled extend - just store the label last used when extending a given function in a table, along with whatever information is needed to undo that extension, and have an unlabeled extension macro that uses a gensym as the label. That way we get labeled & unlabeled extend with undo & replacement.

-----

1 point by adm 5464 days ago | link

extend looks good. but I don't understand where one can use it, apart from extending a function for different types.

-----

1 point by aw 5464 days ago | link

In the Arc server, I moved creating the request object out of 'respond (http://awwx.ws/srv-misc), so that 'respond is now being passed the request object and does the usual Arc srv action to respond to a request: look to see if there is a defop etc. defined for the request path.

Now I can extend respond to implement my own ways of responding to requests: I can easily have my own way of choosing which action to take (I can have http://myserver.com/1234 display the "1234" item page, for example), or implement my own kinds of defop's.

-----

1 point by adm 5463 days ago | link

I see it now. So type based dispatch is just one of the cases where it can be used. Thanks for the explanation. but why rntz says it's less efficient?

-----