On Tuesday 11 July 2006 23:50, Mark V. wrote:
On 7/11/06, Stefan L. [email protected] wrote:
[…]end task :b => :a do ... endI haven’t done much with Rake yet, but fortunately I knew that =>
is used to indicate that one task depends on another. I wonder how
many people who didn’t know Rake would guess that.
You have to learn any syntax/API. Important is that it’s
easy to remember and that you don’t have to write unnecessary
code each time you define a task. In Python this would
probably be done like this:
def fun_a():
...
task("a", fun_a)
def fun_b():
...
task("b", "a", fun_b)
Having to define the separate functions fun_a and fun_b
is an unnecessary burden for the programmer. Having to
invent those function names gets tiresome. And I don’t
see how that would be any clearer than the Ruby version.
dirAndSize = do size <- many1 digit spaces dir_name <- anyChar `manyTill` newline return (Dir (read size) dir_name)And this? I don’t know Haskell, but I thought if it’s a good
language for creating DSLs then I’d at least have a good guess at
what the code does. Unfortunately I don’t have a guess here. I
think that’s a bad sign. Call me stupid if you’d like.
Perhaps it wasn’t so a good idea to drop these examples
in without any explanation 
The parseInput function parses lines like this:
65572 /home/adept/photos/raw-to-burn/dir1
This example is from
http://haskell.org/haskellwiki/Hitchhikers_Guide_to_the_Haskell
The important point here is again that if you know basic
Haskell, Parsec provides an easy way to define parsers.
There is no bookkeeping for the Haskell compiler.
Parsec was used for Pugs, the first Perl 6 compiler. So
it seems to work for harder tasks too.
Of course, Lisp is the language for DSL construction.
I’d like to see a DSL example in LISP.
Taken from “Practical Common Lisp”,
http://www.gigamonkeys.com/book/practical-building-a-unit-test-framework.html
Usage of a small unit test framework:
;; Define a test case for the "+" function
(deftest test-+ ()
(check
(= (+ 1 2) 3)
(= (+ 1 2 3) 6)
(= (+ -1 -3) -4)))
;; Another test case for "*"
(deftest test-* ()
(check
(= (* 2 2) 4)
(= (* 3 5) 15)))
;; Test suite for arithmetic functions
(deftest test-arithmetic ()
(combine-results
(test-+)
(test-*)))
;; run the test suite
(test-arithmetic)
pass ... (TEST-ARITHMETIC TEST-+): (= (+ 1 2) 3)
pass ... (TEST-ARITHMETIC TEST-+): (= (+ 1 2 3) 6)
pass ... (TEST-ARITHMETIC TEST-+): (= (+ -1 -3) -4)
pass ... (TEST-ARITHMETIC TEST-*): (= (* 2 2) 4)
pass ... (TEST-ARITHMETIC TEST-*): (= (* 3 5) 15)
T
That “T” in the last lines means that all tests have passsed.
“deftest”, “check” and “combine-results” are user defined macros.
The whole “framework” is defined in 26 lines of code.
For my needs, I would tweak it so that the test code is printed
only for tests that failed.
Currently I have to write a Java webapp at work. Writing Java and
loads of XML when you know Lisp and Ruby really hurts.
If Java would provide something like Lisp’s macros or some of
Ruby’s features (anonymous closures, defining own attr_* methods,
higher order functions, etc.), I’m sure we could reduce the code
size of the project to a quarter or less of the current size.
The same goes for the XML code. Those XML DSLs have a serious
problem. When a certain pattern occurs often in the project and
the framework hasn’t a builtin way to factor it out, you’re out
of luck. Type it out each time.
In an Rantfile/Rakefile I have the full power of Ruby at hand.
I simply Won’t Repeat Myself.
I know I’ll learn