Nabble - Epigram

A Text editor for Epigram

2008-09-22T10:20:49Z

Dear all,

As a result of my experiences trying to use Epigram, I would like to
have a go at writing nicer editor for Epigram programming. I am
currently studying the "View from the Left" papers and wondered what
other sources one might consult?

Cheers,
Eric Macalay.

CFP: Dependently Typed Programming (FI Special Issue)

2008-06-30T03:47:22Z

Hi,

Tarmo and I are editing a special issue on dependently typed
programming and it would be nice to have papers on Epigram (either on
the system and its implementation or on applications). So please get
writing...

It would help with our planning if you could let us know in advance
whether you plan to submit a paper (let's say end by end of July).

Cheers,
Thorsten & Tarmo

Call for Papers:

Special Issue of Fundamenta Informaticae
(http://fi.mimuw.edu.pl/)
Dependently Typed Programming
(http://sneezy.cs.nott.ac.uk/darcs/DTP08/journal.html)

Editors:
Thorsten Altenkirch (Nottingham)
Tarmo Uustalu (Tallinn)

Dependently typed programming is using the power of dependent types to
capture relationships between data, internalising invariants necessary
for appropriate computation. When data describe types, we can express
patterns of programming in code. To capture this potential a number of
languages have been proposed and implemented which incorporate some
aspects of dependent types, e.g. Agda, ATS, Cayenne, Coq's CIC,
Concoqtion, DML, Delphin, ELF, Epigram, Omega, OpTT, Pie, PiSigma,
Ynot for
a non-exhaustive list.

Within the European TYPES project we have organized two workshops to
discuss aspects of dependently programming:

- EffTT, Workshop on Effects and Type Theory
http://cs.ioc.ee/efftt/
Tallinn, Estonia, December 2007

- DTP08, Dependently Typed Programming 2008
http://sneezy.cs.nott.ac.uk/darcs/DTP08/
Nottingham, UK, February 2008

The special issue is motivated by the desire to give people who have
presented their ideas at those workshops the opportunity to publish
papers on their work. However, we would like to invite everybody
working in this area to submit papers to the special issue. For a more
complete list of topics, please consult the workshop pages following
the links above.

The paper should follow the usual standards of journal papers, and
should be submitted by email (preferable pdf) to one of the editors
before 1 October 2008. We expect that the papers don't exceed 20 pages
(see the FI webpage for style files). We hope to be able to stick to
the following schedule:

Deadline for submissions: 1 October 08
Notification of acceptance: 15 January 2009
Final versions due: 15 March 2009

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Re: Why does Epigram colors Branches brown?

2008-04-19T14:50:25Z

Hi Serguey,

> ( X : * ! ( X : * ; subs : List (Tup X (Bush X)) !
> data !------------! where !---------------------------------------!
> ! Bush X : * ) ! Branches subs : Bush X )
>
> Tup is a tuple, List is a list.

This is a limitation in Epigram's current treatment of data types. If
recursive occurrences of Bush occur within other types (like List or
Tup in your example), Epigram cannot tell that the data type is
strictly positive. You can find more about this in Peter Morris's
thesis:

http://www.cs.nott.ac.uk/~pwm/thesis.pdf

I'm not entirely sure what's going on in your other question regarding
implicit arguments.

In the meantime, I'd recommend you have a look at Agda:

http://appserv.cs.chalmers.se/users/ulfn/wiki/agda.php?n=Main.HomePage

At the moment, it's much better supported than Epigram and has a very
similar type theory. It can handle things like you Bush data type, for
example.

Hope this helps,

Wouter

And a question on UniqList.

2008-04-19T07:37:13Z

Why there are explicit p:So (...) in

( u : A ; us : UniqList A eq xs ; p : So (not (elem u xs eq)) !
!---------------------------------------------------------------!
! ulCons u us p : UniqList A eq (cons x xs) )

?

I, actually, tried to make it implicit, but failed. And I cannot figure why.

Why does Epigram colors Branches brown?

2008-04-19T06:25:44Z

( X : * ! ( X : * ; subs : List (Tup X (Bush X)) !
data !------------! where !---------------------------------------!
! Bush X : * ) ! Branches subs : Bush X )

Tup is a tuple, List is a list.

Equality.

2008-03-21T09:00:39Z

I have type Char = cA | cB | cC | ... | cZ.

If I decide to write charEq (a,b:Char ---- charEq a b:Bool) in
straightforward way, I will be quickly lost in details (26^2
variants).

I tried use of refl, but cannot put it properly: let (a,b:Char; _p :
Eq a b ---- charEq a b _p:Bool) and then use <= case _p does not do
any good to me.

I tried to figure out a type that represents equality in (eq a: EqX a
a) and inequality in some other constructor, but failed.

So the question is: is there any way to express equality like charEq shortly?

CFP: PLMMS 2008

2008-03-05T10:30:17Z

[Two Epigram people are already involved, let's hope for more!]

SECOND CALL FOR PAPERS

* UPDATE: Post-workshop proceedings in Journal of Automated Reasoning
* UPDATE: Invited talk by Conor McBride

Second Workshop on
Programming Languages for Mechanized Mathematics
(PLMMS 2008)

http://events.cs.bham.ac.uk/cicm08/workshops/plmms/

As part of CICM / Calculemus 2008
Birmingham, UK, 28-29 July 2008

This workshop is focused on the intersection of programming languages
(PL) and mechanized mathematics systems (MMS). The latter category
subsumes present-day computer algebra systems (CAS), interactive proof
assistants (PA), and automated theorem provers (ATP), all heading
towards fully integrated mechanized mathematical assistants that are
expected to emerge eventually (cf. the objective of Calculemus).

The two subjects of PL and MMS meet in the following topics, which are
of particular interest to this workshop:

* Dedicated input languages for MMS: covers all aspects of languages
intended for the user to deploy or extend the system, both
algorithmic and declarative ones. Typical examples are tactic
definition languages such as Ltac in Coq, mathematical proof
languages as in Mizar or Isar, or specialized programming
languages built into CA systems. Of particular interest are the
semantics of those languages, especially when current ones are
untyped.

* Mathematical modeling languages used for programming: covers the
relation of logical descriptions vs. algorithmic content. For
instance the logic of ACL2 extends a version of Lisp, that of Coq
is close to Haskell, and some portions of HOL are similar to ML
and Haskell, while Maple tries to do both simultaneously. Such
mathematical languages offer rich specification capabilities,
which are rarely available in regular programming languages. How
can programming benefit from mathematical concepts, without
limiting mathematics to the computational worldview?

* Programming languages with mathematical specifications: covers
advanced "mathematical" concepts in programming languages that
improve the expressive power of functional specifications, type
systems, module systems etc. Programming languages with dependent
types are of particular interest here, as is intentionality vs
extensionality.

* Language elements for program verification: covers specific means
built into a language to facilitate correctness proofs using MMS.
For example, logical annotations within programs may be turned
into verification conditions to be solved in a proof assistant
eventually. How need MMS and PL to be improved to make this work
conveniently and in a mathematically appealing way?

These issues have a very colorful history. Many PL innovations first
appeared in either CA or proof systems first, before migrating into
more mainstream programming languages. Some examples include type
inference, dependent types, generics, term-rewriting, first-class
types, first-class expressions, first-class modules, code extraction
etc. However, such innovations were never aggressively pursued by
builders of MMS, but often reconstructed by programming language
researchers. This workshop is an opportunity to present the latest
innovations in MMS design that may be relevant to future programming
languages, or conversely novel PL principles that improve upon
implementation and deployment of MMS.

We also want to critically examine what has worked, and what has not.
Why are all the languages of mainstream CA systems untyped? Why are the
(strongly typed) proof assistants so much harder to use than a typical
CAS? What forms of polymorphism exist in mathematics? What forms of
dependent types may be used in mathematical modeling? How can MMS
regain the upper hand on issues of "genericity" and "modularity"? What
are the biggest barriers to using a more mainstream language as a host
language for a CAS or PA/ATP?

Invited Talk
------------

Conor McBride (Alta Systems, Northern Ireland) will give an invited
talk.

Submission
----------

Submission works through EasyChair
http://www.easychair.org/conferences/?conf=plmms2008

Two kinds of papers will be considered:

* Full research papers may be up to 12 pages long. Authors of
accepted papers are expected to present their work on the workshop
in a regular talk.

* Position papers may be up to 4 pages long. The workshop
presentation of accepted position papers consists of two parts: a
stimulating statement of certain issues or challenges by the
author, followed by a discussion in the plenum.

Papers should use the usual ENTCS style http://www.entcs.org/prelim.html
(11 point version), and will be reviewed by the program
committee. Informal workshop proceedings will be circulated as a
technical report.

Moreover there will be post-workshop proceedings of improved research
papers, or position papers that have been completed into full papers,
to appear in a special issue of the Journal of Automated Reasoning.
There will be a separate submission and review phase for this, where
papers from both PLMMS 2007 and 2008 will be considered.

Programme Committee
-------------------

Jacques Carette (Co-Chair) (McMaster University, Canada)
John Harrison (Intel Corporation, USA)
Hugo Herbelin (INRIA, Ecole polytechnique, France)
James McKinna (Radboud University Nijmegen, Netherlands)
Ulf Norell (Chalmers University, Sweden)
Bill Page
Christophe Raffalli (Universite de Savoie, France)
Josef Urban (Charles University, Czech Republic)
Stephen Watt (ORCCA, University of Western Ontario, Canada)
Makarius Wenzel (Co-Chair) (Technische Universitaet Muenchen, Germany)
Freek Wiedijk (Radboud University Nijmegen, Netherlands)

Important Dates
---------------

* Submission deadline - 5 May 2008
* Notification of acceptance - 6 June 2008
* Final version - 7 July 2008 (approximately)
* Workshop - 28-29 July 2008

Re: wList definition, reloaded.

2008-03-04T07:48:37Z

Hi again, (sorry about the blank reply a second ago)

You are on the right track, the correct statement of the oh2 constructor would look like this, however:

a : A
-----------------------------
oh2 a : So2 (Just a)

You can't say 'justA : (Just a)' because 'Just a' is not a type. Luckily you can do the indexing directly, as show above.

Hope this helps,

Peter

On 04/03/2008, Peter Morris <morrispwj@...> wrote:

On 04/03/2008, Serguey Zefirov <sergueyz@...> wrote:
Being not satisfied with solution I spun from thin air I decided to
reimplement it once again.

If I could invent a type So2 indexed by (Maybe a) type, I could get
the following more appropriate definitions of wNil and wCons (Haskell
style):
wNil = W Nothing notSo2
wCons a as = W (Just a) (lam p => as)

But I cannot get a type, indexed by Maybe:
     ( A : * ;  a : Maybe A !        ( a : A ;  justA : (Just a) !
data !----------------------!  where !---------------------------!
     !      So2 a : *       )        !      oh2 : So2 justA      )

Epigram colors a whole definition in light brown and (Just a) in an
even more brown color. I think it tells me that I am wrong, but I
cannot understand why.

Again.

Re: wList definition, reloaded.

2008-03-04T07:43:14Z

On 04/03/2008, Serguey Zefirov <sergueyz@...> wrote:

Being not satisfied with solution I spun from thin air I decided to
reimplement it once again.

If I could invent a type So2 indexed by (Maybe a) type, I could get
the following more appropriate definitions of wNil and wCons (Haskell
style):
wNil = W Nothing notSo2
wCons a as = W (Just a) (lam p => as)

But I cannot get a type, indexed by Maybe:
     ( A : * ;  a : Maybe A !        ( a : A ;  justA : (Just a) !
data !----------------------!  where !---------------------------!
     !      So2 a : *       )        !      oh2 : So2 justA      )

Epigram colors a whole definition in light brown and (Just a) in an
even more brown color. I think it tells me that I am wrong, but I
cannot understand why.

Again.

wList definition, reloaded.

2008-03-04T05:11:06Z

Being not satisfied with solution I spun from thin air I decided to
reimplement it once again.

If I could invent a type So2 indexed by (Maybe a) type, I could get
the following more appropriate definitions of wNil and wCons (Haskell
style):
wNil = W Nothing notSo2
wCons a as = W (Just a) (lam p => as)

But I cannot get a type, indexed by Maybe:
( A : * ; a : Maybe A ! ( a : A ; justA : (Just a) !
data !----------------------! where !---------------------------!
! So2 a : * ) ! oh2 : So2 justA )

Epigram colors a whole definition in light brown and (Just a) in an
even more brown color. I think it tells me that I am wrong, but I
cannot understand why.

Again.

wList again.

2008-03-04T00:03:40Z

(sorry for probable accidental unfinished post)

These exercises are exciting. They shift my paradigm far, far away. ;)

Did I described wList correctly now?

If so, I still cannot get construction like wCons a as => Sup true
(lam p => as). Right now it's beyond my comprehension.
------------------------------------------------------------------------------
( a : A ; b : Bool ! ( a : A !
data !-------------------! where !--------------------!
! So1 a b : * ) ! oh1 a : So1 A true )
------------------------------------------------------------------------------
( p : So1 A false !
let !-----------------!
! notSo1 p : X )

notSo1 p <= case p
------------------------------------------------------------------------------
( A : * !
let !-------------!
! wList A : * )

wList A => W Bool (So1 A)
------------------------------------------------------------------------------
( A : * !
let !----------------!
! wNil : wList A )

wNil => Sup false notSo1
------------------------------------------------------------------------------
( a : A ; as : wList A !
let !-----------------------!
! wCons a as : wList A )

wCons a as => Sup true (lam p => as)
------------------------------------------------------------------------------

wList again.

2008-03-03T23:41:14Z

These exercises are just exciting. This is the most interesting
paradigm shift I experienced in 8 years. ;)

Did I described wList
------------------------------------------------------------------------------
( a : A ; b : Bool ! ( a : A !
data !-------------------! where !--------------------!
! So1 a b : * ) ! oh1 a : So1 A true )
------------------------------------------------------------------------------
( p : So1 A false !
let !-----------------!
! notSo1 p : X )

notSo1 p <= case p
------------------------------------------------------------------------------
( A : * !
let !-------------!
! wList A : * )

wList A => W Bool (So1 A)
------------------------------------------------------------------------------
( a : A ; as : wList A !
let !-----------------------!
! wCons a as : wList A )

wCons a as => Sup true (lam p => as)
------------------------------------------------------------------------------

Re: Transpose again

2008-02-29T07:14:51Z

Hi

Mea culpa, I suspect. I haven't checked, but it looks like
you've run into one of the known bugs. It's annoying, but
there's a workaround.

The trouble is the dog that doesn't bark...

On 29 Feb 2008, at 14:16, Serguey Zefirov wrote:

> I decided to write transpose with implicit parameters. And get
> stuck, as usual.
>
> This is partial code:
> --------------------------------------------------------------------
> ( n : Nat ; m : Nat ; xys : Vec n (Vec m X) !
> let !---------------------------------------------!
> ! transpose _n _m xys : Vec m (Vec n X) )

...where does X go? Inconsistently with the notation,
Epigram is actually adding X as an implicit argument
as far left as possible. I know it looks like you're
signalling that n and m should come first and second,
but actually what happens just now is that code which
manages rules puts X first.

So, here,

>
> transpose _ n _ m xys <= rec xys
> { transpose _ n _ m xys <= case xys
> { transpose _ n _ zero vnil [<= case _n]
> transpose _ n _ (suc m) (vcons xy xys) []
> }
> }

n and m refer to the first and second arguments,
and if you look in the Horace buffer (an often
neglected source of information!) you'll probably
see an unexpected n : * which may confirm my
suspicions.

The workaround is to declare the order of arguments
explicitly. I'd write

( n ; m ; X ; xys : Vec n (Vec m X) !
let !-----------------------------------------!
! transpose _n _m xys : Vec m (Vec n X) )

Epigram will figure out the types of n, m and X
without difficulty, and it will use the order of
arguments n m X xys, with n, m and X hidden by
default at usage sites, and n and m visible
during the definition.

I'm sorry the poor thing isn't as good at guessing
as it should be, but it's not so hard just to tell
it what you want.

Hope this helps

Conor

Transpose again

2008-02-29T06:16:45Z

I decided to write transpose with implicit parameters. And get stuck, as usual.

This is partial code:
--------------------------------------------------------------------
( n : Nat ; m : Nat ; xys : Vec n (Vec m X) !
let !---------------------------------------------!
! transpose _n _m xys : Vec m (Vec n X) )

transpose _ n _ m xys <= rec xys
{ transpose _ n _ m xys <= case xys
{ transpose _ n _ zero vnil [<= case _n]
transpose _ n _ (suc m) (vcons xy xys) []
}
}
--------------------------------------------------------------------
Why "<= case xys" matches xys and m? The type of xys is clearly says
that it depends on n, then on m and matching should be done on xys and
n.

Re: Generic programming again, now exercise 3.

2008-02-27T13:15:15Z

> I've tried not to give away to much so that you can complete the exercise
> yourself, but I fear this may have caused me to be less than clear in
> places. If you find you are still lost, please don't hesite to ask more
> questions :)

I found some errors you mentioned by myself and I stopped reading with
attention when I realized that I am on the right track (yes, wNil with
parameter). Now it took me more than several seconds after the sending
mail here. ;)

I haven't had time to verify my thoughts yet but I think I know how to
do it right.

Re: Generic programming again, now exercise 3.

2008-02-27T08:33:32Z

Hi Serguey,

> When I meditated on that exercise I come to interesting conclusion.
> wNat has a "type" *, and has a value from "universe of types", W Bool
> So. Does it mean that when we declare wZero : wNat, wNat gets
> "expanded" and its' value gets substituted as the type for wZero?

No, the definition wNat contains representatives for all Natural Numbers regardless of the definitions wZero and wSuc. The point of defining these 'constructors' is simply to equip this generic encoding of Nat with the standard, Peano interface (at least when it comes to constructing natural numbers, elimination is another matter). They do not change the fact that wNat is already closed under zero and successor.

> My description of Lists follows wNat example from paper. Did I
> described Lists correctly?

Given that the 'constructors' wZero and 'wSuc' do not "expand" the definition of wNat the definition of 'wList' must be different from that of 'wNat'. You should be suspicious that the element 'a : A' appears nowhere on the right-hand side of your definition of 'wCons'. (Also I worry that your wNil constructor also takes an element of 'A', surely the empty list contains no 'A's?). Generally the 'S' in 'W S P' must contain information about the type's constructors *and* non-recursive arguments. You use 'Bool' for 'S' in the definition of 'wNat' though one could define a new type with more informative constructor names:

data NatCons : * where nczero : NatCons ; ncsuc : NatCons

The 'P' part then defines how many recursive arguments each constructor takes, 'Oh' dictates that 'false' (or 'nczero') has none, and 'true' ('ncsuc') has one. While the definition of 'wList' has a similar shape to 'wNat' one must account in the definition for the presence of an 'A' in the constructor 'wCons'.

I've tried not to give away to much so that you can complete the exercise yourself, but I fear this may have caused me to be less than clear in places. If you find you are still lost, please don't hesite to ask more questions :)

Peter

On 26/02/2008, Serguey Zefirov <sergueyz@...> wrote:

I decided to start from something lighter than BTree. I choosed a
List. This is easy because Lists are very like Nats, just a little bit
more polymorphic.

When I meditated on that exercise I come to interesting conclusion.
wNat has a "type" *, and has a value from "universe of types", W Bool
So. Does it mean that when we declare wZero : wNat, wNat gets
"expanded" and its' value gets substituted as the type for wZero?

My description of Lists follows wNat example from paper. Did I
described Lists correctly?

------------------------------------------------------------------------------
let  (----------!
     ! wNat : * )

     wNat => W Bool So
------------------------------------------------------------------------------
let  (--------------!
     ! wZero : wNat )

     wZero => Sup false notSo
------------------------------------------------------------------------------
     (   n : wNat    !
let  !---------------!
     ! wSuc n : wNat )

     wSuc n => Sup true (lam p => n)
------------------------------------------------------------------------------
     ( A : * ;  a : A !
let  !----------------!
     !  wList a : *   )

     wList a => W Bool So
------------------------------------------------------------------------------
     (      a : A       !
let  !------------------!
     ! wNil a : wList a )

     wNil a => Sup false notSo
------------------------------------------------------------------------------
     ( a : A ;  as : wList A !
let  !-----------------------!
     ! wCons a as : wList A  )

     wCons a as => Sup true (lam p => as)
------------------------------------------------------------------------------

Re: Higher-order functions.

2008-02-26T02:43:13Z

Serguey,

A reasonable question, to which you might receive several possible answers:

At the risk of duplication, or just being a bit out of date now --- the
previous go having failed as I needed to re-align my subscription
address to my new coordinates --- let me add the following observations
below.

Thanks for your continuing interest, and I hope this helps, (and perhaps
my other colleagues will leap in to correct or contradict me!)

James McKinna
Radboud University Nijmegen

Serguey Zefirov wrote:
> I hardly can find any example of higher-order functions in Epigram
> examples. I searched distribution examples and online examples.
>
> Why is that?
0) on the language and its library of examples
0a) the library, such as it is, has been focused on examples which show
off the use of indices in type families to constrain computation:
typically, these take the form of first-order data (lengths of vectors,
size bounds on trees, type names...) used for measurement

0b) incidentally, the use of 'by' notation hides a lot of
behind-the-scenes dependently-typed higher-order functions... actually,
I don't think this is (co-)incidental at all --- see 3) below

1) on higher-order functions proper
1a) standard higher-order functions such as map, fold on lists etc. are
all trivially available (and/but simply-typed!), so not much attention
has been paid to them; functions which take dependently-typed functions
as arguments are less common in nature or experience --- we are still
learning to program this way. But you could try writing the version of
"map" which takes a list of elements of A, a function f of type
(x:A)B(x) which ensures each a in A is mapped to ... something
satisfying property B, and returns a function mapping lists of As to
lists of "elementwise B(-)s". If you were to try this example, it might
throw up some interesting problems: should the result type be List
(Sigma a:A. B[a]) or something more interesting? And then how do you
write the function? Choices, choices, ...

1b) [Wouter's suggestion also includes this example] for a non-trivial
example of a dt higher-order function, look at Conor's draft paper on
closure under substitution in syntax with binders (I can probably supply
a URL if you need it); we need more examples like this: in this case,
the proofs were done years ago (by myself and Healf Goguen), and the
programs re-invented in a slightly different way, only years later...

2) on a syntactic restriction
Epigram 1's syntax for let declarations and their bodies discourages
writing functions which return functions ... e.g. Epigram 1 doesn't
allow terms of the form
lam x => case x { ...} for example: case x is an elimination operator,
so is expected to appear in a <= expression. Taking functional
arguments is no problem, though, and they can even be declared
inference-rule style...

3) more speculatively, more abstractly
You might wonder about higher-order functions in the special case of
parametric polymorphism in simply-typed languages: do they impose a
uniformity on their use/application (or the use of their h-o arguments)
which runs counter to the 'learning-by-testing' which arises in
dependently-typed case analysis? What are the right ways to capture new
kinds of such uniformities in the dependently-typed case? Again, only
examples and experience will tell us. Here example 1b above is a good
such candidate (sorry for the pun): h-o functions which carry around
functional arguments representing abstract closure conditions on the
intended source and target data. Elimination operators (0b above) are
just one very general vision of that idea: for 'methods' in elimination
operators are just 'abstract closure conditions which correspond
to/arise from patterns of data' (typically, but not necessarily, given
by constructor patterns).

Generic programming again, now exercise 3.

2008-02-25T22:39:12Z

I decided to start from something lighter than BTree. I choosed a
List. This is easy because Lists are very like Nats, just a little bit
more polymorphic.

When I meditated on that exercise I come to interesting conclusion.
wNat has a "type" *, and has a value from "universe of types", W Bool
So. Does it mean that when we declare wZero : wNat, wNat gets
"expanded" and its' value gets substituted as the type for wZero?

My description of Lists follows wNat example from paper. Did I
described Lists correctly?

------------------------------------------------------------------------------
let (----------!
! wNat : * )

wNat => W Bool So
------------------------------------------------------------------------------
let (--------------!
! wZero : wNat )

wZero => Sup false notSo
------------------------------------------------------------------------------
( n : wNat !
let !---------------!
! wSuc n : wNat )

wSuc n => Sup true (lam p => n)
------------------------------------------------------------------------------
( A : * ; a : A !
let !----------------!
! wList a : * )

wList a => W Bool So
------------------------------------------------------------------------------
( a : A !
let !------------------!
! wNil a : wList a )

wNil a => Sup false notSo
------------------------------------------------------------------------------
( a : A ; as : wList A !
let !-----------------------!
! wCons a as : wList A )

wCons a as => Sup true (lam p => as)
------------------------------------------------------------------------------

Re: transpose from Generic Programming with Dependent Types.

2008-02-25T06:30:47Z

Hi

On 22 Feb 2008, at 12:52, Serguey Zefirov wrote:

>> 0xN is an empty list
>> Nx0, the result of the transposition, is a list of N empty
>> lists. You
>> can express this (the value of N...) with vectors/dependent-
>> types, you
>> know how long it should be, so you can do this.
>>
>> does that seem right?
>
> Yes, but I don't know how to find N it through Epigram. I cannot do
> case analysis on the length of Vec.

It sometimes happens that an argument which is typically
inferrable when a function is used (hence implicit by default)
is important and needs to be seen when defining the function.
Fortunately, Epigram has a way to deal with this situation.
I'm sure we could do better, but it works.

The standard example is the function vec, which makes a vector
of copies of a given element. Typically, the desired length is
known when you use the function, so you probably want it to
be left implicit, but the vec will be defined by recursion on
the length. Here's how to start

( n ; X ; x : X !
let !--------------------! ; vec _ n x []
! vec _n x : Vec n X )

The underscore character is the "manual override" for implicit
syntax. If you use it to show n in the declaration, you will
also be shown n in the patterns of your program. When you use
this mechanism, it's a good idea to declare the order of
arguments to prevent the machine from making bad choices,
hence the "n ; X ;" premises.

Hope this helps

Conor

Re: transpose from Generic Programming with Dependent Types.

2008-02-22T04:52:56Z

> 0xN is an empty list
> Nx0, the result of the transposition, is a list of N empty lists. You
> can express this (the value of N...) with vectors/dependent-types, you
> know how long it should be, so you can do this.
>
> does that seem right?

Yes, but I don't know how to find N it through Epigram. I cannot do
case analysis on the length of Vec.

I decided to solve that troubling case alone, make transformation from
(Vec zero (Vec n X)) to (Vec n (Vec zero X)). I stumbled at the same
problem - how to extract length n of (Vec n X) from vnil of (Vec zero
(Vec n X)).

Re: transpose from Generic Programming with Dependent Types.

2008-02-21T11:11:44Z

Serguey Zefirov wrote:

> let (xys : Vec m (Vec n X) ---- transpose xys: Vec n (Vec m X))
>
> Why isn't it possible to use Haskell version of transpose as a boilerplate?
>
> transpose [] = []
> transpose ([] : xys) = transpose xys
> transpose ((x:xs):xys) = ...
>
> BTW, when I elaborating cases in Epigram, the first case of transpose
> xys is a vnil (after rec xys then case xys). And, actually, it makes
> sense to return vnil as an aswer. But Epigram colours return of vnil
> in brown.
>
>>From elaboration information in Epigram buffer I figured out that
> first vnil case is a transposition to (Vec m (Vec zero X)) and tried
> recursion on m. It gave me two cases for vnil. First vnil (Vec zero
> (Vec zero X)) can be transposed into vnil. But second vnil (for result
> type Vec (suc m) (Vec zero X)) couldn't elaborate preperly.
>
> Now I am lost for a little bit longer than in previous questions.

0xN is an empty list
Nx0, the result of the transposition, is a list of N empty lists. You
can express this (the value of N...) with vectors/dependent-types, you
know how long it should be, so you can do this.

does that seem right?

transpose from Generic Programming with Dependent Types.

2008-02-21T08:16:24Z

let (xys : Vec m (Vec n X) ---- transpose xys: Vec n (Vec m X))

Why isn't it possible to use Haskell version of transpose as a boilerplate?

transpose [] = []
transpose ([] : xys) = transpose xys
transpose ((x:xs):xys) = ...

BTW, when I elaborating cases in Epigram, the first case of transpose
xys is a vnil (after rec xys then case xys). And, actually, it makes
sense to return vnil as an aswer. But Epigram colours return of vnil
in brown.

From elaboration information in Epigram buffer I figured out that
first vnil case is a transposition to (Vec m (Vec zero X)) and tried
recursion on m. It gave me two cases for vnil. First vnil (Vec zero
(Vec zero X)) can be transposed into vnil. But second vnil (for result
type Vec (suc m) (Vec zero X)) couldn't elaborate preperly.

Now I am lost for a little bit longer than in previous questions.

Re: How to define init for vectors?

2008-02-20T14:36:35Z

> It's not known that the length of ns is a succ, so it isn't
> appropriate to
> call vecInit here. The Haskell function is exploiting fall-through
> in patterns
> here, so you should expect the Epigram version to be slightly
> noisier. So far,
> you haven't quite determined which case you're in. You will need to
> look a
> bit harder. You'll also need to indicate what you're doing recursion on.

Yes. I almost used to arriving to the answer the seconds after asking
a question.

( X : * ; xs : Vec (succ n) X !
let !------------------------------!
! vecInit xs : Vec n X )

vecInit xs <= case xs
{ vecInit (vcons n' ns) <= case ns
{ vecInit (vcons n' vnil) => vnil
vecInit (vcons n'' (vcons n' ns)) => vcons n'' (vecInit (vcons n' ns))
}
}

(indentation can be broken, I indented badly pasted version)

I'm looking for more dependent function. Now - with variable length
vector size checking!

(I almost figured out how to do it)

Re: How to define init for vectors?

2008-02-20T08:46:52Z

Hi Serguey

> And here I got stuck:
> ----------------------------------------------------------------------
> --------
> ( X : * ; xs : Vec (succ n) X !
> let !------------------------------!
> ! vecInit xs : Vec n X )
>
> vecInit xs <= case xs
> { vecInit (vcons n' ns) => vcons n' (vecInit ns)
> }
> ----------------------------------------------------------------------
> --------
> This is a version of init function from Haskell Prelude:
> init [x] = []
> init (x:xs) = x:init xs
> I do not get second case from Epigram when elaborating. And, actually,
> Epigram does not like "=> vcons n' (vecInit ns)" part. But I can
> understand that, albeit not formally.

It's not known that the length of ns is a succ, so it isn't
appropriate to
call vecInit here. The Haskell function is exploiting fall-through
in patterns
here, so you should expect the Epigram version to be slightly
noisier. So far,
you haven't quite determined which case you're in. You will need to
look a
bit harder. You'll also need to indicate what you're doing recursion on.

>
> Where should I look for hints on to get a clue on how to do it right?

The tail of the list!

All the best

Conor

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

How to define init for vectors?

2008-02-20T06:01:14Z

I try to write small familiar programs to understand dependent types
programming better (more precisely, understand it at all). All usual
maps and folds are done and I processed to more dependent ones.

That's what I managed to write:
------------------------------------------------------------------------------
( n : Nat !
data (---------! where (------------! ; !--------------!
! Nat : * ) ! zero : Nat ) ! succ n : Nat )
------------------------------------------------------------------------------
( A : * ! ( a : A !
data !-------------! where (-------------------! ; !------------------!
! Maybe A : * ) ! Nothing : Maybe A ) ! Just a : Maybe A )
------------------------------------------------------------------------------
( A : * ; B : * ! ( a : A ; b : B !
data !----------------! where !----------------------!
! Pair A B : * ) ! Tuple a b : Pair A B )
------------------------------------------------------------------------------
( n : Nat ; X : * ! ( x : X ; xs : Vec n X !
data !------------------! where (--------------! ; !-----------------------!
! Vec n X : * ) ! vnil : ! ! vcons x xs : !
! Vec zero X ) ! Vec (succ n) X )
------------------------------------------------------------------------------
let (-------------!
! width : Nat )

width => succ (succ zero)
------------------------------------------------------------------------------

And here I got stuck:
------------------------------------------------------------------------------
( X : * ; xs : Vec (succ n) X !
let !------------------------------!
! vecInit xs : Vec n X )

vecInit xs <= case xs
{ vecInit (vcons n' ns) => vcons n' (vecInit ns)
}
------------------------------------------------------------------------------
This is a version of init function from Haskell Prelude:
init [x] = []
init (x:xs) = x:init xs
I do not get second case from Epigram when elaborating. And, actually,
Epigram does not like "=> vcons n' (vecInit ns)" part. But I can
understand that, albeit not formally.

Where should I look for hints on to get a clue on how to do it right?

Re: Higher-order functions.

2008-02-14T09:59:38Z

Hi Serguey,

> I hardly can find any example of higher-order functions in Epigram
> examples. I searched distribution examples and online examples.

There are a few higher-order functions in Conor's lecture notes:

http://www.e-pig.org/downloads/epigram-notes.pdf

See Section 3.4 or the exercises of Section 4.1 for examples.

Best,

Wouter

Higher-order functions.

2008-02-14T07:08:19Z

I hardly can find any example of higher-order functions in Epigram
examples. I searched distribution examples and online examples.

Why is that?

Constant definition.

2008-02-13T05:34:11Z

Sorry, I figured it second later I hit "Send" button.

How to define a constant in Epigram?

2008-02-13T05:32:11Z

I need a "width," a length of vector to transfer between two
functions. I managed to define a list with upper bound on its' length
(ListLE n X) and I'd like to create a function that collect data in
ListLE and answers Just (Vec n X) when it collected ListLE (width) X
(and Nothing otherwise).

I cannot figure how to define it width.

[let (----width : Nat)] elaborates to seemingly proper structure, but
then I fail to figure out how to provide value for width. width [<=
succ (succ zero)] elaborates to brown expression, telling me I'm
wrong.

But I don't see how and where I am wrong.

Re: Got stuck.

2007-12-07T06:52:18Z

Hi Serguey,

I'm afraid there's no easy way we can help - both the problems you
mention are known limitations of programming with Epigram 1.

Yes - you can only undo the last change you made. There's no way to
edit code once you've hit escape. The only thing to do is copy the
entire buffer to *scratch*, make the changes you want, reset the
Epigram buffer, and try again. The same trick works if you want to
add a data constructor (although you may need to rewrite all the
functions you wrote using this data type as there is now a new
constructor).

If you want to do any serious development using Epigram, you may want
to look at Agda 2 (http://appserv.cs.chalmers.se/users/ulfn/wiki/
agda.php) instead - it's a lot more stable and better supported than
Epigram 1 is at the moment. A lot of our effort is focussed on
developing a new version of Epigram, instead of maintaining the old one.

Hope this helps,

Wouter

This message has been checked for viruses but the contents of an attachment
may still contain software viruses, which could damage your computer system:
you are advised to perform your own checks. Email communications with the
University of Nottingham may be monitored as permitted by UK legislation.

Got stuck.

2007-12-07T06:17:52Z

There are two places where I do get stuck:
1) I cannot edit any existing definitions except the very last one (by
using Undo)
2) When defining data I successfully manage to elaborate first data
constructor and then got stuck again. There is no (visible) way to
insert semicolon and elaborate remaining data constructors.

I use Epigram with XEmacs 21.4.21 under Windows.

Thank you in advance.

reactions to "Simply Easy" paper

2007-08-12T07:22:19Z

Assorted reactions I had while reading "Simply Easy! An Implementation
of a Dependently Typed Lambda Calculus" paper. (I wonder where to send
this message).

pi replaces Fun (type of function), lam stays lam (value of function).
It took me a while to figure out that that was what was going on... it
was not stated explicitly, and the relative appearances of the three
things (forall, fun and lam) did not at all clarify things (neither the
mathematical symbol forms, nor what the implementation called them). It
would be simpler though more tedious to merge values and types first (it
was said to simplify some aspects of the code after all), without
changing fun to pi

(aka becoming dependent - it's just one in which the range, instead of
sitting there on the right of the arrow, may [depend on / vary with] the
value applied to the lam being typed -- you cannot know a concrete type
of the result (the range) until you know the concrete type and then the
concrete value of the argument. Just like allowing parametric
polymorphism in Haskell: (id :: a -> a), meaning that you can only know
that the result is Bool once you know that the argument is of type bool.
The only difference with dependent types being, you also may have to
know whether the argument is True or False (which is equally well
unknown to a seperate-compilation compiler, in most cases, as the
argument's concrete type is). Combined with unifying types and values,
this means polymorphism is easy (with some explicitness... extra lams to
capture the types that may vary, even if they are not used to compute
the value of the result). I then wonder how this type system is used
like rank-2 and weirder... ok.
haskell: runST :: forall a. (forall s. ST s a) -> a
lp:
runST :: forall a::*. (forall s::*. ST s a) -> a
or
runST :: forall a::*. forall x::(forall s::*. ST s a). a
easy!!!! the "->" in the type is nothing to do with lam, merely
equivalent to fun, just a syntax sugar that's immediately turned into
forall(pi). The rank-2 argument, in lp, takes an 's' argument that it
needs to use to create any internal ST parts according to their 's'
arguments. runST invents one, and e.g. newSTRef or readSTRef consumes
one, as they are primitives (unless there is another sound way to
implement them).
and we all know typeclasses are really weird and troublesome sugar...
and the dictionary approach is "easy" to do explicitly here..?

natElim's type explains much more to me what it does than foldNat's type
does!

I would have preferred figures 15 and 16 to have bluish backgrounds, as
they are added stuff and they don't stand on their own (but... are
unnecessary to fundamental dependent types... but some of the other
Nat-stuff _is_ blue)

Where is the .lhs source of the paper itself, to see how it was done?

Probably the "uniplate" library could simplify it somewhat for those who
know uniplate already.

It is quite right about (type) inference - it seems some of the most
important research for dependently typed languages is actually being
done by GHC, in implementing type inferences that have to be predictable
and powerful (and work with a fairly sophisticated type system...). It
is the reason that I can't easily write a dynamically-typed Haskell
interpreter that doesn't do type inference - class instance selection is
quite hard, especially in the presence of defaulting, `seq`, complicated
type-restricting signatures, and
functional-dependencies/associated-types. (I thought it might be
interesting to have a way to try to produce _examples_ of
type-incorrectness for when a type error message is incomprehensible.
Of course some programs are NOT dynamically type-incorrect and it
wouldn't be able to find an example in those, and it might be unsafe in
other ways like if it can't enforce runST's rank-2 type signature when
the result is demanded)

Isaac

Make the most of Now

2007-08-10T08:51:56Z

Apologies to the people who are only in here to catch epigram code in
their inbox.
But the partial monad ist discussed as a device for structuring partial
programming in epigram.
And since I wrote these programs mainly to get a grip on - a very short
prefix of - the discussion Bas Spitters and Thorsten had on this list a
while ago, I drop them here.

> {-# OPTIONS -fglasgow-exts #-}

General recursion augments every data type with an extra element, the
divergent compution.

>-- data Empty ; bot = bot :: Empty

Thorsten and others have suggested to make this manifest in the
signature of a program, capturing partiality with the delay monad

> data{- codata -} D a = Now a | Later (D a) ; never = Later never

> instance Monad D where
> return = Now
> Now a >>= f = f a
> Later d >>= f = Later (d >>= f)

which allows for a notion of a 'race'

> (%) :: D a -> D a -> D a

> Now a % _ = Now a
> _ % Now a = Now a
> Later d % Later e = Later (d % e)

('synchronisation' is also at hand)

> (&) :: D a -> D a -> D a

> Now a & Now _ = Now a
> a@(Now _) & Later d = Later (a & d)
> Later d & a@(Now _) = Later (d & a)
> Later d & Later e = Later (d & e)

The delay monad explains for example why the /trivial/ fixed point of
monadic computations isn't very useful.

>-- class Monad m => MonadFix m where
>-- mfix :: (a -> m a) -> m a

>-- instance MonadFix D where
>-- mfix f = f =<< (mfix f)

Because taking

> bot = never

this mfix computes the /least fixed point/ of a partial program lifted
to a partial domain. Which clearly is bot.

---------------------------------------------------------------------------

Topologists with a heart for computability theory are fond of this datatype

>-- data S = T ; bot = bot :: S

which allows the type of /definable characteristic functions/ of subsets
to be defined as this

>-- type Open a = a -> S

and things start to get interesting with programs of type Open S.

But to be able to define the union of subsets

>-- u `union` v = \x -> u x `or` v x

one needs the following equations to hold.

>-- T `or` T = T
>-- T `or` bot = T
>-- bot `or` T = T
>-- bot `or` bot = bot

Enter the delay monad...

Quotienting with respect to termination

> top = {- Later $ ... Later $ -} Now never

makes at least the important ones from the above equations hold
/definitionally/.

>-- top % bot ~~> top
>-- bot % top ~~> top

And we can head for a 'subobject classifier'.

> data Zero {- -}
> type One = D Zero {- bot -}
> type Omega = D One {- bot,top -} ; top :: Omega

Now, before you go "Boring!" just because of this

> type Sub a = a -> Omega

> empty :: Sub a
> empty = const bot

> whole :: Sub a
> whole = const top

consider again the topology of the Sierpinski space.

> [{- -}_,{-top-}_,{-bot,top-}_] = [empty,id,whole] :: [Sub Omega]

Why is {-bot-} :: Sub Omega missing?

Union and intersection are now definable

> (\/),(/\) :: Sub a -> Sub a -> Sub a

> u \/ v = \a -> u a % v a
> u /\ v = \a -> u a & v a

and readily extend to the countable and finite cases respectively.

> (\/.), (/\.) :: [Sub a] -> Sub a

> (\/.) = foldr (\u v -> u \/ (Later . v)) empty

> (/\.) = foldr (/\) whole

Please note that

> locale :: Sub a -> [Sub a] -> Sub a
> locale = \ u -> \us -> u /\ (us \/.)

is well defined even if us is /countable/.

And we can have a poor man's roll your own TT:

> subzero :: Zero -> a
> subzero = \_ -> error ['0'..]

>-- (%),(&) :: Omega -> Omega -> Omega

> type Prop = Sub One

> false :: Prop
> false = \i -> case i of
> Now x -> subzero x
> Later d -> Later (false d)

> true :: Prop
> true = Now -- see subject line

Alladat must have to with 'coalgebras give rise to toposes'. But that
requires more hunting & gathering at the library on my part.

Best regards,
Sebastian

Odelay

2007-07-24T09:12:08Z

Been playing with the partial monad a little longer. Tried to
use it for making the equations of section 3.4 of these nice
lecture notes

http://www.cs.bham.ac.uk/~mhe/papers/entcs87.pdf

hold /definitionally/.

> {-# OPTIONS -fglasgow-exts #-}

Given the suitable codata to capture divergence

> {-co-}data D a = Now a | Later (D a) ; never = Later never

we can not only 'race' two or (infinitely many) more
computations against each other

> Now a \/ _ = Now a
> _ \/ Now a = Now a
> Later d \/ Later e = Later (d \/ e)

but also 'sync' two or finitely more of them.

> Now a /\ Now _ = Now a
> a@(Now _) /\ Later d = Later (a /\ d)
> Later d /\ a@(Now _) = Later (d /\ a)
> Later d /\ Later e = Later (d /\ e)

By quotienting with respect to termination we can have this
initial fragment of the finite sets,

> data Zero -- {}
> type One = D Zero -- {never}
> type Two = D One -- {never,Now never}

allowing us to introduce the subset functor

> type Sub a = a -> Two

which - like the contrapositive of negation - is contravariant.

> ( # ) :: (a -> b) -> Sub b -> Sub a
> ( # ) = flip (.)

((id :: a -> a) # ) = id :: Sub a -> Sub a

((g . f) # ) = (f # ) . (g # )

For example /Sub Two/ gives the topology of the Sierpinski
space, consisting of (const never), id and (const (Now never))
which correspond to {},{Now never} and {never,Now never}
respectively. But there'll be no characteristic function for
{never}.

All this corresponds more to constructive set theory where to
give an element of the union of two sets it suffices to give one
from either one but unlike type theory it's not recorded from
which one.

> union :: Sub a -> Sub a -> Sub a
> union = \u -> \v -> \x -> u x \/ v x

And so Conor's orwell-story

http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=69

/here/ can only be told with functions, not functors:

> zero :: Sub a
> zero = const never

> nogood f = f # zero -- > zero

> orwell f a b = f # (a `union` b) -- > (f # a) `union` (f # b)

I'd really like to see the partial monad beeing integrated into
epigram, because it not only gives safer general recursion but
allows to express semi-deciadable properties like inequality for
codata.

Cheers,
Sebastian

applicative partial programming now

2007-05-07T06:15:15Z

* Am 03.04.07 schrieb Isaac Dupree:

>
> Aren't ALL monads applicative functors? (though not the converse), with:
> pure = return
> (<*>) = ap
>
> And here are some invented (untested) direct definitions:
> instance Functor D where
> fmap f (Now a) = Now (f a)
> fmap f (Later d) = Later (fmap f d)
> instance Applicative D where
> pure = Now
> Now f <*> ma = fmap f ma
> Later df <*> ma = Later (df <*> ma)

Thanks for really putting things into perspective, Isaac. Applicative
functors seem to give a nice interface to partial programming since one
often needs to feed the impure results of general recursive calls to
pure functions.

So given Idiomatica spoken fluently by the compiler

http://www.e-pig.org/epilogue/?p=139

in such case one just needs to wrap the returned values with thoses
funny brackets

iI ... Ii

which signal the application of a pure function to effectful arguments

iI f mx1 ... mxn Ii

such that for example the fibonacci function from

http://sneezy.cs.nott.ac.uk/fplunch/weblog/?p=3

(together with lfp according to the spec) get's a rather ordinary outfit

fib :: Integer -> D Integer
fib = lfp (\ fib -> \ n ->
if n == 0 then iI 0 Ii
else if n == 1 then iI 1 Ii
else iI (+) (fib (n-1)) (fib (n-2)) Ii )

It's also possible to blend in pure values.

fact :: Integer -> D Integer
fact = lfp (\ fact -> \ n ->
if n == 0 then iI 1 Ii
else iI (*) Pu n (fact (n-1)) Ii )

And now that even infixes are available

fib :: Integer -> D Integer
fib = lfp (\ fib -> \ n ->
if n == 0 then iI 0 Ii
else if n == 1 then iI 1 Ii
else ii (fib (n-1)) (+) (fib (n-2)) )

one has a bit of a workaround for cases where it's unfortunate that
bracketing doesn't nest (in Haskell).

qsort :: [Integer] -> D [Integer]
qsort = lfp (\qsort xs ->
case xs of
[] -> iI [] Ii
(x:xs) -> ii (qsort (filter (<x) xs))
(++)
(ii (return [x]) (++) (qsort (filter (>=x) xs))) )

And one can always prune redundant impurity.

nest :: Integer -> D Integer
nest = lfp (\nest n -> if n == 0 then iI 0 Ii
else iI nest (nest (n-1)) Ji )

Best regards,
Sebastian