Code generation in Erlang

1,464 views
1,353 views

Published on

How to use code generation for creation of right parser

Published in: Technology
0 Comments
1 Like
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
1,464
On SlideShare
0
From Embeds
0
Number of Embeds
2
Actions
Shares
0
Downloads
8
Comments
0
Likes
1
Embeds 0
No embeds

No notes for slide
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • \n
  • Code generation in Erlang

    1. 1. Code generationfor enterprise integration Max Lapshin max@maxidoors.ru
    2. 2. FIX protocol• Automated stock exchange trading• Binary protocol for receiving quotes and sending orders• No opensource erlang implementation
    3. 3. FIX protocol• Packet is a Key,Value list.• Keys are ASCII-coded integers• Values may vary• Separated with 0x01 byte
    4. 4. FIX protocol• Binary protocol with three levels: transport (TCP), packet and business• All business logic is described in protocol spec• Different message types with many fields and groups of fields• Very large protocol specification (about 100 different messages)• 10 us limit for all parsing
    5. 5. FIX protocol• Received data is decoded to proplists• But we use records in code• How to translate? And do it fast!
    6. 6. FIX protocol• Large XML description how to compose objects from proplists• XML describes syntax and semantic levels
    7. 7. Problem• Every FIX user needs only small subset of whole spec• Impossible to work with full FIX records (more than 100 fields)• My code works with my records and business logic• How to fight impedance between our logic and FIX business logic?
    8. 8. Ways to go• Enterprise• Ad-hoc• Controlled code generation
    9. 9. Enterprise way• Object with 100 fields and 300 methods is ok• It is Java: abstract singleton factory will make you happy• Copy-pasted glue code will translate full spec to required subset• Impossible to use because large size of records• Not my way
    10. 10. Ad-hoc• Write custom code for each message type• Workaround for broker’s bugs• Ok for some situations• Not my way: I’m too lazy to copy-paste code by hands
    11. 11. Right way• Autogenerate proplists-to-record translator• Make code reuseable for others• Design system, that can fit into other businesses• Don’t want to write glue code• I chose configurable code generation
    12. 12. Code generation• Parse XML• Reduce messages according to config file• Generate headers• Generate parsers• Profit!
    13. 13. Headers• Translate only required FIX messages to records• Include only required fields in these records• Always include “fields” field to each record for remaining data• Dialyzer-compatible: types are known at generate time
    14. 14. ExampleNewOrderSingle message with 60 fields is translated to#new_order_single{} with 6 fields
    15. 15. Syntax parser• Translate binary fields to erlang types and back• Don’t forget sugar: translate 0,1,2 to atoms buy, sell, make_gift• Doesn’t depend on config• Generate C extension (blazing fast)• Produces readable proplist (not hash!): ordered key-value list
    16. 16. Semantic parser• Translates proplists to records• Need to produce records, directly used in business logic• Can loose some not important information (checksum)• Need to handle groups of fields (most cryptic part)• It is generated with config• Yet have some limited ad-hoc code to keep flexibility
    17. 17. Structure of semantic parser1. Determine type of message and use compile time record info2. Process the rest of proplist3. If key is a known record field, write it to record4. Else append this {Key,Value} to “fields” field5. Use “setelement” and generated “field_index(MsgType,KeyName)”
    18. 18. Results• Simple and useable code• FIX datatypes are used in business logic directly• Configurable autogeneration of parser is really helpful• Working code
    19. 19. Questions? Max Lapshin max@maxidoors.ru

    ×