>> Mm I don't think it's what the OP is asking (unless I misunderstood...).
>> I think he wants to compile some syntax TO Python.
>> But I don't really see why you would something like this (if not for fun).
>
> Maybe because you think that Python syntax could be improved upon --
> for instance, Python with pattern-matching would be freaking awesome
> -- but at the same time you want to leverage Python's extensive
> ecosystem of libraries. So instead of creating your own brand-new
> language with no third party libraries whatsoever, you create one that
> just compiles down to regular Python.
You can generalize the dictionary based dispatch used for "case"
statements to do this. The main downsides are:
1.) You have to define your functions ahead of time or use lambdas
2.) The syntax is not quite as nice as it could be (e.g.)
foo = DispatchDict({
Pattern1: f1,
Pattern2: f2,
etc...
})
Reminds me more of javascript than I would like.
>> Then how are you going to maintain the code? Maintain the compiled
>> code or the source?
>
> As with all compiled software, you maintain the input, not the output.
I think maintaining the output can be valuable. There are going to be
things that can be expressed in the more verbose expanded form that
will not be easily expressible in the terse pre-translated macro.
Unfortunately, most macro writers don't put much time into making sure
their macro produces concise code.
>> And proving that your translator is always correct
>
> That's what unit tests are for.
I have a love hate affair with unit tests. You need them, but I'd
really rather analytically prove that my software is correct under
some set of assumptions.
Cheers,
Nathan
--
http://mail.python.org/mailman/listinfo/python-list
