Arc Forum | Functions defined by defmemo & defcache aren't put into sig

Arc Forum

Functions defined by defmemo & defcache aren't put into sig

1 point by fallintothis 5659 days ago | 3 comments

  $ cd arc3
  $ rlwrap mzscheme -m -f as.scm
  Use (quit) to quit, (tl) to return here after an interrupt.
  arc> (sig 'hexrep)
  nil

Is this deliberate or an oversight? There are other forms that aren't in sig, so I'm not sure if it's just supposed to be things defined by def/mac.

1 point by shader 5642 days ago | link

As long as they use the same symbol table, putting them into the same sig, src, and fns tables makes logical sense.

Realistically, src should be defined for '= (presuming you could discriminate for global symbols), and all of them redefined for every assignment macro that uses the global symbol table.

Unfortunately, it can't work for all def* forms, because some of them save their functions to different tables. For example, defop saves its functions to the srvops* table, so adding those functions to the 'sig table could result in name collisions.

Is it possible to make temporary changes to variables/hash tables? Suppose I wanted '= to save the assignment code "(= place value)" to a table using place as the key, but I only want that change to be valid for the current scope. For example

  arc> (= a 42)
  42
  arc> src.a
  (= a 42)
  arc>(let b 16
        (= a b)
        src.a)
  (= a b)
  arc> src.a
  (= a 42)

Is that possible? The idea would be to do the same thing for def and mac so that you can know the current definition of any symbol.

-----

1 point by CatDancer 5642 days ago | link

You could extend the compiler to save/restore information when a scope is introduced.

In your example though, at the end, 'a is set to 16, but you're reporting that its source is "(= a 42)". Is that what you want?

-----

1 point by shader 5642 days ago | link

whoops, good point. I was intending to make a a new local variable and redefine it using '= to a new value. In that case, the value of a would obviously be local, so redefining its source in the global table would obviously not make sense.

The problem with save/restore is that it isn't thread safe. Hmmm.

-----