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 :)
You could write a more complicated check within memo that examined whether the arguments had been passed before. This would probably slow down lookup though and not give much of a net gain.
The problem which prevents this from working nicely with nil is that hash tables in Arc do not distinguish between the value nil and a key simply not being there. The workaround is to use a default value (generally a symbol returned by (uniq)) to guarantee uniqueness for the case when the key does not exist.
Actually I know why it happens and how to fix that. The question was more like "is it a bug or a feature?" I remember that PG suggested (but forgot where I read that) to store cons' in a table when you need to distinguish nil and absence of an element but why doesn't he use that technique (or any other) himself?
I think the simple answer is that he hasn't needed that feature. 'memo and 'defmemo are used in 5 places in news.arc and it doesn't look like any of those uses would benefit from allowing nil as a value.
If someone created an application that benefited from that feature then perhaps there would be reason to redefine 'memo.
This seems to be an important part of the Arc philosophy: add a feature only when its absolutely needed.
Only now I realized that you treat memo as some kind of the way to improve performance (do you?). What I used memo for is to make sure that function won't be called twice:
When I use lazy sequences (of symbols read from input port for example) based on these definitions I can't be sure that readc somewhere inside will never be called twice if I call force for an element of this sequence twice.
So I treat this as a bug. Or maybe I'm just wrong about what memo is for at all. Am I?
Another twist is to use the 'on interator which binds its first argument to each successive element and implicitly binds 'index to the index of that element.
arc> (on c "arc" (prn index ":" c))
0:a
1:r
2:c
nil
(def ugh (str)
(let x 5
(on c str
(let v (trunc (/ 12 (+ index 1)))
(if (is c #\A)
(++ x v)
(-- x v))))
x))
I dropped Moshe a line to see what he has to say regarding Plop's dependency on Maxima.
I've looked through the first few files and so far have only encountered fairly straight-forward common lisp. Hopefully whatever Maxima features are used will be relatively easy to implement.
