What Lies Under The Syntax Sugar

What Lies Under The Syntax Sugar

Presentation given at the October 2017 WebDevTalks Meetup.

In this talk I explore the similarities and differences in the implementations of the 3 programming languages that I use the most these days: Objective-C, Swift and Elixir.

This talk is a deep dive into what goes behind the scenes when code is compiled.

3bb2abb35d54dfe7c3179cb2d7c049e7?s=128

Oscar Swanros

October 25, 2017
Tweet

Transcript

  1. W H AT L I E S U N D

    E R T H E S Y N TA X S U G A R W D T O C T O B E R
  2. Oscar Swanros Sr. iOS Software Engineer @ CloudApp oscar@swanros.com @Swanros

    W H O A M I
  3. P R O G R A M M I N

    G L A N G U A G E S
  4. None
  5. None
  6. None
  7. Compiled Open source Widespread use Fun to write Completely different

    approaches
  8. Compiled Open source Dynamic Statically checked at compile time Runs

    on the BEAM
  9. None
  10. Compiled Open source Dynamic Statically checked at compile time Runs

    on Linux, macOS, iOS, watchOS, tvOS, Raspberry Pi, Android, etc etc et
  11. None
  12. Compiled Open source SUPER Dynamic The compiler tries to catch

    many things Runs wherever C code runs*
  13. None
  14. None
  15. R U N T I M E

  16. [object doSomething]; objc_msgSend(object, doSomething); [object doSomethingWith:@“Param”]; objc_msgSend(object, doSomething, @“Param”);

  17. id objc_msgSend(id self, SEL op, …); id: any Objective-C object

    type SEL: typedef struct objc_selector *SEL;
  18. None
  19. None
  20. None
  21. LLVM

  22. LLVM

  23. Objective-C/C++/C

  24. Objective-C/C++/C LLVM Intermediate Representation

  25. unsigned square_int(unsigned a) { return a * a } define

    i32 @square_unsigned(i32 %a) { %l = mul i32 %a, %a ret i32 %l }
  26. IR is a low-level programming language in it of itself,

    that LLVM knows how to interpret and optimize.
  27. None
  28. Objective-C is a relatively thin layer on top of C.

    Most of the actual code is still C. Swift is a completely new language, that drops the baggage of C. The whole Swift stdlib is written in Swift.
  29. None
  30. None
  31. A S T

  32. let x = 1 let y = 2 let z

    = 3 * x + y
  33. None
  34. None
  35. None
  36. S E M A ( S E M A N

    T I C A N A LY S I S )
  37. S E M A ( S E M A N

    T I C A N A LY S I S ) • Perform type checking
  38. S E M A ( S E M A N

    T I C A N A LY S I S ) • Perform type checking • Unused variables?
  39. S E M A ( S E M A N

    T I C A N A LY S I S ) • Perform type checking • Unused variables? • Check for unreachable code
  40. S E M A ( S E M A N

    T I C A N A LY S I S ) • Perform type checking • Unused variables? • Check for unreachable code • Overflow checks
  41. S I L G E N / S I L

    (Swift intermediate Language)
  42. None
  43. None
  44. S I L • Represents program semantics • Is suitable

    as a base for code generation and further analysis/optimizations • Bridges Swift sources and LLVM.
  45. None
  46. B U I LT I N S • Builtins represent

    types and operations below Swift, at LLVM level. • Swift stlib implements interfaces on top of Builtins for ease of use. • Great for portability. Swift only cares about Int, the LLVM backend defines what an Int actually is.
  47. A F T E R S I L G E

    N • SIL is further analyzed, optimized. • LLVM IR is generated. • IR is passed to the swiftc LLVM backend to generate executables.
  48. E L I X I R ?

  49. With Swift/Objective-C

  50. Once compilation starts, there’s no turning back. With Swift/Objective-C

  51. Once compilation starts, there’s no turning back. AST is not

    accessible to the program. With Swift/Objective-C
  52. E L I X I R I S D I

    F F E R E N T
  53. 9 9 % O F E L I X I

    R I S B U I LT I N E L I X I R
  54. None
  55. W H Y I S T H I S G

    O O D ? • The language only has to comply with a very small list of characteristics. • As long as the general structure of the language remains, changes can occur rather rapidly. • Elixir is some sort of Erlang DSL (but not quite).
  56. E L I X I R C O M P

    I L AT I O N • Read file • Tokens • Parse, build initial AST • Expand macros • Apply rewrite rules • Lower Elixir AST to Erlang AST • Pass to Erlang compiler…
  57. E R L A N G C O M P

    I L AT I O N • Compile Erlang AST to Core AST • Core optimization and inlining • Pattern matching • Optimize kernel • Generate ASM • Optimize ASM • Generate Bytecode • Write .beam
  58. • Flexible at compile time • Efficient • A really

    nice syntax for a rather powerful underlying
 engine • Distributed by nature
  59. • Flexible at compile time • Compiles really quickly (because

    the compiler can 
 only do so much). • Cumbersome syntax • Super powerful runtime
  60. • Really strict at compile time, misuse of language 


    features results in compile errors. • Compilation is really slow, but final program is way
 safer in terms of memory management • Familiar syntax • The amount of optimizations that go into compiling
 Swift, make it really fast.
  61. TA K E A WAY S • A language is

    much more than just its syntax • The foundation and background of each language is important • Knowing where they break give you superpowers • Knowing how to break them give you really good insights • Is really fun to work with compilers
  62. T H A N K S !

  63. Q U E S T I O N S ?

    O S C A R @ S WA N R O S . C O M