Understanding Static Typing and Hash Tables in Language Design, Slides of Computers and Information technologies

Download Understanding Static Typing and Hash Tables in Language Design and more Slides Computers and Information technologies in PDF only on Docsity!

The Next Language

Ian Holyer

Ian Holyer

http://www.cs.bris.ac.uk/software/next/

http://www.cs.bris.ac.uk/software/next/

Aim: Next Language

●

Design a new language

Design a new language

●

Working title: "Next"

●

Why do we need a new language?

Why do we need a new language?

●

There are 2000 already (100 are "modern and OO")

●

Programming languages get more complex with age

●

They can't be simplified because of backwards

compatibility (old programs must still compile and run)

●

So old languages need to be replaced

Objectives

●

Simplicity

Simplicity

make the Next language compact and convenient

close the gap between scripting and development

●

Robustness

Robustness

eliminate pointers (anti-aliasing)

eliminate globals (anti-static)

eliminate constructors, inheritance

automate defensive copying and immutability

add lending, outer environments, delegation

Finding simplicity

●

Development languages aren't simple

Development languages aren't simple

languages started out a bit complex and verbose

e.g. Java (1995) was built on old complex ideas

features get bolted on

Java's platform independence causes problems

extensive standard libraries grow slowly

●

Scripting languages aren't robust

Scripting languages aren't robust

can't build bullet-proof classes

●

Where do we look for inspiration?

Where do we look for inspiration?

Objective: Close the Gap

●

Is there any really good reason for the sharp divide

Is there any really good reason for the sharp divide

between scripting and development languages?

between scripting and development languages?

●

Maybe not, maybe it is time to close the gap and design

Maybe not, maybe it is time to close the gap and design

a language with the best of both worlds

a language with the best of both worlds

●

People who argue for scripting languages say that

People who argue for scripting languages say that

robustness comes from

robustness comes from unit testing

unit testing , which you can do

, which you can do

equally well in either language

equally well in either language

●

But

But

bullet-proof units

bullet-proof units

form a complementary issue

form a complementary issue

which can't be tested

which can't be tested

●

Let's try for both

Let's try for both

●

We should steal ideas from Java, JavaScript, JavaFX

We should steal ideas from Java, JavaScript, JavaFX

Script, ActionScript, Python, Ruby, Groovy, Go, ...

Script, ActionScript, Python, Ruby, Groovy, Go, ...

Semicolons and Curly Brackets

●

Java insists on them, Python insists on indenting instead

Java insists on them, Python insists on indenting instead

●

Haskell allows both, but is strongly biased to indenting

Haskell allows both, but is strongly biased to indenting

●

Feelings run too strong to decide between them

Feelings run too strong to decide between them

●

The issues are continuation lines and inner blocks

The issues are continuation lines and inner blocks

Block examples

Use curly brackets, or indenting if there aren't any

Use curly brackets, or indenting if there aren't any

if (n==0) { n++ } curlies still OK

if (n==0) n++ one-line block still OK

if n==0 { n++ } round brackets unnecessary

if n==0 curlies continue the block

{...}

if n==0 curly brackets added

n++

next() block ends (indenting stops)

Other Low Level Simplifications

●

Handle octal (obsolete) and hex (rare) by library calls

0xffff -> hex("ffff")

●

In string literals, eliminate octal, hex, unicode, control

characters, and any other backslash-escapes

●

Allow real newlines instead of \n

message =

"Line one

Line two

"

●

Allows the language to be used better in 'embedded

code' applications such as dynamic web pages

Types

●

Having weak types as in C is rubbish, see

Having weak types as in C is rubbish, see

http://www.viva64.com/en/a/0004/

http://www.viva64.com/en/a/0004/

●

Strong types can be

Strong types can be

●

static (all checking done at compile time)

●

dynamic (all checking done at run time)

●

Scripting languages have dynamic strong types

Scripting languages have dynamic strong types

var x ( x can hold any object)

●

There is full run-time checking, so this is

There is full run-time checking, so this is

not

not

unsafe

unsafe

●

Types should be mostly static, for 2 reasons:

Types should be mostly static, for 2 reasons:

Why we need static types (1)

●

People who like scripting languages claim that programs

People who like scripting languages claim that programs

are faster to write

are faster to write

●

It is brevity and simplicity that help with this, not the

It is brevity and simplicity that help with this, not the

loose types

loose types

●

For example, good programmers have been known to

For example, good programmers have been known to

stare at this line of JavaScript for hours without seeing

stare at this line of JavaScript for hours without seeing

why it does not work:

why it does not work:

button.onclick = action()

●

With static types, the compiler would tell you instantly

With static types, the compiler would tell you instantly

●

So static types can

So static types can increase

increase development speed

development speed

What we Really Need

●

What is it that dynamic typing in scripting languages

What is it that dynamic typing in scripting languages

really gives you that we should hold onto?

really gives you that we should hold onto?

●

Brevity: keeping code short:

Brevity: keeping code short:

we can do that with static types

●

Avoid a slow and separate compilation stage

Avoid a slow and separate compilation stage

we can do that with a fast enough implicit compiler

●

Allow either static typing or dynamic typing (using

Allow either static typing or dynamic typing (using

dispatch) with no change of notation

dispatch) with no change of notation

we can do that with dispatch built in to the language

A compromise on types

●

JavaFX, go, Haskell use type inference

JavaFX, go, Haskell use type inference

●

That means you can often write

That means you can often write

var x = expression

●

and the compiler will work out the type from context

and the compiler will work out the type from context

●

For example:

For example:

for (var x : stringArray) ...

●

The variable

The variable

x

x

clearly should have type

clearly should have type

String

String

How do you make code bullet-proof?

●

Start with a bit of code|:

Start with a bit of code|:

int n = 0

count() { n++ }

get() { return n }

int n = 0

count() { n++ }

get() { return n }

●

To make it bullet-proof would mean, for example, to

To make it bullet-proof would mean, for example, to

guarantee

guarantee

that counter

that counter

n

n

can

can

never

never

be negative

be negative

Encapsulate

●

Put the data and code in a file and give it a class name

Put the data and code in a file and give it a class name

●

Make the data private

Make the data private

class Counter

{

private int n = 0;

void count() { n++; }

int get() { return n; }

}

class Counter

{

private int n = 0;

void count() { n++; }

int get() { return n; }

}

Counter.java

●

Now you can create lots of objects from the same code,

Now you can create lots of objects from the same code,

and the class is bullet-proof, e.g.

and the class is bullet-proof, e.g. n

n

can never go negative

can never go negative