Writing a DSL with Python(blog.fmeyer.org)
blog.fmeyer.org
Writing a DSL with Python
http://blog.fmeyer.org/entry/writing_a_domain_specific_language_dsl_with_python
21 comments
Note that there is a world of difference between an in-language DSL and one with its own syntax that must be parsed, so much difference that they really should have different names. The former can effortlessly exchange data with and enjoy all the features of the host language. I'm convinced that the latter will one day be an artifact of less enlightened times.
By convention the in-language form is called an internal DSL, the other an external ditto.
A very interesting DSL for network packet manipulation is Scapy(http://www.secdev.org/projects/scapy/).
It uses python itself as a DSL to make things like packet forging easy:
It uses python itself as a DSL to make things like packet forging easy:
>>> Ether()/IP()/TCP()/"GET / HTTP/1.0\r\n\r\n"
<Ether type=0x800 |IP frag=0 proto=TCP |<TCP |<Raw load='GET / HTTP/1.0\r\n\r\n' |>>>>
Wow. If you ever wanted curly braces or multi-line lambdas in Python this looks like the way to do it.
What exactly would people do with multi-line lambdas? I would definitely refactor any lambda with statements or more than one expression in it, give it a name, or use a list comprehension, so I've never seen a problem with them. Can anybody give me an example of a piece of code they think would look better if python had multi-line lambdas?
If you give something a name, yet still only use it once, what's the point? It is just semantic clutter to do that (unless, of course, you can't use multiline lambdas...).
There is no big harm in giving something a name. Giving a name also helps if you find a need to reuse it later. Plus a name can give a hint to what this code is for.
Yet, if you look in functional programming code (e.g. Haskell, Scheme), you'll find many anonymous lambdas (that in python would be > 1 line). Why would good coders bother doing that?
If something is small and enough to be anonymous, it's usually simply enough to be expressed without binding a variable.
(See point-free style.)
(See point-free style.)
In Python, you can easily define methods within methods, so there is little semantic clutter at the toplevel.
def doSomething():
def doSomethingElse():
# Code goes here.
pass
eggs = filter(doSomethingElse, spam)
for cheese in eggs:
# Do something.
passBecause functional languages discourage loops. This is just a really trivial example, but:
# value x =[|1;2;3;4|];
value x : array int = [|1; 2; 3; 4|]
# for i = 0 to (Array.length x) - 1 do {
Printf.printf "%d" x.(i);
};
1234- : unit = ()
# Array.iter (fun y -> Printf.printf "%d" y) x;
1234- : unit = ()
# Array.map (fun y -> Printf.printf "%d" y) x;
1234- : array unit = [|(); (); (); ()|]
Those are just two of the complaints I hear most. A friend of mine actually went so far as to patch Python to use curly braces at the start of a project in Python. "Perfect Python" he called it. Personally I think deviating from PEP8 & standard idioms is likely to cause more pain in maintainability than you win in elegant syntax.
Ugh, he means imperfect python, right? Even if I hated the indention sytnax, which I dont (and it seems to me that it grows on most people after a few weeks of use), I think a patched python is the wrong way to go about it as you now deviate from the main python distributions, so cant make use of updates and bugfixes (and do all libraries play nice with a patched version? maybe - maybe not). If you absolutely must have braces, use #{ and #} :-D, you should be indenting anyway!
I really don't get why some people hate the indention-as-syntax. Sure, its different to C and Java, but it also results in (more) consistently formatted code and readable indention. It also only takes a day or two to get used to, even if you're a hardened C++ user (for the record, I have nothing against C/C++ syntax, I actually switched from years of C++ to Python as my main language and I just recently started a C++/Python hybrid project).
I really don't get why some people hate the indention-as-syntax. Sure, its different to C and Java, but it also results in (more) consistently formatted code and readable indention. It also only takes a day or two to get used to, even if you're a hardened C++ user (for the record, I have nothing against C/C++ syntax, I actually switched from years of C++ to Python as my main language and I just recently started a C++/Python hybrid project).
from __future__ import braces
Some links:
1. O'Reilly mini-book on pyparsing (probably best single ref) http://oreilly.com/catalog/9780596514235/
2. Quick example of pyparsing http://eikke.com/pyparsing-introduction-bnf-to-code/
3. Main pyparsing page (i know it's not very aesthetically pleasing. The code is much better, I promise) http://pyparsing.wikispaces.com/
4. Links to more on pyparsing here http://pyparsing.wikispaces.com/Publications
Python Magazine is excellent, by the way. Definitely worth the purchase price as they include a zip file with code. (Mandatory disclaimer: I have no stake in it at all. Just found it very useful, that's all).