[lnkForumImage]
TotalShareware - Download Free Software

Confronta i prezzi di migliaia di prodotti.
Asp Forum
 Home | Login | Register | Search 


 

Forums >

comp.lang.lisp

ML-like type system

Jim Newton

3/16/2016 9:58:00 AM

Does someone who understands lisp and also ML have a way to explain this,
or else to help clear up my confusion?

I'm reading the book:
Types and Programming Languages by Benjamin C. Pierce.

The author explains type systems starting untyped lambda calculus
and gradually adding more and more capabilities to be able to describe
semantics of lots of language features found in ML, OCaml, Java, and others.

Coming from a lisp background some of the concepts are hard to understand,
and one gripe I have about this particular book, is that the author sometimes
states (and proves) some remarkable claims without giving examples.

One such concept he explains are called "meets" and "joins" of types,
which seem very similar intersections and union types. The join of A and B
seems to be the particular union of A and B which is a subtype of any other
union of A and B... sort of the least union. Analogously the meet of A and B
seems to be the intersection of A and B which is a super-type of every other
intersection.

I have trouble mapping this to my understanding of types from common lisp.

If someone can help me understand, it would be great. Thanks.

6 Answers

Kaz Kylheku

3/16/2016 3:31:00 PM

0

On 2016-03-16, Jim Newton <jimka.issy@gmail.com> wrote:
> Coming from a lisp background some of the concepts are hard to understand,
> and one gripe I have about this particular book, is that the author sometimes
> states (and proves) some remarkable claims without giving examples.
>
> One such concept he explains are called "meets" and "joins" of types,
> which seem very similar intersections and union types. The join of A and B
> seems to be the particular union of A and B which is a subtype of any other
> union of A and B... sort of the least union.

Given a set A and B, the union of A and B is unique; there do not exist
two or more distinct unions. If U is a union of A and B, and V is a union
of A and B, then U and V refer to the same set.

Your paraphrase of whatever concept appears in the book indeed doesn't
make sense.

(Some union-like combination of A and B which is less than the union
should be describable in terms of elementary set operations: regular
union, intersection and difference.)

Jim Newton

3/16/2016 4:55:00 PM

0

Hi Kaz, thanks. My understanding is the same as yours. So certainly there is something wrong with my paraphrasing. I'll type in the paragraphs here from the book. But first a little background.
I don't know whether record types, or join/meet is "normal" terminology for functional language
or whether it is something this author made up.

<: (with the :) means is a subtype of
^ means meet
v means join
{x1:T1, x2:T2 ... xn:Tn} means a record type with fields x1, x2... xn whose types are T1, T2...Tn resp.
{} is the record type with no fields.
If A and B are record types, and if each field of B is also a field of A, then A <: B
(provided the field types match). Consequently every record type is a subtype of {}
Top is the type which is a super type of all types
There is no corresponding Bot type (for reasons I don't yet completely understand)

--- Text from Book ---

Definition: A type J is called a join of a pair of types S and T, written SvT = J,
if S <: J, T <: J, and, for all types U, if S <: U and T <: U, then J <: U.
Similarly, we say that a type M is a meet of S and T, written S^T=M, if M <: S,
M <: T, and, for all types L, if L <: S and L <: T, then L <: M.

Depending on how the subtype relation in a particular language with sub-
typing is defined, it may or may not be the case that every pair of types has a
join. A given subtype relation is said to have joins if, for every S and T, there
is some J that is join of S and T. Similarly, a subtype relation is said to have
meets if, for every S and T, there is some M that is a meet of S and T.

The subtype relation that we are considering in this section has joins, but
not meets. For example, the types {} and Top->Top do not have any common
subtypes at all, so they certainly have no greatest one. However, a slightly
weaker property does hold. A pair of types S and T is said to be bounded
below if there is some type L such that L <: S and L <: T. A given subtype
relation is said to have bounded meets if, for every S and T such that S and T
are bounded below, there is some M that is a meet of S and T.

Stefan Monnier

3/16/2016 6:02:00 PM

0

>> One such concept he explains are called "meets" and "joins" of types,
>> which seem very similar intersections and union types. The join of A and B
>> seems to be the particular union of A and B which is a subtype of any other
>> union of A and B... sort of the least union.

> Given a set A and B, the union of A and B is unique; there do not exist
> two or more distinct unions. If U is a union of A and B, and V is a union
> of A and B, then U and V refer to the same set.

IIUC the difference is that in Pierce's context types aren't just sets,
they are more like descriptions of sets. So the "join" of A and
B is a type that describes the set that is the union of the set
described by A and the set described by B.

It may be the case that there is no way in the type language to
describe that set. And it may be the case that there are several ways
to describe that set.

And this is all because, "union" and "intersection" do not necessarily
exist in the type language.


Stefan

Helmut Eller

3/16/2016 6:20:00 PM

0

On Wed, Mar 16 2016, Jim Newton wrote:

> One such concept he explains are called "meets" and "joins" of types,
> which seem very similar intersections and union types. The join of A and B
> seems to be the particular union of A and B which is a subtype of any other
> union of A and B... sort of the least union. Analogously the meet of A and B
> seems to be the intersection of A and B which is a super-type of every other
> intersection.

"meet" and "join" are usually operations on a "type lattice" [1, 2]. I
think "least-upper-bound" and "greatest-lower-bound" are perfectly good
synonyms for meet and join and make more sense to me.

What the type lattice is, is fairly obvious for statically typed
languages (e.g. read the "Subtyping" section of the Java Language Spec),
but for Common Lisp it's not so clear. I guess one way to define a
lattice would use subtypep. A problem with that is that subtypep itself
is not that well defined and de-facto implementation dependent (it also
doesn't work for values types and says very little about function
types).

There are other possibilities to define a lattice for Common Lisp types,
e.g. Henry Baker describes one[3]. He is more interested in finding
efficient representations for values (opportunities for unboxing and
such) than to find the static type defined by the language spec (which
the Common Lisp Spec doesn't define or at least not very well).

Helmut

[1]https://en.wikipedia.org/wiki/Joi...
[2]https://en.wikipedia.org/wik...(order)
[3]http://www.pipeline.com/~hbaker1/TInfe...

Paul Rubin

3/17/2016 6:11:00 AM

0

Jim Newton <jimka.issy@gmail.com> writes:
> I don't know whether record types, or join/meet is "normal"
> terminology for functional language

I'm no expert but I think subtypes in general haven't fit in well with
functional programming based on typed lambda calculus. It's seen to
some extent as an OOP thing. Haskell favors bounded polymorphism
instead, and Ocaml may now have something like that too.

You might like Harper's book Practical Foundations of Programming
Languages: http://www.cs.cmu.edu/~rwh/plboo...

M. Strobel

3/17/2016 1:53:00 PM

0

On 16.03.2016 10:57, Jim Newton wrote:
> Does someone who understands lisp and also ML have a way to explain this,
> or else to help clear up my confusion?
>
> I'm reading the book:
> Types and Programming Languages by Benjamin C. Pierce.
>
> The author explains type systems starting untyped lambda calculus
> and gradually adding more and more capabilities to be able to describe
> semantics of lots of language features found in ML, OCaml, Java, and others.
>
> Coming from a lisp background some of the concepts are hard to understand,
> and one gripe I have about this particular book, is that the author sometimes
> states (and proves) some remarkable claims without giving examples.
>
> One such concept he explains are called "meets" and "joins" of types,
> which seem very similar intersections and union types. The join of A and B
> seems to be the particular union of A and B which is a subtype of any other
> union of A and B... sort of the least union. Analogously the meet of A and B
> seems to be the intersection of A and B which is a super-type of every other
> intersection.
>
> I have trouble mapping this to my understanding of types from common lisp.
>
> If someone can help me understand, it would be great. Thanks.
>

_IMO_ you can't understand it with Lisp background, because precisely the
type system is not present in Lisp.

Pierce uses the ML type system right away to start basics in formal proofs.

When you get to the point where he starts constructing natural numbers,
starting with O (witten as letter, meaning zero), and building successors of O,
meaning 1, 2, .. and you are asking yourself: what the ... is this??

then start reading up on
intuitionistic logic,
Martin Löf type system,
"Propositions as types" by Phil Wadler,
Hindley, Milner, of course
programming with dependent types,
Generalized Algebraic Data Types (GADTs),

then start programming in a stricly typed language like Haskell or OCaml (Coq! so
rather OCaml),

then you will know what product types and sum types are, and it will be clear
that Pierce has to construct math in a way that proofs will be "operable", or
"machinery" (my terms).

Or something along these lines...

BTW, Dierk König (creator of Frege, a Haskell on JVM) says on youtube "it is
rather save to say that you need a PhD in Informatics to work with Coq or Isabelle".
Anyway, enjoy discovering new ideas.

Max