On Thu, Mar 29, 2012 at 3:50 PM, Nathan Rice <nathan.alexander.r...@gmail.com> wrote: > Well, a lisp-like language. I would also argue that if you are using > macros to do anything, the thing you are trying to do should classify > as "not natural in lisp" :)
You would run into disagreement. Some people feel that the lisp philosophy is precisely that of extending the language to do anything you want, in the most natural way. At least, I disagree, but my lisp thoughts are the result of indoctrination of the Racket crowd. I don't know how well they represent the larger lisp community. But you should definitely take what I say from the viewpoint of the sort of person that believes that the whole purpose of lisps is to embed new syntax and new DSLs via macros. Without macros, there's no point of having this despicable syntax (barring maybe pedagogy and other minor issues). > I'm really thinking here more in terms of a general graph reactive > system here, matching patterns in an input graph and modifying the > graph in response. There are a lot of systems that can be modeled as > a graph that don't admit a nested list (tree) description. By having > references to outside the nesting structure you've just admitted that > you need a graph rather than a list, so why not be honest about it and > work in that context from the get-go. I don't see any issue in defining a library for working with graphs. If it's useful enough, it could be added to the standard library. There's nothing all that weird about it. Also, most representations of graphs are precisely via a tree-like non-recursive structure. For example, as a matrix, or adjacency list, etc. We think of them as deep structures, but implement them as flat, shallow structures. Specialized syntax (e.g. from macros) can definitely bridge the gap and let you manipulate them in the obvious way, while admitting the usual implementation. > I don't think they have to be. You can view functions as names for > temporally ordered sequence of declarative implication statements. > Databases just leave out the logic (this is hyperbole, I know), so you > have to do it in client code. I don't feel that a database > necessarily has to be a separate entity, that is just an artifact of > the localized, specialized view of computation. As stronger > abstractions are developed and concurrent, distributed computation is > rigorously systematized, I think we'll go full circle. Maybe I'm too tired, but this went straight over my head, sorry. Perhaps you could be a bit more explicit about what you mean by the implications/logic? -- Devin -- http://mail.python.org/mailman/listinfo/python-list
