Friday, November 19, 2010

Language Ideas Part 3

This part of this series is about what is one of my favorite concept in the language: iterators. This is a bit different that iterators in C++ or Java. In this case, it's really just a special type of function that automatically iterates over an array or list.

Syntactically, it looks something like this:
iterator squareAll(int[]) -> int[]
given currVal:
currVal * currVal

It's not a finished concept. In this case, because the output is an array/list, then automatically takes the return value and adds it to the output array. Whether or not that's appropriate or not is debatable, however, it is clean. Also, it looks suspiciously like a map function. Here's a version that's like a reduce:
iterator summation(int[], init) -> int
given currVal, acc:
acc + currVal
Here, we have an accumulator that we add each value to. However, in both cases, there is a significant flaw: we only look at one value at a time. If we need to look at previous or future values, we're out of luck. So, a recent thought I had was this:

iterator summation(int[], init) -> int
given values, index, acc:
acc += values[i]
In this case, we now retrieve the value using the index, much like a C array. It's not the most pleasant solution, however it's still nicer than recursion. It's still not quite right as there it removes the convenience of not having to use an index to get a value. This is similar to the foreach and for loops that exist in several languages.

To go back in time a bit, the inspiration for this construct came from the D Programming Language. Specifically, the concept of ranges which have the ability to add/remove values from either end of a range as well as access values via an index. Ranges are really nothing more than some sort of data structure contained within a struct or class that has a specific API. In SPL I wanted the same thing mainly because I wanted to allow users of the language to create lists using the best data structure for their application. Each of these data structures could be accessed using an iterator without any additional work.

All of these ideas are good, however it's making them work together that's the hard part. I'm not really sure what the best solution is as I don't want to have two different constructs if one can do the job, but I also don't want to make things too complicated.

Perhaps it'll be figured out in the future.

Labels: ,

0 Comments:

Post a Comment

Links to this post:

Create a Link

<< Home