Using the Python Interpreter as a Reference

[Travis Parks]

On Nov 22, 1:37 pm, Alan Meyer <amey... at yahoo.com> wrote:
> On 11/20/2011 7:46 PM, Travis Parks wrote:
>
> > Hello:
>
> > I am currently working on designing a new programming language. ...
>
> I have great respect for people who take on projects like this.
>
> Your chances of popularizing the language are small.  There must be
> thousands of projects like this for every one that gets adopted by other
> people.  However your chances of learning a great deal are large,
> including many things that you'll be able to apply to programs and
> projects that, at first glance, wouldn't appear to benefit from this
> kind of experience.  If you get it working you'll have an impressive
> item to add to your resume.
>
> I suspect that you'll also have a lot of fun.
>
> Good luck with it.
>
>      Alan

I've been learning a lot and having tons of fun just designing the
language. First, I get think about all of the language features that I
find useful. Then I get to learn a little bit how they work
internally.

For instance, functions are first-class citizens in Unit, supporting
closures. To make that happen meant wrapping such functions inside of
types and silently elavating local variables to reference counted
pointers.

Or, I realized that in order to support default arguments, I would
have to silently wrap parameters in types that were either set or not
set. That way calls to the default command could simply be replaced by
an if statement. It was a really subtle implementation detail.

It is also fun thinking about what makes sense. For instance, Unit
will support calling methods with named arguments. Originally, I
thought about using the '=' operator:

Foo(name="bob" age=64)

but, then I realized that the equals sign could be confused with
assignment. Those types of syntactic conflicts occur quite often and
lead to a lot of rethinking. Ultimately, somewhat good ideas get
replaced with much better ideas. I had been contemplating Unit for
months before the final look and feel of the language came into view.
It isn't what I started out imagining, but I think it turned out
better than I had originally planned.


Recently, I rethought how functions looked, since the headers were too
long:

alias Predicate = function<T> (value: & readonly T) throws()
returns(Boolean)
let Any = public function<T>
    (values: & readonly IIterable<T>)
    (?predicate: Predicate<T>)
    throws() # ArgumentNullException inherits from UncheckedException
    returns(Boolean): # this can be on one line
    default predicate = (function value: true)
    assert predicate != null "The predicate cannot be null."
ArgumentNullException
    for value in values:
        if predicate(value):
            return true
    return false

Most of the time, throws clauses, returns clauses and parameter type
constraints can be left off. Plus, now they can all appear on one
line. Assertions and default statements now appear in the body.
Assertions now optionally take a message and the exception type to
throw.

So, yeah, this has been an awesome project so far. I have dozens of
documents and I have been keeping up on a blog. I've even started
implementing a simple recursive descent parser just to make sure the
syntax doesn't conflict. Now it will be a matter of formally defining
a grammer and implementing the backend of the compiler... which I've
never done before. I have been thinking about compiling into a
language like C++ or C instead of assembler for my first time through.