MultiMethod

เมื่อวันเสาร์ไป compkucamp มา เจออาจารย์โป้งเข้าก็เลยถามว่า ช่วงนี้ทำอะไรอยู่, อาจารย์โป้งก็ตอบว่ากำลัง implement multimethod บน c++ อยู่ ว่าแล้วก็ควักโน๊ตบุ๊คออกมาแสดง อาจารย์โป้งใช้ software ได้ผสมปนเปมาก เริ่มจากเปิด microsoft visual c++ ขึ้นมา จากนั้นก็ switch ไปใช้ terminal บน mac เพื่อใช้ django generate project files จากนั้นก็ show file content ให้ดูโดยใช้ textmate

หลังจากกลับมาบ้าน และส่งลูกเข้านอนหมดแล้ว เพื่อแก้ข้อสงสัยที่ฟังมา ก็เลยต้องเข้า wikipedia ไปหาอ่านเรื่อง Multimethod หรือ Multiple Dispatch บ้าง

ในการทำความเข้าใจกับเรื่องนี้ เราก็ควรจะเริ่มจาก basic สุดก่อนก็คือ Single Dispatch ซึ่งใช้ใน Java, C++, Smalltalk, Objective-C

ลองดู code นี้

public abstract class Animal {
        
        public abstract void feed(Food food);
        
}

public abstract class Food {

}

public class Fish extends Food {

}

public class Bone extends Food {

}

public class Dog extends Animal {

        @Override
        public void feed(Food food) {
                System.out.println("I 'm full. Hong Hong!!!");
        }

}

public class Cat extends Animal {

        @Override
        public void feed(Food food) {
                System.out.println("I 'm full. Meaw Meaw!!!");
        }

        public void feed(Bone food) {
                System.out.println("I don't like this. Meaw Meaw!!!");
        }

}

ถ้าลอง run แบบนี้ดู

public class Runme {

        public static void main(String[] args) {
                Animal a = new Dog();
                Animal b = new Cat();
                
                Bone bone = new Bone();
                a.feed(bone);
                b.feed(bone);

        }

}

กรณีที่เป็น single dispatch ผลลัพท์ที่ได้ก็คือ

I 'm full. Hong Hong!!!
I 'm full. Meaw Meaw!!!

จะเห็นว่า single dispatch จะตัดสินใจเลือก method โดยดูแค่ว่าจะเลือกให้ class ไหนรับผิดชอบในการ handle การ call, โดยไม่ได้สนใจ type ของ arguments
ส่วน multiple dispatch มันจะเลือก method โดยดู type ของ arguments ด้วย
ถ้าทดลองนำ code ข้างบน ไป run ใน groovy ซึ่งเป็น multiple dispatch ผลลัพท์ทีได้ก็คือ

I 'm full. Hong Hong!!!
I don't like this. Meaw Meaw!!!

ทำ DSL ด้วย parser combinator

ช่วงนี้ทำระบบ billing ด้วย Grails อยู่ มันมีโจทย์ว่า user ต้องสามารถกำหนด policy การคิดเงินค่าโทรศัทพ์ได้เอง โดยรูปแบบของการคิดเงินถ้าเขียนออกมาเป็น text ก็ประมาณนี้

ถ้าเวลาที่โทรอยู่ในช่วงหนึ่งนาทีแรก ให้คิดเงินเต็มหนึ่งนาที ส่วนเวลาที่เกินให้ปัดที่หน่วยละ 6 วินาที โดยคิดหน่วยละ 10 % ของราคาต่อนาที

version แรกสุดที่ผมทำ หน้าตาออกมาประมาณนี้

[minimum: 60, nextCharge: 6, rateFunc: { x -> x * rate * 0.1}]

ไม่ต้องบอกก็รู้ตัวว่า ไม่มี user ที่ไหน config ได้แน่ มี closure หน้าตาประหลาดโผล่มาแบบนี้ (จริงๆแล้วมันคือ code ของ groovy ที่พร้อมจะ run นั่นเอง)

version ที่สอง ผมก็เลยปรับให้มันกระเดียดไปทางภาษาคนมากขึ้น หน้าตาออกมาแบบนี้

minimum 60 sec , nextcharge 6 sec : 10 %
หรือจะใช้หน่วย minute ด้วยก็ได้
minimum 1 min, nextcharge 6 sec : 10 %

เมื่อความต้องการเป็นแบบนี้ ก็ต้องหาวิธี implement, วิธีที่คุ้นเคยมากสุดก็คือใช้ Antlr เขียน Parser แต่บังเอิญเป็นคนขี้เบื่อ ก็เลยมองหาวิธีอื่นแทน ช่วงนี้ Scala กำลังมาแรง ประกอบกับเคยเห็นว่ามันทำ Parser combinator ได้ด้วย ก็เลยหวยออกที่ Scala + Parser Combinator

เริ่มแรกสุด parser ของเรา extends จาก StandardTokenParsers (มากับ Core ของ Scala อยู่แล้ว ไม่ใช่ external library)

class RateParser extends StandardTokenParsers {

}

กำหนด delimiters และ reserved word

  lexical.delimiters ++= List(":", "%", ",")
  lexical.reserved += ("minimum", "nextcharge", "min", "minute", "sec", "second", "m", "s")  

จากนั้นก็ define grammar
ถ้าดู code จะเห็นว่าเรา define parser ย่อยๆเต็มไปหมด อันนี้แหล่ะคือความหมายของ combinator นั่นคือเราเขียน parser ใหญ่ๆ ด้วยการการเอา parser เล็กๆย่อยๆมาประกอบกันนั่นเอง

  def rule: Parser[RateStrategy] = minimum ~ nextcharge ~ percent ^^
      { case (min ~ next) ~ percent => new RateStrategy(min, next, percent)}

  def minimum: Parser[Int] = "minimum" ~> unit <~ ","

  def nextcharge: Parser[Int] = "nextcharge" ~> unit <~ ":"

  def percent: Parser[Int] = numericLit <~ "%" ^^ (_.toInt)
  
  def unit: Parser[Int] = minuteUnit | secondUnit

  def minuteUnit: Parser[Int] = numericLit <~ ("min" | "minute" | "m") ^^ (_.toInt * 60)

  def secondUnit: Parser[Int] = numericLit <~ ("sec" | "second" | "s") ^^ (_.toInt)

จะเห็นว่ามี operator หน้าตาแปลกๆ เต็มไปหมด ไม่ต้องตกใจ มาลองดูแบบง่ายสุดก่อน เริ่มที่การ parse หน่วยเวลากันก่อน
จากโจทย์ของเขา จะเห็นว่าเราจะทำการ parse พวก "1 min", "60 sec"
กรณี minute จะเห็นว่า code หน้าตาแบบนี้

  def minuteUnit: Parser[Int] = numericLit <~ ("min" | "minute" | "m") ^^ (_.toInt * 60)

def minuteUnit: Parser[Int]

ก็คือการ define method ที่ return parser ที่ return Integer (Higher order function)

numericLit <~ ("min" | "minute" | "m")

ก็คือ ระบุว่า ประโยคจะเริ่มต้นด้วย integer จากนั้นจะตามด้วย "min" หรือ "minute" หรือ "m"
เครื่องหมาย "<~" เป็น operator ที่ extend มาจาก operator "~"
operator "~" มีความหมายว่า ถ้า parse argument ทางซ้ายสำเร็จ ก็ให้ทำ ทางขวาต่อ (chain)
แต่ถ้าไม่สำเร็จ ก็ abort
ส่วน "<~" เป็นการเพิ่มความหมายว่า argument ท่ีอยู่ทางซ้ายถือเป็นตัวที่เราสนใจ ให้ ignore argument ที่อยู่ด้านขวาไปได้เลย
Note: แน่นอน เมื่อมี "<~" ก็เลยมี "~>" ด้วย

^^ (_.toInt * 60)

เราเรียก transforms operator นั่นคือ ในกรณีนี้แทนที่จะ return String ตัวเลขนาทีไป เราจะเปลี่ยนให้มันเป็น integer ก่อน

ความยุ่งยากอันถัดไปก็คือ ต้องให้มันเรียกใช้จาก Groovy ได้ (โปรเจคหลักเป็น Groovy)
โชคดีที่ Class ที่ Scala compile ออกมามันหน้าตาดีมาก ไม่มีการแปลงชื่อหรือเปลี่ยนรูปมาก
ทำให้เราสามารถเรียกใช้ได้ตรงๆ

groovy:000> f = RateStrategyParser.parse("minimum 1 min , nextcharge 6 sec : 10%")    
===> RateStrategy@34a02677
groovy:000> f
===> RateStrategy@34a02677
groovy:000> f.calc(24.00, 72)
===> 28.80

config syntax ใน grails

ผมสงสัยเรื่อง configuration ใน grails มาได้พักใหญ่แล้ว
เพราะเห็น syntax มันแปลกประหลาดเหลือเกิน ลองดูตัวอย่างข้างล่างนี้

log4j.appender.stdout = "org.apache.log4j.ConsoleAppender"
log4j.appender."stdout.layout"="org.apache.log4j.PatternLayout"

ทำไมบรรทัดที่สองต้องมี quote ครอบด้วยหล่ะ?

class ที่ทำหน้าที่อ่าน file Config.groovy ของ grails ก็คือ ConfigSlurper
โดยวิธีการใช้งานเจ้า ConfigSlurper ก็คือแบบนี้

def config = new ConfigSlurper().parse(new File('/tmp/x.groovy').toURL())

สิ่งที่เจ้า ConfigSlurper return มาก็คือ Map ตัวหนึ่ง (มันคือ class ConfigObject ที่ extends จาก LinkedHashMap)

ที่นี้มาลองดู nature ของมันบ้าง
เริ่มจาก config ง่ายๆ บรรทัดเดียว

topic1.subtopic1=1

ผลลัพท์ที่ได้จากการ parse จะเป็น map หน้าตาแบบนี้

["topic1":["subtopic1":1]]

ที่นี้ถ้าลองเพิ่ม sub node เข้าไปใต้ subtopic แบบนี้

topic1.subtopic1=1
topic1.subtopic1.subofsubtopic1="foo"

เมื่อลอง parse ดู แทนที่จะได้ผลลัพท์ เรากลับได้ exception แบบนี้แทน

groovy.lang.MissingPropertyException: No such property: subofsubtopic1 for class: java.lang.Integer
 at script1226551599145.run(script1226551599145.groovy:2)
 at Script9.run(Script9:1)

ดูเหมือนว่าการทำงานภายในของมันก็คือ เมื่อมันต้องการ assign ค่า topic1.subtopic1.subofsubtopic1 มันจะไป get value โดยใช้ key topic1.subtopic1 จากนั้นก็พยายามจะ set property subofsubtopic1ลงใน value ที่ได้มาก ซึ่งไม่สำเร็จแน่ๆเพราะ value ที่ได้มันไม่ใช่ map อย่างที่ควรจะเป็น

ที่นี้ลอง config แบบนี้บ้าง

topic1.subtopic1.subofsubtopic1="foo"
topic1.subtopic1=1

ผลลัพท์ที่ได้คือ

["topic1":["subtopic1":1]]

อ้าว แล้ว subofsubtopic1 ของเราหายไปไหนหล่ะ
กลายเป็นว่า subofsubtopic1 ของเราถูก เจ้า topic1.subtopic1 override ค่าไปเรียบร้อยแล้ว

ลองให้เหลือ บรรทัดเดียวแบบนี้ ดูบ้าง

topic1.subtopic1.subofsubtopic1="foo"

ผลลัพท์ที่ได้ จะเป็นแบบนี้

["topic1":["subtopic1":["subofsubtopic1":"foo"]]]

สรุปได้ว่า เนื่องจาก ConfigSlurperใช้ nested map เป็น internal structure ในการเก็บผลลัพท์จากการ parse
ทำให้เกิดข้อจำกัดในการเก็บขึ้นมา ดังนั้นถ้าเราต้องการเก็บค่าแบบบ้างบนให้ได้ เราก็เลยต้อง hack มัน โดยการห่อค่าให้เป็น string แบบนี้แทน

topic1.subtopic1=1
topic1."subtopic1.subofsubtopic1"="foo"

ผลลัพท์ที่ได้จากการ map ก็จะเป็นแบบนี้

["topic1":["subtopic1":1, "subtopic1.subofsubtopic1":"foo"]]

อืมม์ไม่สวยเป็นอย่างยิ่ง น่าจะมีคน refactor นะ

สรุปได้ว่า ถ้าเรานำไปใช้งาน configuration ของเรา (ถ้าใช้ grails ก็ต้องเจอแน่ๆ)
เราก็ควรจะออกแบบ tree ของเราดีๆ อย่าให้เกิดกรณีที่ parent node มีค่า value attach อยู่
(ให้มี valueได้เฉพาะ leaf node)
ไม่งั้นอาจจะปวดหัวว่า ทำไมค่า config ถึงหายไป หรือไม่ก็ ทำไมถึง get config ที่ต้องการไม่เจอ

code ของ grails 's plugin

คราวก่อนที่เจอปัญหา xml-rpc บน grails, ผมได้นั่งแกะโครงสร้าง plugins ของ grails ไปแวบหนึ่ง
รู้สึกติดใจว่า ถ้ามีเวลาต้องมานั่งแกะให้เป็นเรื่องเป็นราว

วันนี้ได้ที ใน mailing list ของ th-grails-user มีปัญหาซึ่งพาดพิงถึง mail-plugin
ก็เลยจัดการ install แล้วก็นั่งแกะ code ว่ามันทำอะไรบ้าง

function หลักๆที่ mail plugin ทำก็คือ

• สร้าง service ที่ชื่อ mailService เพื่อให้ controller หรือ domain เรียกใช้ตามอัธยาศัย
  โดย service นี้ จะทำหน้าที่สร้าง builder ที่จะใช้แปลง closure ที่ pass เข้ามา ให้กลายเป็น mail message
  ก่อนจะ delegate ต่อให้ mailSender bean เป็นคนจัดการส่งออกไป
  (mailSender แอบใช้ของที่ spring มีอยู่แล้ว นั่นคือ org.springframework.mail.javamail.JavaMailSenderImpl)
  
• สร้าง method ที่ชื่อ sendMail ให้กับ controller ทุกตัวที่มี ผ่านทางกลไกของ metdata
  

code ในส่วนของ function แรกที่น่าสนใจ ก็คือการ define bean 'mailSender'
ลองดู code ที่มันใช้

def doWithSpring = {
    def config = application.config.grails.mail
    mailSender(JavaMailSenderImpl) {
        host = config.host ?: "localhost"
        defaultEncoding = config.encoding ?: "utf-8"
        if(config.port)
            port = config.port
        if(config.username)
            username = config.username
        if(config.password)
            password = config.password
        if(config.protocol)
            protocol = config.protocol
        if(config.props instanceof Map && config.props)
            javaMailProperties = config.props
    }
}

method นี้จะถูกเรียกใช้ในช่วง startup ของ grails
ซึ่งข้างในจะเห็นว่ามันใช้ DSL ในการ config spring
code ข้างบน ถ้าเขียนในแบบดั้งเดิมของ spring ก็จะออกมาทำนองนี้

<bean id="mailSender" 
      class="org.springframework.mail.javamail.JavaMailSenderImpl">
      <host>localhost</host>
      <defaultEncoding>utf-8</defaultEncoding>
      ...
</bean>

ข้อได้เปรียบที่เห็นได้ชัด สำหรับการใช้ DSL ในการ config spring ก็คือ
เราสามารถใส่ logic ลงไปได้ (เพราะมันเป็น code ไม่ใช่ xml)

ในส่วน function ที่สอง ที่มีการ inject method ให้กับทุก controller
ถ้าดูตาม code แล้วจะเห็นว่ามันทำแบบนี้

def doWithApplicationContext = { applicationContext ->
    configureSendMail(application, applicationContext)
}

def configureSendMail(application, applicationContext) {
    application.controllerClasses*.metaClass*.sendMail = {Closure callable ->
        applicationContext.mailService?.sendMail(callable)
    }
}

code กระทัดรัดมาก มันแค่ส่งต่อ closure ที่รับเข้ามาให้กับ mailService
ถ้าเป็น java code ก็ต้องยืดยาวประมาณนี้

MailService svr = (MailService) ctx.getBean('mailService');
if (svr != null) {
    svr.sendMail(...);
}

เริ่มใช้ grails

ช่วงเดือนที่ผ่านมา ผมได้มีโอกาสสัมผัสกับ Grails อย่างจริงๆจังเป็นครั้งแรก
โดยได้มีโอกาส implement open source project ตัวหนึ่งด้วย Grails

อารมณ์ในช่วงแรก ก็คือ "wow"
สาเหตุก็คือ มันใช้ stack ทุกอย่างที่ผมคุ้นเคย และใช้อยู่แล้ว
ไม่ว่าจะเป็น spring, hibernate
แต่นำมาลด noise ด้วยการทำ DSL บ้าง หรือลด noise ด้วยคุณสมบัติของตัวภาษา groovy เองบ้าง
แถมยังยึดแนว convention over configuration ของ Rails อีก
learning curve ก็เลยถือว่าน้อยมากๆ

พอผ่านอารมณ์ wow มาได้
ก็ได้เวลาขัดอกขัดใจบ้างแล้ว
เริ่มแรกสุด ก็คือ ผมจำชื่อ package ของ java class ที่ใช้บ่อยๆไม่ได้
เดิมผมผลักภาระไปให้ IDE มัน popup หรือ import ให้เรา
แต่พอมาใช้ groovy, เจ้า context assistent ของ groovy ใน eclipse มันทำงานช้าเหลือเกิน

ความขัดใจที่สองก็คือมัน compile ช้า
เวลาเขียน unit testing เพื่อทดสอบหาแนวทางการทำงานของ library ต่างๆ (เช่น lucene, nekohtml)
การ run แต่ละครั้งมันหนึืดเหลือเกิน

แต่สิ่งที่ผมยึดถือก็คือ คนเราปรับตัวได้
อย่าปล่อยให้ความลำบากเล็กๆน้อยๆ (จากความไม่เคยชินของเรา) มาเป็นอุปสรรคในการเรียนรู้

จากข้อ 1 ที่ไหนๆ groovy plugin มันไม่ได้ช่วยอะไรเรา (แถมยังขัดขาอีก)
ก็เลยเปลี่ยนไปใช้ emacs แทน (ซึ่งไม่มี context assistent แน่ๆ)
แล้วก็เปิด javadoc ไว้ข้างๆ เพื่อใช้ค้นหาชื่อ package
แต่ก็พบว่า ถ้าเราเขียนโปรแกรมแบบไม่ระบุ type มันก็จะช่วยลด import statement ไปได้เยอะเหมือนกัน

ส่วนข้อสอง ก็แก้โดย ใช้ groovy console ทดลองเขียนให้เรียบร้อยก่อน
จากนั้นค่อย copy ไปใส่ไว้ใน unit test.

Groovy in Ofbiz

น้องแซนแจ้งมาว่าขณะที่ merge source code ของ Ofbiz เข้า project Orangegears
พบว่ามี้ groovy code โผล่เข้ามาแล้วแล้ว
ว่าแล้วผมก็จัดแจง update source code ของ orangegears เสียหน่อย
แล้วก็สั่ง grep -ilR groovy ดู
ก็พบว่าเริ่มมีการ replace screen action script จากของเดิมที่เขียนด้วย bsh ไปเป็น groovy บ้างแล้ว
แล้วก็พบว่ามีการเตรียมการใช้ groovy ใน service layer อีกด้วย (แต่ยังไม่ได้มีการ implement)

ลองไล่เปรียบเทียบ syntax ของ bsh กับ groovy ดูว่า ช่วยลดรูปอะไรได้บ้าง

ใน ofbiz เวลา pass parameters มักจะใช้ Map ในการ pass arguments
พอเปลี่ยนเป็น groovy แล้วการสร้าง Map ก็เลยกระทัดรัดขึ้น

// bsh
payment = delegator.findByPrimaryKey("Payment", 
            UtilMisc.toMap("paymentId", paymentId)));
            
# groovy
payment = delegator.findByPrimaryKey("Payment", [paymentId : paymentId]);

แน่นอนพวกการ iterate collections นี่ได้ประโยชน์ไปเต็มๆ

// bsh
oibIter = orderItemBillings.iterator();
while (oibIter.hasNext()) {
    orderIb = oibIter.next();
    orders.add(orderIb.getString("orderId"));
}

# groovy
orderItemBillings.each { orderIb ->
    orders.add(orderIb.orderId);
}

การอ้างถึง value ใน Map
ด้วย syntax sugar ของ Groovy ก็เลย สะอาดสะอ้านขึ้นแบบนี้

// bsh
context.put("decimals", decimals);
context.put("rounding", rounding);

# groovy
context.decimals = decimals;
context.rounding = rounding;

การ check empty หรือ null collections ก็สบายตาขึ้น

// bsh
if (glAccounts != null && glAccounts.size() > 0) {
    glAccount = glAccounts.get(0);

# groovy
if (glAccounts) {
    glAccount = glAccounts[0];

delegate ใน groovy closure

งาน NJUG ที่ผ่านมาตอนที่ฟังคุณ cblue พูดเรื่อง groovy
มีตัวแปรใน closure ตัวหนึ่งที่ผมติดใจ ก็คือ delegate
กลับมาแล้วก็เลยต้องนั่งเปิด groovy document หาความรู้เพิ่มเติม
ก็เลยเจอ snippet code ที่น่าสนใจตัวนี้เข้า

เทคนิคที่น่าสนใจก็คือการเปลี่ยน reference ของ delegate ให้ชี้ไปยัง object ที่เราต้องการ

class XmlBuilder {
   def out
   XmlBuilder(out) { this.out = out }
   def invokeMethod(String name, args) {
       out << "<$name>"
       if(args[0] instanceof Closure) {
            args[0].delegate = this
            args[0].call()
       }
       else {
           out << args[0].toString()
       }
       out << "</$name>"
   }
}

ลองดูตัวอย่างการ run code ข้างบน
จะเห็นว่ามีการใช้ closure ซ้อนๆกัน

def xml = new XmlBuilder()
xml.html {
    head {
        title "Hello World"
    }
    body {
        p "Welcome!"
    }
}

ทุกๆครั้งที่ มีการ execute inner closure ก็จะมีการ switch delegate ให้ชี้ไปที่
XmlBuilder Object แทนที่จะเป็น default parent object

Declarative with groovy

กำลังทำงานอยู่ชิ้นหนึ่ง งานนี้เป็นงานรับข้อมูลงบการเงินเข้ามา
แล้วทำการสรุปพวก financial ratio ต่างๆออกมา
โดยสูตรของการคำนวณขึ้นอยู่กับ context ของผู้ที่ส่งงบเข้ามาด้วย
(เช่น สูตร ratio ของงบการเงินของธนาคาร ย่อมต่างจาก งบการเงินของพวกโรงงาน)
รายละเอียดปลีกย่อยมียุบยับ แต่ละไว้แล้วกัน

ประเด็นก็คือ เราอยากเขียนโปรแกรมให้กำหนดสูตรในลักษณะ declarative ได้
แทนที่จะเขียนเป็น method หรือ class ใน java แบบปกติ
เมื่ออยากได้ solution ที่เป็น declarative ก็เลยต้องมองหาพวก script language เข้ามาช่วย
ก็เลยหยิบเอา groovy มาลองทดสอบดู

ในเบื้องต้น เรามีสูตรแบบนี้อยู่

current_ratio = สินทรัพย์หมุนเวียน / หนี้สินหมุนเวียน

เขียนเป็น groovy ตรงๆก็คือ

current_ratio = element('asset') / element('liabilities')

โดย method element คือ helper ที่ช่วยดึงข้อมูลจากงบการเงิน

แต่พอลองทดสอบดู ก็พบว่า เราไม่สามารถ bind method element เข้าไปตรงๆได้
ต้องแปลงสูตรให้เป็น

current_ratio = env.element('asset') / env.element('liabilities')

การ evaluate code นี้ทำได้โดย

Binding binding = new Binding();
binding.setVariable("env", helperObject);
GroovyShell shell = new GroovyShell(binding);
shell.evaluate(src);
float current_ratio = binding.getVariable("current_ratio");

ใช้งานได้ แต่ดูแล้ว การที่ต้องใช้ "env" ก่อนนั้นดูไม่งามเลย
นอกจากนี้ยังมีประเด็นเรื่อง fix ชื่อสูตรไว้ใน code ด้วย
ประกอบกับที่พอนำ idea ไปคุยกับ user, user บอกว่า
อยากให้ script มันสามารถ include กันได้ด้วย
เพราะว่า sector แต่ละ sector มันมี common ratio อยู่

ก็เลยออกแบบใหม่
เอา Closure เข้ามาช่วย
สุดท้ายได้หน้าตาประมาณนี้ออกมา

formulas.declare {
  include 'common.script'
  
  formula('current ratio') {
    element('assets')/element('liabilities')
  }
  
  formula('quick ratio') {
    element('cash') + .... / element('liabilities')
  }
}

ซึ่งการ evaluate script นี้จะยังไม่ได้ผลลัพท์ทันที
แต่จะได้ Closure จำนวนหนึ่งออกมา ซึ่งเราจะเก็บไว้ก่อน
แล้วค่อยนำ Closure พวกนี้ไป run ใน context ใดๆที่เราต้องการ

code ที่ใช้อ่าน formula เข้ามา หน้าตาเป็นแบบนี้
พระเอกของเรื่องนี้คือ closure.setDelegate(..)

public FormulaSet load(String name) throws IOException {
    final FormulaSet ret = new FormulaSet();
    Binding binding = new Binding();            
    binding.setVariable("formulas", new Delegate() {
            
            public void declare(Closure c) {
                c.setDelegate(this);                                    
                c.call();
            }

            public void formula(String name, Closure c) {
                Formula f = new FormulaImpl(name, c);
                ret.put(name, f);
            }
            
            public void include(String name) throws IOException {
                FormulaSet set = FormulaLoaderImpl.this.load(name);
                ret.add(set);
            }
            
        });
    GroovyShell shell = new GroovyShell(binding);
    InputStream src = getClass().getClassLoader().
        getResourceAsStream(scriptPath + name);
    if (src == null) throw new IOException("script " + name + " not found!");
    Script script = shell.parse(src);
    script.run();
    return ret;
}