Alasan kedua atas kemalasan saya di blog ini, adalah saya sedang jenuh mempelajari desain bahasa dan teknik kompilasi (kapan-kapan balik, it’s my deepest passion), pindah mempelajari bagaimana memproduksi film animasi sendiri. Resolusi 2010 saya, harus sudah memproduksi setidaknya satu film pendek animasi. Software yang saya gunakan adalah Blender 3D, dan waktu dan kapasitas otak yang tersisa setelah mempelajari animasi dan sketsa (untuk storyboarding dan desain karakter), saya gunakan untuk memprogram perangkat-perangkat tambahan untuk Blender agar memudahkan proses menjadi One-Man Pixar

Menggambar dan animasi ternyata susah, dan pikiran saya kadang kelayapan kembali ke pemrograman. Satu bidang yang menjembatani keduanya adalah pemrograman grafis, dan selama 1 tahun terakhir di waktu luang saya mengakrabkan diri dengan bahasa-bahasa pemrograman grafis PostScript, Processing, dan yang terakhir: ActionScript. Di antara ketiganya saya paling menyukai ActionScript, karena lebih manusiawi dari PostScript dan lebih mudah diajak eksperimen ketimbang Processing (sayangnya berbasis Java dan sulit menguji program lewat command-line).

Meski tersedia IDE semacam Flex Builder atau Flash Develop, dalam menciptakan lingkungan pemrograman ActionScript yang nyaman, saya kembali bergantung pada GNU Emacs tercinta, dan menambahkan paket/file berikut:

• Adobe Flex [URL] dan/atau SWFTools [URL]. Diperlukan untuk mengkompilasi file .as kode sumber program menjadi file Flash .swf. Kompiler SWFTools as3compile adalah yang waktu kompilasinya paling cepat dan berukuran paling kecil di antara kedua pilihan ini, namun kompiler Adobe Flex mxmlc lebih ketat memberlakukan sintaks ActionScript, ditambah bonus komponen-komponen Flex yang memudahkan kita sewaktu-waktu menciptakan Rich Internet Application.
• Adobe Flash Player – Debugger Version [URL]. Diperlukan untuk menguji file Flash yang dihasilkan. Versi player Flash ini memudahkan debugging program-program ActionScript, termasuk mencetak perintah tracing ke stdout.
• Emacs ActionScript mode [URL]. Di antara berbagai versi yang ditawarkan, saya paling sreg dengan buatan John Connors (HTML, jangan langsung "Save As…"), turunan dialek Java dari cc-mode.
• Dokumentasi ActionScript + Adobe Flex [URL]. Tersedia satu file arsip berisi seluruh dokumentasi offline ActionScript dan Adobe Flex dalam format HTML dengan ukuran total cukup besar, 100MB++, yang kemudian saya ubah menjadi file .chm HTML Help berukuran 17MB.

Terakhir, saya tambahkan aturan khusus ActionScript berikut ke dalam Makefile generik (daftar Makefile yang digunakan GNU Make bila tidak ditemukan makefile per-proyek, ditentukan dalam env-variable MAKEFILES):

# Actionscript
SWFWIDTH = 640
SWFHEIGHT = 480
FLASHPRJ = flashplayer_10_sa_debug.exe
AS3COMPILE = as3compile --width $(SWFWIDTH) --height $(SWFHEIGHT)
MXMLC = mxmlc -default-background-color=0x7f7f7f \
        -default-size=$(SWFWIDTH),$(SWFHEIGHT)
%_st.swf: %.as
        $(AS3COMPILE) $^ -o $@ --width 800 --height 600

%.swf: %.as
        $(MXMLC) $^ -o $@

%_test: %.swf
        $(FLASHPRJ) $^

%.html:: %.swf
        @echo '<object width="$(SWFWIDTH)" height="$(SWFHEIGHT)">' \
                '<param name="movie" value="$^">' \
                '<embed src="$^" width="$(SWFWIDTH)"'\
                ' height="$(SWFHEIGHT)">' \
                '</embed></object>' > $@

… sehingga untuk menguji file XYZ.as saya hanya perlu menjalankan perintah make XYZ_test (yang dalam Emacs saya petakan ke satu tombol dengan fungsi Emacs-Lisp).

Kesan saya tentang ActionScript sejauh ini positif. Sekadar membuat program ActionScript untuk credit-roll film sangatlah mudah (dan jauh lebih cepat di-render ketimbang jika membuatnya sebagai scene 3D dalam Blender), mungkin saya akan mengusulkannya untuk Seruling Project-nya Blender Indonesia di mana saya turut terlibat (jelas open source, jelas punya keunggulan, tinggal presentasinya seperti apa…).

Akhir Februari lalu, saat penasaran lagi dengan Nusa, saya temui artikel menarik di situs Pak Bernaridho, pencipta bahasa ini. Mungkin beliau terkadang melakukan narcissism-search —seperti saya juga — karena di sana beliau merespon kritik pedas seorang blogger dari Kalimantan Selatan yang, meski judulnya salah alamat, diarahkan pada pandangan beliau tentang software bebas. Sepintas lalu artikel Pak Bernaridho memang terkesan menghina software bebas, namun berkat tanggapan ini segala isu yang keruh bagi saya menjadi jelas, bahkan akhirnya mempengaruhi perspektif saya sendiri. Maka sebelum saya lancarkan tanggapan saya secara penuh, saya ucapkan terima kasih baik pada Pak Syamsuddin Ideris yang berani memulai proses dialektik ini maupun Pak Bernaridho Hutabarat yang bersedia merespon dengan kepala dingin.

Para pengembang software profesional tentu telah familiar dengan inti catatan; saya hanya mempertegas saja konsep yang jarang ditekankan dalam artikel lain. Now, on with the show!

Software sebagai Produk

Saya yakin Anda akrab dengan software yang dipasarkan sebagai produk. Dikemas dengan profesional, didistribusikan lengkap dengan buku manual, garansi dan dukungan konsumen, dan diberi label harga seperti rata-rata produk konsumen. Harga produk software telah memperhitungkan segala biaya konstruksinya, termasuk biaya intangible berupa kompensasi terhadap beban intelektual yang diemban para pemrogram software yang dimaksud saat menciptakannya. Mereka tidak menyebutnya demikian, tentu saja, karena biaya tersebut telah difaktorkan ke dalam remunerasi untuk masing-masing pemrogram.

Di sinilah terletak justifikasi untuk memperlakukan software selayaknya sebuah produk konsumen. Semua biaya tersebut nyata meski inti dari produk akhirnya adalah kombinasi berbagai mekanisme dan implementasi algoritma kompleks yang abstrak, bukan rangkaian bit pseudorandom. Seribu simpanse memukul-mukul tombol seribu mesin ketik selama seribu tahun tidak akan menghasilkan karya Shakespeare, apalagi Windows XP! Kita tahu bahwa para pemrogram tersebut layak atas gaji pertahun US$ 60.000 ke atas. Kita tahu bahwa merakit sebuah software komersial bukan pekerjaan mudah.

Tapi pada pengetahuan tersebut pula, terletak kelemahan yang saat ini membatasi model bisnis ini, dan industri software dalam negeri secara keseluruhan: rata-rata masyarakat Indonesia tidak tahu bahwa menciptakan software itu sulit, apa lagi yang berkualitas tinggi. Yang mereka tahu adalah mereka ingin memanfaatkan komputer dengan mudah, dan bila software komersial-lah solusi terbaik, itulah yang mereka gunakan. Dan bila menggunakannya secara ilegal adalah solusi termudah, itulah yang akan mereka lakukan! Produsen software yang tidak turut mempertimbangkan bahwa karya mereka, berapapun harganya, cepat atau lambat akan muncul pula di Glodok dengan harga per DVD Rp 30.000 harus bersiap-siap menelan kekecewaan.

Bill Gates kurang-lebih mempopulerkan model bisnis ini sejak tahun 1976, saat mempublikasikan suratnya yang turut menandai lahirnya industri software, An Open Letter to Hobbyists. Di sana ia berujar sederhana,

Who can afford to do professional work for nothing?

Ya, masuk akal jika kita turut bertanya: siapa yang mau membuat software berkualitas tinggi tanpa imbalan? Dan kita akan lihat, bahwa model bisnis alternatifnya-pun tetap tunduk pada hukum alam yang sederhana ini.

Software sebagai Jasa

Selain sebagai produk, software juga dapat dipandang sebagai jasa, atau pelengkap jasa. Kemunculan model alternatif ini ditandai, tentu saja, dengan pemunculan software bebas. Bentuknya bervariasi, dari yang ideologis (Free Software Foundation) sampai pragmatis (Open Source Initiative). Untuk memahami logika dari model bisnis yang menggunakan software sebagai pelengkap jasa, kita mulai saja dengan menganggap pekerjaan para sukarelawan kontributor software bebas sebagai pendanaan tidak langsung. Mereka telah memiliki sumber penghidupan yang memadai, sehingga tidak memusingkan profit saat menyumbangkan waktu, tenaga dan pikiran mereka pada sebuah proyek software bebas. Diluar pendanaan tidak langsung tersebut —dan donasi— sebenarnya banyak cara lain yang digunakan pengelola software bebas untuk mendukung kesinambungan pengembangan produk mereka, misalnya:

• wxWidgets didukung pula oleh penjualan perangkat bantu konstruksi program semacam wxDesigner atau DialogBlocks yang diciptakan oleh para kontributor utama wxWidgets, secara berturutan, Robert Roebling dan Julian Smart.
• Bahasa Processing didukung pula oleh penjualan buku-buku tentang pemanfaatan bahasa pemrograman visual tersebut.
• GCC didukung pula oleh, di antaranya, perusahaan konsultansi semacam Cygnus Support (sekarang bagian dari Red Hat) yang menjual kepakaran dan keakraban mereka dengan GCC (mampu membangun backend untuk mikroprosesor baru, atau porting ke platform baru, misalnya), atau para akademisi yang menggunakan GCC dalam riset dengan dana pihak ketiga.
• Software blog semacam WordPress atau Movable Type didukung pula oleh jasa hosting blog, atau komersialisasi fitur "Pro" dari layanan mereka.
• Blender didukung pula oleh penjualan buku/video berbagai tutorial dan referensi penggunaan Blender, serta penjualan produk-produk —saat ini setidaknya dua buah film (Elephant’s Dream dan Big Buck Bunny) serta satu buah game (Yo, Frankie!)— yang diciptakan dengan Blender.
• ImageMagick didukung pula oleh penjualan lisensi penggunaan komersial, serta setidaknya dua buku tentang penggunaan perangkat tersebut.
• Apache didukung pula oleh pendanaan dari IBM, yang menilai bahwa server-HTTP dengan biaya terjangkau dapat mendukung penjualan produk server mereka.
• GNU/Linux didukung pula oleh perusahaan semacam Red Hat atau Mandriva yang menjual distribusi ramah-pengguna dari sistem operasi tersebut, dengan buku referensi dan panduan penggunaan, serta menyewakan dukungan konsumen pada pengguna korporat.

Tidak saya ragukan bahwa masih banyak sumber pendanaan lain untuk menjaga kelangsungan hidup sebuah proyek software bebas (termasuk yang disebut di atas), terutama untuk software dengan manfaat luas seperti GNU/Linux. Yang ingin saya garis bawahi dari contoh (yang sangat tidak lengkap) di atas adalah sebuah pola umum, berupa peletakan masing-masing software dalam sebuah kerangka bisnis yang lebih luas: entah itu digabungkan dengan penyediaan jasa (konsultansi, dukungan konsumen) atau penjualan produk (hardware server, buku, perangkat bantu pemrograman), atau keduanya. Software bebas yang berhasil jarang berdiri sendiri: hampir selalu ada dukungan dari pihak-pihak yang dapat memanfaatkannya secara ekonomis.

Memang ada software bebas yang tidak memenuhi "pola umum" tersebut, misalnya (CMIIW) MediaWiki yang —dibawah naungan Wikimedia Foundation— secara eksklusif bergantung pada donasi. Satu hal yang saya kritik dari pandangan Pak Bernaridho, meminta donasi tidak harus identik dengan mengemis, dan memberi donasi tentu tidak sama dengan berbelas kasihan. Perspektif lain yang lebih positif adalah Set Your Own Price ("If you found this software as useful, please consider donating!") atau Do For Greater Good (Wikipedia: "Lots of others found Wikipedia useful, please consider donating!").

Perkembangan di Indonesia

Mengenai perubahan taktik promosi IGOS oleh Depkominfo yang diutarakan Pak Bernaridho, saya hanya bisa tersenyum karena sudah sejak lama dapat menebak, bahwa mental senang-gratisan orang Indonesia tidak dapat dimanipulasi untuk menguntungkan software bebas, karena tidak dibarengi dengan pemahaman etis yang sinkron. Sampai sekarang, bagi saya IGOS lebih identik dengan seremoni-seremoni khas pemerintah, ketimbang gebrakan nyata.

Untungnya, tanpa gegap-gempita IGOS pun dunia usaha mulai merespon positif keberadaan software bebas. BusinessWeek Indonesia edisi bulan ini (Maret 2009) turut meliput beberapa korporasi dalam negeri yang melakukan migrasi ke sistem open source berbasis platform GNU/Linux. Rata-rata proses migrasi baru berjalan beberapa tahun, dan yang relatif paling matang sepertinya adalah PT TELKOM, yang telah memulainya sejak tahun 2000.

Saya tidak dapat mengambil kesimpulan definitif dari fakta-fakta semacam itu, namun tanda-tandanya mulai jelas, bahwa dunia usaha secara umum mulai dapat menerima penggunaan software bebas. Setidaknya tiga tahun terakhir saya lihat mulai banyak perusahaan konsultansi dan perangkat lunak web bermunculan, yang percaya diri menggunakan platform LAMP. Itu pun gejala yang cukup baik. Intinya —dan ini kesimpulan yang sudah basi sekali, meski banyak yang belum mengerti— software bebas tidak dapat dengan serta-merta diidentikkan dengan "amatiran" atau "pengemis". Banyak software bebas (buatan orang luar Indonesia) yang robust dan berkualitas tinggi, serta dapat bernilai ekonomis bagi penciptanya tanpa melulu bergantung pada donasi. Tinggal komunitas pemrogram Indonesia —saya, Anda, dan semua rekan kita— yang harus membuktikannya dalam konteks software buatan dalam negeri!

Jadinya kali ini saya hanya akan menggunakan cerita tentang implementasi scanner BAIK sebagai konteks untuk sebuah dongeng, tentang ekspresi regular dan dua cara umum dalam memanfaatkannya untuk memproses bahasa pemrograman. Seperti sebelumnya, akan saya sertakan program-program pendek yang mengilustrasikan kedua pendekatan tersebut, yaitu sebuah pustaka ekspresi regular…

> ((build-regexp-matcher "ba+c?b") "baaaaaaaaab")
#t
> ((build-regexp-matcher "ba+c?b") "bacb")
#t

… dan sebuah pembangkit scanner untuk bahasa C.

> (generate-regexp-matcher-c-code "ba+c?b")
int match( char* cstr ) {
   char* c = cstr;
   if( c && *c == 'b' ) {
      ++c;
      if( c && *c == 'a' ) {
         ++c;
         while( c && *c == 'a' ) ++c;
         if( c && *c == 'c' ) ++c;
         if( c && *c == 'b' ) {
            ++c;
            return 1;
         }
      }
   }
   return 0;
}
>

Meski program ini sederhana dan ringkas (agar saya tidak dikira sedang bersaing panjang-panjangan blog dengan Steve Yegge), namun ia memadai untuk tujuan saya dan masih membuka kesempatan bagi yang berminat untuk mengembangkannya.

Ekspresi Regular

Di antara keempat tipe grammar dalam Hierarki Chomsky, Grammar Regular adalah jenis grammar paling efisien untuk mengekspresikan pola linier. Batasan Grammar Regular, menurut "Parsing Techniques"-nya Grune dan Jacobs:

[A] right-hand side may only contain one non-terminal and it must come at the end.

membuat terbayang di benak sebuah mesin yang menjejerkan simbol demi simbol berdasarkan satu set aturan sebuah program, sampai aturan yang digunakan tidak memungkinkan diletakkannya satupun simbol baru. Contohnya grammar berikut:

A -> a B
B -> b c C
C -> A
C ->

Dengan simbol awal A, grammar di atas hanya dapat membangkitkan string "abc…" secara linier…

Mesin Regular: Grammar Regular sebagai perangkat pembangkit.

Kita bisa saja meletakkan aturan tambahan, misalnya

C -> B A

untuk menciptakan percabangan dalam proses produksi kalimat, tapi ini sudah bukan Grammar Regular lagi. Maka ciri khas GR sebagai perangkat pengenal¹ adalah: Simbol yang ia nantikan hanya bergantung pada simbol yang telah ia temukan dan aturan produksi yang tengah digunakan.

Karakteristik ini mengingatkan kita akan automata keadaan-berhingga (finite-state automata), karena pembaca bahasa dengan grammar regular (bahasa regular) hanya perlu menyimpan informasi tentang keadaannya saat itu (state) dan berubah keadaan, diam, atau berhenti membaca pada setiap kata (input). Dengan berbekal struktur data list atau tree, seorang pemrogram dapat dengan mudah membuat program yang mengenali bahasa regular.

Maka sampailah kita pada pembahasan tentang ekspresi regular (regular expression). Meski saya yakin Anda sudah tahu apa itu regex dan bagaimana cara menggunakannya, saya tebak Anda —seperti juga saya— belum tahu persis bagaimana fasilitas regex diimplementasikan. Untungnya, dengan membuat prototip fasilitas regex dalam bahasa Scheme setidaknya kita bisa mendapatkan gambaran.

Inti dari prototip ini hanya berupa satu fungsi. Ia hanya mendukung subset pokok dari apa yang kita kenal sebagai "regex" (karena "regex" sekarang bukan sekadar ekspresi regular lagi). Berikut kode utamanya:

(define (build-regexp-list-pattern list-regexp)
  (let loop ([list-regexp list-regexp] [fa (list)] [fa-tail ()])
    (if (null? list-regexp)
        (append fa fa-tail)
        (let ([head (car list-regexp)] [tail (cdr list-regexp)])
          (cond
           ;; Star closure
           [(and (eq? head #\*)
                 (char? (car fa-tail)))
            (loop tail fa (list (cons 'star fa-tail)))]
           ;; Kleene closure
           [(and (eq? head #\+)
                 (char? (car fa-tail)))
            (loop tail fa (list (car fa-tail) (cons 'star fa-tail)))]
           ;; Optional presence
           [(and (eq? head #\?)
                 (not (null? fa-tail)))
            (loop tail fa (list (cons 'opt fa-tail)))]
           ;; Match-all character
           [(eq? head #\.)
            (loop tail (append fa fa-tail) (list 'any))]
           [else
            (loop tail (append fa fa-tail) (list head))]
           )))))

Fungsi build-regexp-list-pattern di atas memanfaatkan sifat linier Grammar Regular. Ia menerima string regex dalam wujud list (agar tidak perlu proses scan), dan menghasilkan struktur list lain berisi pola kalimat regular. Misalnya,

> (build-regexp-list-pattern (string->list "z?ab*c+"))
((opt #\z) #\a (star #\b) #\c (star #\c))
>

Sebagai satu bukti bahwa fungsi regex di atas masih dapat dikembangkan, perhatikan bahwa Kleene closure didefinisikan menggunakan star closure: a+ sebagai aa*. Fasilitas lain yang dapat kita tambahkan adalah pembatasan frekuensi semacam "x{3,5}", yang dapat diterjemahkan sebagai "xxxx?x?". Dengan bekal fungsi sederhana tersebut, kita akan menjelajahi kedua alternatif pemanfaatan regex dalam perakitan komponen scanner dalam pemroses bahasa.

Teknik #1: Pembangkitan Dinamis

Teknik ini yang digunakan oleh pustaka regex generik. Karena pustaka semacam ini digunakan untuk berbagai keperluan yang belum tentu dapat diantisipasi penciptanya, string ekspresi regular harus diterjemahkan terlebih dahulu, dan struktur data yang dihasilkannya disimpan dalam memori sepanjang fungsi pengenal ekspresi tersebut masih diperlukan. Misalnya, menggunakan struktur data yang dihasilkan build-regexp-list-pattern kita dapat membuat fungsi validasi sederhana:

(define (build-regexp-matcher regexp)
  (let ([pattern (build-regexp-list-pattern (string->list regexp))])
    (lambda (str) (match-pattern pattern str))))

(define (build-regexp-list-pattern list-regexp)
  (let loop ([list-regexp list-regexp] [fa (list)] [fa-tail ()])
    (if (null? list-regexp)
        (append fa fa-tail)
        (let ([head (car list-regexp)] [tail (cdr list-regexp)])
          (cond
           ;; Star closure
           [(and (eq? head #\*)
                 (char? (car fa-tail)))
            (loop tail fa (list (cons 'star fa-tail)))]
           ;; Kleene closure
           [(and (eq? head #\+)
                 (char? (car fa-tail)))
            (loop tail fa (list (car fa-tail) (cons 'star fa-tail)))]
           ;; Optional presence
           [(and (eq? head #\?)
                 (not (null? fa-tail)))
            (loop tail fa (list (cons 'opt fa-tail)))]
           ;; Match-all character
           [(eq? head #\.)
            (loop tail (append fa fa-tail) (list 'any))]
           [else
            (loop tail (append fa fa-tail) (list head))]
           )))))

Fungsi build-regexp-matcher mengembalikan fungsi validasi string. Selama fungsi validasi tersebut digunakan, selama itu pula struktur data pola regular diperlukan.

Teknik #2: Pembangkitan Statis

Teknik seperti ini, kurang-lebih, yang digunakan oleh pembangkit penganalisa leksikal baik yang memakai switch (e.g. re2c) atau tabel DFA (e.g. flex) untuk mengubah keadaan automaton. Fungsi berikut menyediakan fasilitas serupa:

(define (generate-regexp-matcher-c-code regexp)
  (let ([pattern (build-regexp-list-pattern (string->list regexp))]
        [echo (lambda (level fmt . vals)
                (display (format "~a~a\n"
                                 (make-string (* level 3) #\space)
                                 (apply format fmt vals))))])
    (echo 0 "int match( char* cstr ) {")
    (echo 1 "char* c = cstr;")
    (let recurse ([pattern pattern] [level 1])
      (if (null? pattern)
          (echo level "return 1;")
          (let ([head (car pattern)] [tail (cdr pattern)])
            (cond
             ;; Star closure
             [(and (list? head)
                   (eq? (car head) 'star))
              (echo level "while( c && *c == '~a' ) ++c;" (cadr head))
              (recurse tail level)
              ]
             ;; Optional presence
             [(and (list? head)
                   (eq? (car head) 'opt))
              (echo level "if( c && *c == '~a' ) ++c;" (cadr head))
              (recurse tail level)
              ]
             ;; Match-all character
             [(eq? head 'any)
              (echo level "++c;")
              (recurse tail level)
              ]
             [else
              (echo level "if( c && *c == '~a' ) {" head)
              (echo (1+ level) "++c;")
              (recurse tail (+ level 1))
              (echo level "}")
              ]
             ))
          ))
    (echo 1 "return 0;")
    (echo 0 "}")))

Pada dasarnya teknik pembangkitan statis ini memanfaatkan informasi tentang pola-pola lexeme yang dinantikan, dan mengkodekan informasi tersebut dalam program. Pemanfaatan informasi seperti ini lazim disebut sebagai evaluasi parsial, yang tujuannya tidak lain adalah optimasi program. Bila kita tahu program kita (translator atau interpreter) hanya akan menerima input dalam bahasa tertentu, kenapa harus repot-repot mengakomodasi input di luar bahasa tersebut?

Evaluasi Parsial Untuk Kemudahan Pengelolaan

Awalnya saya mau bilang, dari sudut pandang pemrogram translator, perbedaan kedua teknik di atas adalah pada efisiensi. Logika dasarnya begini: dengan pembangkit scanner, string ekspresi regular diubah menjadi kode, bagian dari program translator. Setiap kali program dijalankan, pola yang akan dicari telah tersedia, menyatu dengan alur komputasi program. Berbeda dengan pustaka regex, di mana string ekspresi regular dimuat dalam citra biner translator dan dibaca untuk membangkitkan struktur data pola, setiap kali translator (atau kalau pemrogramnya masih awam, fungsi scanner) dijalankan.

Secara intuitif, kita bisa yakin bahwa pembangkitan statis lebih cepat ketimbang pembangkitan dinamis karena tidak memerlukan alokasi dan dealokasi struktur data dinamis, serta dereferensi pointer. Pertanyaannya adalah: seberapa signifikan peningkatan kecepatan tersebut? Saat akan menulis dan menguji contoh, saya terbentur satu fakta: rata-rata komputer sekarang sudah sedemikian cepatnya, perbedaan kecepatan antara pengenal bahasa yang menggunakan pustaka regex generik dan pembangkit scanner baru terasa bila dipanggil 500 ribu kali secara beruntun². Memangnya ada program pengenal bahasa yang pola penggunaannya seperti itu?

Konsekuensinya, salah satu pokok opini awal saya sebelum menulis catatan ini, "untuk merakit scanner, selalu gunakan pembangkit scanner", gugur dengan sendirinya (meski judulnya dipertahankan, karena tidak terlalu menyimpang dari fakta, catchy, dan saya suka peran Russell Crowe di film ini). Saat akan menciptakan sebuah program, seseorang bebas menggunakan perangkat apapun yang ia rasa paling tepat. Bila perakitan scanner menggunakan pustaka regex lebih mudah baginya, terserah! Asalkan ia tahu semua alternatif, serta kelebihan dan kekurangan masing-masing.

Namun pokok opini kedua saya rasanya tetap valid, sejalan dengan catatan sebelumnya: Evaluasi parsial membuat kompleksitas program jauh lebih mudah ditangani pemrogram. Pembangkit scanner yang baik tidak selalu lebih efisien dari perakitan scanner secara manual, tapi ia selalu lebih mudah dikelola. Sebagai contoh, meski saya bilang kode ini jauh dari ideal, analisa leksikal dalam prototip kompiler Jeruk³ dilakukan oleh satu fungsi berikut (memakai re2c):

/**
 * Melakukan analisa leksikal pada file input, mengisi buffer bila
 * diperlukan
 *
 * \param lexer scanner
 *
 * \return Nilai enumerasi tipe token
 */
int lexer_scan( void *lexer ) {
  Lexer *l = (Lexer*) lexer;
  int level_komentar = 0;
 standar:
  l->token = l->cursor;
  /*!re2c
    digit* "." digit+
    { goto akhiran_float; }
    digit+ "." digit*
    { goto akhiran_float; }
    digit+
    { RET( tk_INTEGER ); }

    huruf (huruf|digit|[_])*
    { RET( keyword_chk( lexer_cstr(l) ); ); }

    ["]
    { goto uniline_string; }

    ["]{3}
    { goto multiline_string; }

    "+" { RET( tk_PLUS ); }
    "-" { RET( tk_MINUS ); }
    "*" { RET( tk_MULT ); }
    "/" { RET( tk_DIV ); }

    "(" { RET( tk_LPAREN ); }
    ")" { RET( tk_RPAREN ); }
    "{" { RET( tk_LCBRACKET ); }
    "}" { RET( tk_RCBRACKET ); }
    "[" { RET( tk_LSBRACKET ); }
    "]" { RET( tk_RSBRACKET ); }

    "<"  { RET( tk_LT ); }
    ">"  { RET( tk_GT ); }
    "<=" { RET( tk_LEQ ); }
    ">=" { RET( tk_GEQ ); }
    "="  { RET( tk_EQ ); }
    "!=" { RET( tk_NEQ ); }

    "&" { RET( tk_AND ); }
    "|" { RET( tk_OR ); }

    ":=" { RET( tk_ASSIGNMENT ); }

    ";" { RET( tk_SEMICOLON ); }
    "," { RET( tk_COMMA ); }

    '\r'?'\n'
    { if( l->cursor >= l->eof )
      { RET( tk_EOI ); }
      l->last_nl = l->cursor;
      ++l->line_num;
      l->token = l->cursor; goto standar;
    }

    spasi+ { l->token = l->cursor; goto standar; }

    "//" { while( *l->cursor != '\n' ) ++l->cursor; goto standar; }

    "\/*" { ++level_komentar; goto komentar; }

    [^]
    { @@error( "Karakter tidak dikenali, \'\\%.3d\' = \'%c\'",
               l->token[0], l->token[0] )
    }

   */
 akhiran_float:
  /*!re2c
    ( [Ee] [+-]? digit+ )?
    { RET( tk_FLOAT ); }

    '\r'?'\n'
    { if( l->cursor >= l->eof )
      { RET( tk_EOI ); }
      l->last_nl = l->cursor;
      ++l->line_num;
      l->token = l->cursor; goto standar;
    }
   */
 uniline_string:
  /*!re2c
    ["]
    { RET( tk_STRING ); }

    [^]
    { goto uniline_string;
    }

    '\r'?'\n'
    { @@error("String tidak ditutup"); }
   */
 multiline_string:
  /*!re2c
    ["]{3}
    { RET( tk_STRING ); }

    [^]
    { goto multiline_string;
    }

    '\r'?'\n'
    { if( l->cursor == l->eof )
      { @@error("String baris-jamak tidak ditutup"); }
      goto multiline_string;
    }
    */
 komentar:
  /*!re2c
    "\/*" { ++level_komentar; goto komentar; }

    "*\/"
    { --level_komentar; if( level_komentar == 0 ) goto standar; }

    '\r'?'\n'
    { if( l->cursor == l->eof )
      { @@error("Baris komentar tidak ditutup"); }
      l->last_nl = l->cursor;
      ++l->line_num; goto komentar;
    }

    [^] { goto komentar; }
   */
  RET( tk_EOI );
}

… dan satu fungsi tambahan keyword_chk untuk membedakan keyword dari identifier menggunakan tabel hash. Seandainyapun diiming-imingi imbalan agar menggunakan cara lain, saya tetap lebih memilih teknik pembangkitan statis seperti di atas. Mudah dibaca, dipahami, diubah dan dikembangkan.

1. Grammar mempunyai dua fungsi: sebagai perangkat pembangkit (generator) dan pengenal (akseptor) kalimat.

2. Teknik prefetching Windows memungkinkan eksekusi program untuk kali kedua dan seterusnya lebih cepat dari yang pertama.

3. Saya mengembangkan sendiri kompiler ini di waktu senggang, membuatnya sering terbengkalai.