GameMonkey Script

I've been using LINQ a bit recently and in doing so it reminded me of a scripting environment I was working on years ago in that everything could be queries in sets.

I've noticed that Python has some data query behaviours and have been recently been considering adding something to GameMonkey Script.

Given a table of data items (be it a table of tables, or a table of your own entity types), you want to iterate over them to find all items that match a specific criteria.

In this example, it's a list of RPG entities which have a name, some hitpoints and a class identifier.



Now imagine you wanted to retrieve all items into a new table that had say less than 25 hit points... in normal GM you'd have to foreach over them and insert the items into a new table.

With some more query-like iteration syntax we could simplify this, maybe with something like this:



Which would populate a table with each matching entity.

Or imagine you just wanted to iterate over them, how about something like:



You could combine the selective part using normal conditions, so:



With this, you'd probably add "inrange", "exists" and other such keywords. The concept could probably be extended to allow "joins" across tables, but I'm not sure how that would look, maybe something like:



As a general principle, is this something that could be used in GM, or does it exist in the realm of functional/non-C like languages only?

ideally, i'd prefer an extension to the foreach if possible, rather than allocating and building new tables, support modifiers to the foreach queries.

foreach was my original choice actually, but I wondered if adding it to that operator would overcomplicate/confuse people. I like the ability to grab data into another table, but acknowledge that it might not be the best way to do it. How about adding in the "into" keyword so that the results are pushed into a table?

My thought is that if the result is a new table, you are only saving a small amount of syntax on wrapping a template or inline style function. eg.

My preference is toward DrEvil's suggested syntax, or one of your earlier ones without table populating. I don't know what limitations could or should exist.

I would support the additional stuff in a more readable syntax, like at the end of the statement. I kinda like the 'where' example I gave, as it is easier to read than remembering the x 'argument' of the foreach (seperated by is the condition, some other one is the table destination, etc.

IMO it flows off the tongue a bit better to read it like a sentence



it would seem odd to me that additional optional parameters would come in front of the normal stuff.