Arc Forum | Is there a way to create table pointers in arc ?

Arc Forum

Is there a way to create table pointers in arc ?

2 points by thaddeus 6005 days ago | 13 comments

Hi,

Just wondering if it's possible to make table pointers that may help make my code more readable ?

    arc> (= parent* (obj thing* (obj this "that")))
    #hash((thing* . #hash((this . "that"))))

so instead of doing this:

     (fill-table (parent* thing*) (list 'more "that"))

I'd like to do something like:

     (point mything* (parent* thing*))
     (fill-table mything* (list 'more "that"))

Note: The above example doesn't make it more readable, but a more complex function is using a few tables, each nested a few deep, really shows the problem.

Thanks, T.

1 point by CatDancer 6005 days ago | link

  arc> (= parent* (obj thing* (obj this "that")))
  #hash((thing* . #hash((this . "that"))))
  arc> (fill-table (parent* thing*) (list 'more "that"))
  Error: "reference to undefined identifier: _thing*"

What do you want thing* to be? A symbol? A table?

-----

1 point by thaddeus 6004 days ago | link

I imagine a table as I would like to perform all the normal table operations on it like:

    (keys mything*) 
     
     or (mything* 'this)
     etc etc...

I initially thought a function like (point mything* (parent* thing*)) would be ideal, but then realized it would also probably require the 'let' usage to work otherwise the scope would be a problem.

-----

1 point by CatDancer 6004 days ago | link

So table thing* is a key in the table parent*?

Could you either describe what you want to accomplish or else give some working code examples that you'd like to see simplified? I'm having trouble figuring out what you want your code to do from these fragments.

-----

1 point by thaddeus 6004 days ago | link

    -> So table thing* is a key in the table parent*?

    Yes.

Ok so this is probably exposing how newbish I really am, but please bear with me.... I tried to create an example that better describes what I am thinking.

Data set up:

    (= app* (table))
    (fill-table app* (list "yardwork" 
	                       (obj budget*   (table)
                                forecast* (table))))
    (fill-table app* (list "house" 
	                       (obj budget*  (table)
                                forecast* (table))))

    (fill-table ((app* "house") 'budget*) (list "roof" 1996.0))
    (fill-table ((app* "house") 'forecast*) (list "roof" 1996.0))
    (fill-table ((app* "house") 'budget*) (list "windows" 1000.00))
    (fill-table ((app* "house") 'forecast*) (list "windows" 1800.0))

so instead of doing this:

    (def area-situation (area sub-area)
         (let area-budget (((app* area) 'budget*) sub-area)
         (let area-forecast (((app* area) 'forecast*) sub-area)
         (let delta (- area-forecast area-budget)
         (if (is delta 0.0) 
               (let newval (list sub-area 200) 
                   (fill-table ((app* area) 'budget*) newval)))
         (prn (list "forecast " area-forecast " budget " (((app* area) 'budget*) sub-area))))))
    )

    arc> (area-situation "house" "roof")
    (forecast  1996.0  budget  1996.0)

I was thinking it would be nice to set up all my pointers at the beginning, then the last few lines of code ,where the meat is, become less cluttered with syntax and more about what, from a conceptual perspective, I am doing:

note: p = (point this (at that))

    (def area-situation (area sub-area)
         (p budget ((app* area) 'budget*)) 
         (p forecast ((app* area) 'forecast*))
         (p area-budget (budget sub-area))
         (p area-forecast (forecast sub-area))
         (= delta (- area-forecast area-budget))
         (if (is delta 0.0) 
              (let newval (list sub-area 200)
               (fill-table area-budget newval)))
         (prn (list "forecast " area-forecast " budget " area-budget))
    )

    arc> (area-situation "house" "roof")
    (forecast  1996.0  budget  200)

So you'll notice a few things; in function 1 - the last line requires having the full syntax for getting the roof budget; otherwise even though it's been re-set to 200; the let statement prior had already been set to 1996.0; so it forces me to re-use the syntax again; where ares the pointer notion in function 2 would not.....

Anyways - just the way my mind thinks (like a big spreadsheet haha). :)

-----

2 points by CatDancer 6004 days ago | link

When you have two expressions that are similar,

  (((app* area) 'budget*) sub-area)

  (((app* area) 'forecast*) sub-area)

write a function consisting of the parts that are the same, and make the parts that are different into variables:

  (def (price area type subarea)
    (((app* area) type) subarea))

  (def area-situation (area sub-area)
    (let area-budget (price area 'budget* sub-area)
      (let area-forecast (price area 'forecast* sub-area)
         (let delta (- area-forecast area-budget)

I would continue iteratively with this process of turning similar expressions into functions, but it looks like you may have a bug in your code? You store a new budget but print out the old one. Unless that's what you wanted?

There are a couple of advantages to this process of noticing expressions in your code that are similar and turning them into functions. First, you don't have to figure everything out in advance. You write some code and get it to work right. Then you look for similar expressions and turn them into functions. In practice this works a lot better than trying to figure out what functions you're going to need ahead of time.

The second advantage is that it makes your code easier to change. For example, suppose you wanted to change your representation of your prices from tables inside of tables into lists, or perhaps one table with a compound key. If you have lots of places where you say (((app* area) type) subarea)) then you'd need to change all of those, but if you have a few functions like price then you only need to change those.

-----

1 point by thaddeus 6003 days ago | link

ugh, sorry.

The code didn't have the bug the results I gave did (too much copying and pasting) :)

the first function actually returns 200. (forecast 1996.0 budget 200)

what I had intended to convey was that I had believed I was required to use the full syntax (((app* area) 'budget*) sub-area) in order to get the 200, which I did, but I wanted to just use 'area-budget' to make it more readable.

But as I learned there were so many things I was doing wrong it wasn't funny ... even though I am laughing now. bewahahahah ! :)

Thanks for the reply. T.

-----

1 point by CatDancer 6004 days ago | link

I'll take a look at this, but it may be a couple days before I have a chance to get to it.

-----

1 point by thaddeus 6004 days ago | link

no worries, it's not a real problem I have to solve. I'm just trying to figure out what options/techniques are available.

Thanks. T.

-----

3 points by conanite 6004 days ago | link

app* is a nested structure something like this:

  app*
    yardwork
      budget
      forecast
    house
      budget
        roof = 1996.0
        windows = 1000.0
      forecast
        roof = 1996.0
        windows = 1800.0

And you want a clean way to access, for example, (((app* 'house) 'budget) 'roof), given 'house and 'roof as parameters.

Am I right so far?

An alternative definition of area-situation might look like this:

  (def area-situation (area sub-area)
    (with (budget   ((app* area) 'budget)
           forecast ((app* area) 'forecast))
      (if (is (- (budget sub-area) (forecast sub-area)) 0)
        (= (budget sub-area) 200))
      (prn "forecast " (forecast sub-area) " budget " (budget sub-area))))

You can use 'with to create variables pointing just to the two tables you need and then there's less digging to do when you need to look up or alter values.

You might get better mileage by changing the data structure though if that's possible:

  app*
    yardwork ...
    house
      roof
        budget = 1996.0
        forecast = 1996.0
      windows
        budget = 1000.0
        forecast = 1800.0

Then, area-situation becomes even simpler:

  (def area-situation (area sub-area)
    (let situation ((app* area) sub-area)
      (if (is (- (situation 'budget) (situation 'forecast)) 0)
        (= (situation 'budget) 200))
      (prn "forecast " (situation 'forecast) " budget " (situation 'budget))))

Arc doesn't really have "pointers" (at least not in the c/c++ sense) - you either have global variables, or local (lexically-scoped) variables. So you can create a local variable pointing to the innermost table using 'let or 'with. Oh, I said "pointing" - well, they're kinda pointers.

Does that point you in the right direction, or did I miss the point entirely?

btw with the hot new special-syntax you can write app.area.sub-area instead of ((app area) sub-area) - see http://arclanguage.org/item?id=9220

-----

1 point by thaddeus 6004 days ago | link

wow!

i didn't have an appreciation for the 'hot new special-syntax' until I compared my original hack against your last function with the infixing....

    (def area-situation (area sub-area)
        (let situation app*.area.sub-area
          (if (is (- situation.budget situation.forecast) 0.0)
            (= situation.budget 200)
          (prn "forecast " situation.forecast " budget " situation.budget))))

This is awesome!

-----

1 point by thaddeus 6004 days ago | link

    *Am I right so far?*

yep.

I have to spend more time using 'with'; it's not a well well used tool in my tool shed as it should be.

and your last solution looks great to me.

thanks. T.

-----

2 points by fallintothis 6004 days ago | link

Accepting the hypothetical that there's not a clear-cut way to simplify the data structures (hey, it happens), I can't think of much to do. I know what it is you want to do, as the problem does crop up from time to time -- trying to make use of the expression instead of the value of an expression. An obvious way to solve this would be to introduce a macro, e.g.

  (= app* (table))
  
  (deftem cost-sheet  ;or whatever.  probably a bad name.
    budget   (table)
    forecast (table))
  
  (= (app* 'house) (inst 'cost-sheet 'budget   (obj roof 1996.0 windows 1000.0)
                                     'forecast (obj roof 1996.0 windows 1800.0)))
  
  (mac budget (area sub-area)
    `(((app* ,area) 'budget) ,sub-area))
  
  (def area-situation (area sub-area)
    (withs (area-budget   (((app* area) 'budget)   sub-area)
            area-forecast (((app* area) 'forecast) sub-area)
            delta         (- area-forecast area-budget))
      (when (is delta 0.0)
        (= (budget area sub-area) 200))
      (prn "forecast " area-forecast "budget " area-budget)))

But this isn't a very palatable solution -- you'd need to define macros for each field, and even then they're only shortcuts, really. It'd be easier if there were a shorter way to do nested indexing (which there will be, come arc3: http://arclanguage.org/item?id=9163).

Upon writing this and finding someone else replying, I notice that conanite's post http://arclanguage.org/item?id=9326 contains probably the best solutions, though.

-----

1 point by thaddeus 6004 days ago | link

I like the mac idea too. if the concepts like "budget" and "forecast" are the main data concepts of the program; then I can see being able to re-use the macro a lot. Also I have to read up on 'deftem' and 'inst'.

thanks, T.

-----