I'm aware of unit testing, having read about it in a book: "Foundations of Agile Python Development" (Jeff Younker). I don't have much experience with it in any language though (I'm learning Python simultaneously with learning Factor). Unit testing seems complicated for recursive functions. It might work with list, that only uses tail-recursion, but I am very dubious that it could be done with the functions in symtab (especially optimize) that are truly recursive. I'll give it some thought and possibly take a stab at it.
That dlist class looks interesting. I don't see anything comparable to my link function though. I want something like a + for lists, that appends or prepends one list onto another. Also, my link function can be used for inserting one list into the middle of another list. This works because my lists are circular. It is not clear to me if the dlists are circular or if they have null pointers at the ends. I also like my remove because it returns the next node; it can be called repeatedly to delete a section of the list. I would prefer to use dlist rather than my own list if I can though. Factor is already quite complicated, so having two implementations of doubly-linked lists that are slightly different would just be unnecessary complication. My background is primarily Forth. When the ANSI committee developed ANS-Forth, they specifically made it a "thin" definition. The goal was to not include anything that the user could easily enough define himself, but to not be so limited as to prevent anything from being defined. The committee didn't even provide arrays, which are a pretty fundamental aspect of programming, and they definitely didn't provide linked lists. By comparison, Factor is a "fat" definition; you provide pretty much everything that could conceivably be needed. I would be a lot more comfortable with Factor if you had implemented a two-level definition, similar to ANS-Forth (http://www.taygeta.com/forth/dpans.htm#toc) --- that is, you have a basic definition of the language that is thin, but you also have a higher-level layer of optional extensions. This way I could focus on learning the basic definition first, which is small enough to not overwhelm my scant neural resources, and only later tackle the extensions. As it is, everything in Factor is at a single level. There is so much to learn that I feel like I'm getting a truck-load of bricks dumped on top of me. The downside of ANS-Forth is that it is a little bit too thin. It has some gaps in the definition that are impossible to fill without taking recourse in non-standard code, and doing so defeats the whole purpose of having a standard. ----- Original Message ----- From: <[email protected]> To: <[email protected]> > Message: 2 > Date: Wed, 27 May 2009 19:44:08 +0300 > From: Kobi Lurie <[email protected]> > Subject: Re: [Factor-talk] list > To: [email protected] > Message-ID: <[email protected]> > Content-Type: text/plain; charset=windows-1255 > > Hi Hugh, are you aware of unit testing? > it's very simple and short to write. > In other languages it's sometimes a pain, but here it's very short. > you should try it, instead of the test utils at the end :-) > > Kobi > > Slava Pestov wrote: >> Hugh, >> >> What you've implemented is like Factor's dlists, >> http://docs.factorcode.org/content/article-dlists.html. >> >> They are an implementation of the deque abstract data type, >> http://docs.factorcode.org/content/article-deques.html >> >> Slava ------------------------------------------------------------------------------ Register Now for Creativity and Technology (CaT), June 3rd, NYC. CaT is a gathering of tech-side developers & brand creativity professionals. Meet the minds behind Google Creative Lab, Visual Complexity, Processing, & iPhoneDevCamp as they present alongside digital heavyweights like Barbarian Group, R/GA, & Big Spaceship. http://p.sf.net/sfu/creativitycat-com _______________________________________________ Factor-talk mailing list [email protected] https://lists.sourceforge.net/lists/listinfo/factor-talk
