; i'll skip the code that loads the tables from files.... here's the results
; arc> (vals ktable)
; ((0 "FIRST") (1 "MIDDLE") (2 "LAST"))
; arc> (vals dtable)
; (("Jon" "Mid" "Dow") ("Jane" "Moodd" "Meow") ("Alex" "Morse" "Lstname"))
(def dkey (at-name)
(for i 0 (- (len ktable) 1)
(if (is ((ktable i) 1) at-name)
(prn i))))
; arc> (dkey "MIDDLE")
; 1
; nil
; ((dtable "Jane" ) 1) .... this works passing in '1' but if I substitue for the dkey function i get the error
; arc> ((dtable "Jane" ) 1)
; "Moodd"
(def at-val (dat-name at-name)
((dtable dat-name) (dkey at-name)))
; so (at-val "Jane" "MIDDLE") generated the error
I think your code looks much cleaner, but I guess I have a few more points/questions.
1. Using the assoc function I would still have pass in a number to find the value for a given attribute a user chooses, correct? Which means I still would have to write an iteration function to find the position of that value to return and then would run into the same problem.
2. I have an assumption that when working with large volumes of data one would want to use a table, and small volumes should use a list....Is this correct? (my example above is only for testing)...
I've have to check the code at home, at work now.....
Essentially I'm taking a spreadsheet file (csv) with an arbitrary number of columns of data, reading in the headers so they can be output to the html table as headers then reading in the remainder to create rows in the html table.
also also letting users to pick and choose which columns of data they want by selecting header names.
I've pretty much got it all working, I'm just surprised the language wouldn't provide for passing in results of an iteration function cleanly. To have to create an extra function simply to strip out the nil ends up making the code readability poor..... I'm sure I will look at the code in 2 months, scratch my head and ask why I needed a second function.... of course by then I'll probably have found a better way :)