Docsity
Log inSign up
Docsity
Prepare for your exams
Prepare for your exams

Study with the several resources on Docsity

Earn points to download
Earn points to download

Earn points by helping other students or get them with a premium plan

Guidelines and tips
Guidelines and tips
Sell on Docsity
Sell on Docsity
Docsity AI
Docsity AI
Log inSign up

Prepare for your exams

Study with the several resources on Docsity

Find documents

Prepare for your exams with the study notes shared by other students like you on Docsity

Search for your university

Find the specific documents for your university's exams

Docsity AINEW

Summarize your documents, ask them questions, convert them into quizzes and concept maps

Explore questions

Clear up your doubts by reading the answers to questions asked by your fellow students

Earn points to download

Earn points by helping other students or get them with a premium plan

Share documents
download point icon20 Points

For each uploaded document

Answer questions
download point icon5 Points

For each given answer (max 1 per day)

All the ways to get free points
Get points immediately

Choose a premium plan with all the points you need

Study Opportunities

Choose your next study program

Get in touch with the best universities in the world. Search through thousands of universities and official partners

Community

Ask the community

Ask the community for help and clear up your study doubts

Free resources

Our save-the-student-ebooks!

Download our free guides on studying techniques, anxiety management strategies, and thesis advice from Docsity tutors

Programming Languages: Syntax, Semantics, and Comparison, Study notes of Programming Languages

University of MarylandProgramming Languages

An overview of programming languages, focusing on their syntax and semantics. Topics include regular expressions, context-free grammars, finite automata, recursive descent parsers, implicit and explicit declarations, dynamic and static typing, functional and imperative paradigms, and more. From a computer science course (cmsc 330).

Typology: Study notes

Pre 2010

Uploaded on 02/13/2009

koofers-user-jfd
koofers-user-jfd 🇺🇸

9 documents

1 / 7

Toggle sidebar

This page cannot be seen from the preview

Don't miss anything!

bg1
1
CMSC 330: Organization of
Programming Languages
Type Systems,
Names & Binding
CMSC 330 2
Topics Covered Thus Far
Programming languages
•Ruby
•OCaml
Syntax specification
•Regular expressions
•Context free grammars
Implementation
•Finite automata (scanners)
•Recursive descent parsers
CMSC 330 3
Language Features Covered Thus Far
Ruby
•Implicit declarations { x = 1 }
•Dynamic typing { x = 1 ; x = “foo” }
OCaml
•Functional programming add 1 (add 2 3)
•Type inference let x = x+1 ( x : int )
•Higher-order functions let rec x = fun y -> x y
•Static (lexical) scoping let x = let x = …
•Parametric polymorphism let x y = y ( ‘a -> ‘a )
•Modules module foo struct … end
CMSC 330 4
Programming Languages Revisited
Characteristics
•Artificial language for precisely describing algorithms
•Used to control behavior of machine / computer
•Defined by its syntax & semantics
Syntax
•Combination of meaningful text symbols
¾Examples: if, while, let, =, ==, &&, +
Semantics
•Meaning associated with syntactic construct
¾Examples: x = 1 vs. x == 1
CMSC 330 5
Comparing Programming Languages
Syntax
•Differences usually superficial
¾C / Java if (x == 1) { … } else { … }
¾Ruby if x == 1 … else … end
¾OCaml if (x = 1) then … else …
•Can cope with differences easily with experience
¾Though may be annoying initially
•You should be able to learn new syntax quickly
¾Just keep language manual / examples handy
CMSC 330 6
Comparing Prog. Languages (cont.)
Semantics
•Differences may be major / minor / subtle
•Explaining these differences a major goal for 330
•Will be covering different features in upcoming lectures
a = ba == bOCaml
a == ba.equal?(b)Ruby
*a == *ba == bC
a.equals(b)a == bJava
Structural EqualityPhysical Equality
pf3
pf4
pf5

Partial preview of the text

Download Programming Languages: Syntax, Semantics, and Comparison and more Study notes Programming Languages in PDF only on Docsity!

CMSC 330: Organization of

Programming Languages

Type Systems,

Names & Binding

CMSC 330 2

Topics Covered Thus Far

Programming languages

  • Ruby
  • OCaml

Syntax specification

  • Regular expressions
  • Context free grammars

Implementation

  • Finite automata (scanners)
  • Recursive descent parsers

CMSC 330 3

Language Features Covered Thus Far

Ruby

  • Implicit declarations { x = 1 }
  • Dynamic typing { x = 1 ; x = “foo” }

OCaml

  • Functional programming add 1 (add 2 3)
  • Type inference let x = x+1 ( x : int )
  • Higher-order functions let rec x = fun y -> x y
  • Static (lexical) scoping let x = let x = …
  • Parametric polymorphism let x y = y ( ‘a -> ‘a )
  • Modules module foo struct … end

CMSC 330 4

Programming Languages Revisited

Characteristics

  • Artificial language for precisely describing algorithms
  • Used to control behavior of machine / computer
  • Defined by its syntax & semantics

Syntax

  • Combination of meaningful text symbols ¾ Examples: if, while, let, =, ==, &&, +

Semantics

  • Meaning associated with syntactic construct ¾ Examples: x = 1 vs. x == 1

CMSC 330 5

Comparing Programming Languages

Syntax

  • Differences usually superficial ¾ C / Java if (x == 1) { … } else { … } ¾ Ruby if x == 1 … else … end ¾ OCaml if (x = 1) then … else …
  • Can cope with differences easily with experience ¾ Though may be annoying initially
  • You should be able to learn new syntax quickly ¾ Just keep language manual / examples handy

CMSC 330 6

Comparing Prog. Languages (cont.)

Semantics

  • Differences may be major / minor / subtle
  • Explaining these differences a major goal for 330
  • Will be covering different features in upcoming lectures

OCaml a == b a = b

Ruby a.equal?(b) a == b

C a == b *a == *b

Java a == b a.equals(b)

Physical Equality Structural Equality

CMSC 330 7

Programming Language Features

Paradigm

  • Functional
  • Imperative
  • Object oriented
  • Multi-paradigm

Higher-order functions

  • Closures

Declarations

  • Explicit
  • Implicit

Type system

  • Typed vs. untyped
  • Static vs. dynamic
  • Weak vs. strong (type safe)

CMSC 330 8

Programming Language Features (cont.)

Names & binding

  • Namespaces
  • Static (lexical) scopes
  • Dynamic scopes

Parameter passing

  • Call by value
  • Call by reference
  • Call by name ¾ Eager vs. lazy evaluation

Polymorphism

  • Ad-hoc ¾ Subtype ¾ Overloading
  • Parametric ¾ Generics

Parallelism

  • Multithreading
  • Message passing

CMSC 330 9

Explicit vs. Implicit Declarations

Explicit declarations

  • Variables must be declared before used
  • Examples ¾ C, C++, Java, OCaml

Implicit declarations

  • Variables do not need to be declared
  • Examples ¾ Ruby

CMSC 330 10

Type System Overview

Typed vs. untyped

Static vs. dynamic

Weak vs. strong (type safe)

CMSC 330 11

Type vs. Untyped Languages

Typed language

  • Operations are only valid for specified types ¾ 2 * 3 = 6 ¾ “foo” * “bar” = undefined
  • Helps catch program errors ¾ Either at compile or run time

Untyped language

  • All operations are valid for all values
  • Treat all values as sequences of 0’s and 1’s
  • Example ¾ Assembly languages, FORTH CMSC 330 12

Static vs. Dynamic Types

Static types

  • Before program is run ¾ Type of all expressions are determined - Usually by compiler ¾ Disallowed operations cause compile-time error

Static types may be manifest or inferred

  • Manifest – specified in text (at variable declaration) ¾ C, C++, Java, C#
  • Inferred – compiler determines type based on usage ¾ ML, OCaml

CMSC 330 19

Name Restrictions

Languages often have various restrictions on

names to make lexing and parsing easier

  • Names cannot be the same as keywords in the language
  • OCaml function names must be lowercase
  • OCaml type constructor and module names must be uppercase
  • Names cannot include special characters like ; , : etc ¾ Usually names are upper- and lowercase letters, digits, and _ (where the first character can’t be a digit) ¾ Some languages also allow more symbols like! or -

CMSC 330 20

Names and Scopes

Good names are a precious commodity

  • They help document your code
  • They make it easy to remember what names correspond to what entities

We want to be able to reuse names in different,

non-overlapping regions of the code

CMSC 330 21

Names and Scopes (cont.)

A scope is the region of a program where a

binding is active

  • The same name in a different scope can refer to a different binding (refer to a different program object)

A name is in scope if it's bound to something

within the particular scope we’re referring to

CMSC 330 22

Example

i is in scope

  • in the body of w, the body of y, and after the declaration of j in z
  • but all those i’s are different

j is in scope

  • in the body of x and z

*void w(int i) { ... } void x(float j) { ... } void y(float i) { ... } void z(void) { int j; char i; ... }

CMSC 330 23

Ordering of Bindings

Languages make various choices for when

declarations of things are in scope

CMSC 330 24

Order of Bindings – OCaml

let x = e1 in e2 – x is bound to e1 in scope of e

let rec x = e1 in e2 – x is bound in e1 and in e

let x = 3 in let y = x + 3 in... ( x is in scope here ) let x = 3 + x in ... ( error, x not in scope )

let rec length = function [] -> 0 | (h::t) -> 1 + (length t) ( ok, length in scope ) in ...

CMSC 330 25

Order of Bindings – C

All declarations are in scope from the

declaration onward

int i; int j = i; / ok, i is in scope / i = 3; / also ok /

void f(...) { ... } int i; int j = j + 3; / error / f(...); / ok, f declared /

f(...); / may be error; need prototype (or oldstyle C) / void f(...) { ... } CMSC 330 26

Order of Bindings – Java

Declarations are in scope from the declaration

onward, except for methods and fields, which

are in scope throughout the class

class C { void f(){ ...g()... // OK } void g(){ ... } }

CMSC 330 27

Shadowing Names

Shadowing is rebinding a name in an inner

scope to have a different meaning

  • May or may not be allowed by the language *C int i; void f(float i) { { char i = NULL; ... } }

OCaml let g = 3;; let g x = x + 3;; Java void h(int i) { { float i; // not allowed ... } } CMSC 330 28

Namespaces

Languages have a “top-level” or outermost scope

  • Many things go in this scope; hard to control collisions

Common solution seems to be to add a hierarchy

  • OCaml: Modules ¾ List.hd, String.length, etc. ¾ open to add names into current scope
  • Java: Packages ¾ java.lang.String, java.awt.Point, etc. ¾ import to add names into current scope
  • C++: Namespaces ¾ namespace f { class g { ... } }, f::g b, etc. ¾ using namespace to add names to current scope

CMSC 330 29

Mangled Names

What happens when these names need to be

seen by other languages?

  • What if a C program wants to call a C++ method? ¾ C doesn’t know about C++’s naming conventions

For multilingual communication, names are

often mangled into some flat form

  • E.g., *class C { int f(int x, int y) { ... } } becomes symbol __ZN1C3fEPii in g++
  • E.g., native valueOf(int) in java.lang.String corresponds to the C function Java_java_lang_String_valueOf__I

CMSC 330 30

Static Scope Recall

In static scoping, a name refers to its closest

binding, going from inner to outer scope in the

program text

  • Languages like C, C++, Java, Ruby, and OCaml are statically scoped int i; { int j; { float i; j = (int) i; } }

CMSC 330 37

Nested Dynamic Scopes

Full dynamic scopes can be nested

  • Static scope relates to the program text
  • Dynamic scope relates to program execution trace Perl (the keyword local introduces dynamic scope) $l = "global"; sub A { local $l = "local"; B(); } sub B { print "$l\n"; } B(); A(); B();

global local global CMSC 330 38

Static vs. Dynamic Scope

Static scoping

  • Local understanding of function behavior
  • Know at compile-time what each name refers to
  • A little more work to implement (keep a link to the lexical nesting scope in stack frame)

Dynamic scoping

  • Can be hard to understand behavior of functions
  • Requires finding name bindings at runtime
  • Easier to implement (keep a global table of stacks of variable/value bindings)