-> 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.
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:
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). :)
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.
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 ! :)
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
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
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.
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.
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'.
