A place to kick around dreamy language ideas. ---- Lisp is based on nested lists. What similar things can done with say maps or tables as base structures? Assume we can put code in those structures. Is it doable without creating tons of syntax clutter? ''Isn't that JavaScript or SelfLanguage? Objects are just maps; methods are functions mapped to names.'' Indeed, and LuaLanguage has the same design. It's versatile, particularly for prototyping. -- ScottVokes Also, a data-centric way to do recursion may be to run an operation that labels a data structure (assume a table here) with the order of recursion, and then a second process traverses in that order. Example: t1 = recurse(myTable, parentColumn="parentID", newColumn="recurseOrder") loop(t1, order="recurseOrder") {....} // loop thru table This is sort of a two-pass approach. I agree it may not be as efficient as a one-pass approach, but it breaks the problem into two separate parts: traversing and processing. One does not have to actually implement recursion in an app language here. This may simplify error handling and other issues because if things go wrong we don't have to worry about cleaning up both the recursive process and the processing steps themselves. It is almost a form of SeparateIoFromCalculation. -- top ''how would you write the "recurse" function in this way?'' ---- I've been playing around with an ArtificialIntelligence idea. It occurs to me that when I am thinking about a problem, I have access to all knowledge that I know (kind of like global variables). In many cases, the same symbol has multiple meanings based on different contexts (kind of like property lists). I am also able to instantly recall any temporary values that I am working with (dynamic scope). So far, this sounds a lot like classic Lisp. It occurs to me that I also often do a little bit of backtracking. When you "shoo fly", I filter the possible values of the sound "shoo" and ignore footwear, picking the "go away" meaning. * [Not to nitpick, but your introspection doesn't actually characterize human cognition and memory, which cannot access "all knowledge you know" and cannot "instantly recall temporaries", nor does contextual disambiguation nor filtering work in the optimal automagic way implied. Just FYI. Which says nothing at all about whether a '''software'''' system based on those ideas would be interesting, of course - such things inevitably '''are''' interesting.] ** That's not called "nitpicking", that's called denying another's truth. I don't think you can declare what another's cognitive functions are. Apart from its data collection, PsychologyIsNotAScience. I was pondering the possibility of building a reasoning system that was based on dynamic scope and property lists, ala old Lisp, but where every variable lookup is done using a context (dynamically scoped variable) to create preferences among the possible values. The thing is, the variable lookups would behave like the amb function (see StructureAndInterpretationOfComputerPrograms), which returns a value when run, but if a failure is encountered later in the program, the state of the program is rolled back to the variable lookup and some other value (either from the plist or the dynamic scope) is returned. Preferences would be used to decide what order the possible values of a variable are returned in as failures occur. I'm trying to figure out if this model is just a fancy way of simulating PrologLanguage, or if I've actually got a more powerful idea here. So far I have been unable to establish a simple isomorphism to PrologLanguage, but that doesn't mean it isn't there. Obviously, if all I've got is an idea for a harder to reason about Prolog implementation, then there's no point in messing with it. So, here's the question I'm facing. Well, two questions, but they are closely related. *Is this model of computation in some way isomorphic to unification? *Is there anything that would be comparatively easy to implement in this Lisp variant that would be a royal pain to try and implement in LispLanguage or PrologLanguage? [To me, this sounds like a fairly precise reinvention of MicroPlanner, not of PrologLanguage per se, but (A) in a hand-wavy sense, all these topics (including unification) are pretty similar - they differ more when you get down to lower level details, and (B) note that Hewitt said that Prolog (of which he was unaware originally) was MicroPlanner done right. I think he exaggerates, but it's worth keeping in mind. Both Prolog and Planner found it necessary to support programmer-controlled cuts in backtracking.] [The devil is in the details.] ''I always thought he was at SCO :-)'' ---- ''String-based Lisp. No (perm) internal data structure, just strings.'' Wouldn't that be ToolCommandLanguage? ''Couldn't be. It has curly braces, square brackets, and parentheses. Maybe Lisp-like in some general ways.'' ---- See ExperimentalDevelopmentIdeas KeyLanguageFeature''''''s LanguagesVsEnvironments MaspBrainstorming SmeQl CategoryProgrammingLanguage, CategorySpeculative