1. Variables reference, coding, visibility

2. Rules for making names  permitted character set  maximum length, significant length  case sensitivity  special words: keywords or reserved  predefined names  association with data and processes What features influence readability and writability?

3. Variables – data representation  high level version of memory reference  more general and useful model of memory  six attributes: name and address, type and value, scope and lifetime What features influence readability and writability? name address type value scope lifetime

4. Attributes of variables nameaddress typevalue lifetime scope name address type value scope lifetime

5. D Goforth COSC 31275 Address - memory location  Actual location of data, low level  name-address relations may be one to one one to many: e.g., same name used for different variables in different methods many to one (alias): e.g.: formal parameter in method call refers to same object as actual parameter name address type value scope lifetime

6. D Goforth COSC 31276 Type: code and range  Simple (primitive) types: bit code for storage  Composite types: subtypes and organization Type determines:  range of possible values  operations on values name address type value scope lifetime

7. D Goforth COSC 31277 Values  Actual sequence of bits as interpreted by codes and organization  Abstract memory cell - memory space for a value without considering inside structure e.g., double ‘cell’ is 8 bytes in java e.g., object manipulation name address type value scope lifetime

8. D Goforth COSC 31278 Values  Implementation - inside view  Application - abstract view some languages allow inside view of simple data types e.g.: C has bit level operations name address type value scope lifetime

9. D Goforth COSC 31279 Binding - setting attributes of entities  E.g. a variable (entity) has six attributes that must be bound to it. x = 6.0; // binds value to variable with name x  All entities of a programming language have attributes: data types, operators, keywords, programs, etc. name address type value scope lifetime

10. D Goforth COSC 312710 Binding Time  Time when binding of attributes occurs is a major distinguishing feature of languages Binding Time Line: Language Design Language Implementation Program Coding Program Compile Program Execution name address type value scope lifetime

11. D Goforth COSC 312711 Binding to variables  Static - before execution  Dynamic - (before and) during execution java e.g.: value int mVal = 0; final double yearLength = 365.248; mVal = 1000;  What about other attributes? name address type value scope lifetime

12. D Goforth COSC 312712 Binding type to a variable when how ExplicitImplicit Static Dynamic X name address type value scope lifetime

13. D Goforth COSC 312713 User-defined types Simple types  enumerated e.g. in pascal: type suittype = (spade, heart, diamond, club); var trump suittype; trump := diamond;  subrange e.g. in Ada: subtype DAY_OF_MONTH is INTEGER range 1..31; START_DATE: DAY_OF_MONTH ; name address type value scope lifetime

14. D Goforth COSC 312714 User-defined types Compound types  anonymous types  named types e.g. in Ada: type YEAR_LIST is array (1..366) of INTEGER; A, B: YEAR_LIST; C: array (1..366) of INTEGER; D: array (1..366) of INTEGER; name address type value scope lifetime

15. D Goforth COSC 312715 User-defined types in java Compound types  anonymous types  named types e.g. in Ada: type YEAR_LIST is array (1..366) of INTEGER; A, B: YEAR_LIST; C: array (1..366) of INTEGER; D: array (1..366) of INTEGER; name address type value scope lifetime

16. Dynamic typing  variable gets type from value assigned to it  type can change during execution  expensive in performance – tracking type  e.g. APL, LISP name address type value scope lifetime

17. Storage (address) binding  static allocation: variable is associated with one address for entire program – efficient but inflexible (e.g., no recursion, waste space)  e.g., java class variables  dynamic allocation: memory allocated when declaration executed

18. Stack-dynamic memory  allocations for a called procedure are ‘stacked’ on allocations for calling procedure  lifetime: proc execution allocation for main:x,y,z allocation for a: w,t,x allocation for b: x,e,d procedure main { int x=0,y=1,z=2 a(x) } procedure a(int w) { int t=3,x=4 b(t) } procedure b(int d) { int e,x=5 e = d + x + t + y }

19. Heap-dynamic storage  explicit: heap of memory is allocated on specific request: pointers (c) and references (java) lifetime: till deallocation(c) or gc(java)  implicit: with dynamic typing lifetime: till variable retyped

20. Type checking-compatibility of types in an operation e.g.: assignment, expressions, procedure calls: Type error: expected type and actual type don’t match Coercion: legitimate change of actual variable to expected type e.g.: 4 * 5.6double y = 100; String s = “max: ” + y;int x = 3.2;

21. Strong typing  all type errors are detected - reliability Question: java is strongly typed: can type checking be done at compile time??

22. Strong typing Question: java is strongly typed: can type checking be done at compile time?? NO: some variables can contain different types – must check at run time e.g. Object obj; // can reference object from any class

23. Type compatibility For user defined simple types: type date = 1..31; var birthday: date; count: integer;... count := birthday; Pascal: type error - name type compatibility (OK with structure type compatibility) C?

24. Scope  Range of accessibility of variable  scope in object-oriented languages is distinct and sometimes tricky (chapter 12)  scope in imperative (procedural) languages depends mostly on procedures

25. Scope in imperative languages  Static scoping - visibility depends on structure of source code file determined at compile time  Dynamic scoping - visibility depends on procedure calls determined at execution time

26. Scope definitions – imperative languages  block – bounded part of a program – e.g., procedure  scope – range of visibility of an identifier, e.g., variable name  local scope – block where identifier is delcared  non-local scope – other blocks where identifer is visible

27. Typical imperative program program A type f,g,h var x,y,z procedure B var v,x begin... end begin... end A B C D E F

28. Static Scoping  scopes nested according to file structure – determined at compile  what identifiers are visible from a scope?  which variable for multiply-defined identifier is visible?

29. Static example: pascal  sample of code sample of code  visible variables at each block  visible procedures at each block  partial scope and forward reference

30. Static scope impedes information hiding  unintended access to variables and procedures is hard to prevent – nesting scopes partial solution: flat procedure hierarchy (c)

31. Dynamic scope – stack dynamic variables  Non-local scopes based on procedure calls  procedure may have different scopes each time it is executed

32. Dynamic example: “pseudopascal”  sample of code sample of code  visible variables at each block  visible procedures at each block  partial scope and forward reference

33. Dynamic scope  all local variables visible during execution  difficult to read programs – must know calling order partial solution: use static scoping and get ‘dynamic’ power by parameter passing