ООП в Окамле

[thedeemon]

Сегодня впервые столкнулся с ситуацией, где использование ООП фич Окамла показалось уместным. Понадобилось по-разному трансформировать дерево программы в моем конпеляторе Leo. Например, нужно заменить переменные с заданными именами на заданные выражения. Или заменить везде один оператор на другой. В обоих случаях нужно аккуратно рекурсивно обойти все дерево и построить точно такое же, но в одном аспекте отличающееся. Дерево описывается набором ссылающихся друг на друга алгебраических типов - стейтменты, выражения, условия и т.д. Был бы это один тип, можно было бы следать универсальную функцию map, рекурсивно применяющую функцию-аргумент к узлам дерева, а так получается, что функций и аргументов понадобится много. Поэтому сделал иначе: объединил функции рекурсивного обхода в один класс, у которого можно переопределить нужные куски, остальное отдав на откуп унаследованной функциональности.

class mapper =  
  object(self) 
    method map_code code = List.map self#map_stmt code 
     
    method map_stmt = function 
      | Break | DefVar _ as x -> x 
      | Assign(lv, rv) -> Assign(self#map_lvalue lv, self#map_rvalue rv)    
      | Call(name, rvs) -> Call(name, List.map self#map_rvalue rvs)         
      | Comp code -> Comp(self#map_code code) 
      ... 
       
    method map_lvalue = function  ... 
    method map_rvalue = function  ... 
    method map_cond = function  ...  
  end 

Например, замена переменных по переданному набору имя-значение выглядит так:

let subst_vars smap code = 
  let o = object 
      inherit mapper as super 
      method map_lvalue = function 
        | Var name as x -> (try M.find name smap with Not_found -> x) 
        | something_else -> super#map_lvalue something_else 
    end  
  in o#map_code code

Тут создается объект неназванного типа, унаследованного от класса mapper, в нем переопределен один метод, а в нем фактически переопределен только один вариант АТД, все остальное делает базовый класс, рекурсивно проходя по всем закоулкам и вариантам дерева. Это можно еще упростить. Например, для трансформации стейтментов была добавлена такая функция:

let subst_code_by_stmt f code =  
  let o = object 
      inherit mapper as super 
      method map_stmt st =  
        match f st with Some st' -> st' | None -> super#map_stmt st 
    end  
  in o#map_code code

Использование которой для совершения конкретной трансформации сводится вообще к одной строчке:

C.subst_code_by_stmt (function C.Print x -> Some(C.Prchar x) | _ -> None) code

Кажется, без ООП так просто не получилось бы.

Comments

Re: +1

[thedeemon.livejournal.com]

>параметрического полиморфизма достаточно

Каким образом? В дереве сидят значения (поддеревья) разных типов, какой тип должен быть у аргумента map? Какой тип должен быть у самой map?

Re: +1

[nealar.livejournal.com]

Тип у дерева какой? Я в этом коде не нашёл.

Re: +1

[gds.livejournal.com]

типы разные у разных кусков дерева (map_code кушает список элементов, которые могут быть обработаны map_stmt, а map_stmt кушает некоторый индуктивный тип данных). Благодаря объектам нет нужды выписывать тип, а компилятор знает тип через type inference. У любителей ФП это модно.

Re: +1

[thedeemon.livejournal.com]

Примерно такой:

type name = string 
type code = statement list 
and statement =  
  | DefVar of name 
  | Assign of lvalue * rvalue 
  | Call of name * rvalue list 
  | Ret of rvalue list 
  | If of condition * code * code 
  | Print of rvalue 
  | Comp of code 
  | Break 
  ... 
 
and lvalue = Var of name | PVar of name  | PArith of oper * lvalue * rvalue 
 
and rvalue = 
  | Val of int 
  | LV of lvalue 
  | Arith of oper * rvalue * rvalue 
  | FCall of name * rvalue list 
  | Byte of rvalue 
 
and condition =  
  | Less of rvalue * rvalue 
  | Eq of rvalue * rvalue 
  | And of condition * condition 
  | Or of condition * condition 
  | Not of condition