whiley / whileydocs Goto Github PK

There is no section in Chapter 6 "Expressions" for sublist operations.

Currently it says

There are four functional entities which can be defined within a Whiley source file:
type declarations (§3.5.2), constant declarations (§3.5.3), function declarations (§3.5.4) and
method declarations (§3.5.5).

The list append operator was removed and this should be reflected in the spec.

Minor bug in getting started document at start of Section 2.2 Arrays, in the code:

function vectorMultiply(int[] vector, int[] scalar) -> int[]:
    int i = 0
    while i < |vector|:  // needs loop invariant
        vector[i] = vector[i] * scalar
        i = i + 1
    return vector

Scalar is defined as an array (which I assume is just a typo). I would also mention that this code does not compile even with that fixed without the loop invariant i>=0 (unless I am doing something wrong) but perhaps that is intentional (to avoid getting into that discussion so early in the document). If you are not looking yet for such trivial errors given your other work, please just ignore. :)

Really enjoying playing with this language, thanks for making it so accessible!

-Tim ([email protected])

Currently, the grammar used for describing Whiley statements and expressions is imprecise in certain ways. For example when describing the syntax for an if statement, the condition is defined as a generic Expr, when in fact it can only be a boolean expression.

The question is whether or not we can describe this and, if so, do we want to?

For example

for i in 0..|items|:
   r = r + items[i]

The syntax for functions has changed from => to ->.

Discussion in S4.11 includes real type.

Mixed types are referred to in Section 4.6 "Records", but there is no grammar given for them anyway.

Current syntax doesn't permit generic types!

Should clarify which types can be compared with equality.

These have been removed from the language now, and the documentation needs to be updated accordingly.

From chapter 5 of the specification (eg_6.whiley), the example for continue:

function sumNonNegative(int[] xs) -> int:
    int i = 0
    int r = 0
    while i < |xs|:
        if xs[i] < 0:
            continue
        r = r + xs[i]
        i = i + 1
    return r

While this example demonstrates the continue statement, it also will cause an endless loop if the array actually contains a negative value (because the i = i + 1 is also skipped).

I'm not sure how this example could be fixed to do what the function name pretends, and still use continue.

In the language specification it is not clearly mentioned that there are three phases, and how they depend on each other.

This is what I gathered (e.g. from the description of the assert and assume and fail statements):

• Compile time is when the compiler parses and analyzes the source code, does some type checking, and emits code suitable for verification and for running.
• Verification time is when a verifier takes the compiled code (maybe in a different representation than the one which is run) and checks that it actually does what it pretends to do.
• Run time is when an interpreter takes the compiled code and executes it.

I first assumed those phased happen always in this order, and only verified code is actually run. But the description of fail tells me that it throws a fault at runtime, while the verifier makes sure it is not reachable. How can it then throw a fault? Same for assert (which is basically if (! condition): fail).

Does this mean verification is optional?

Hi,

I think that in 3.2 Recursive Types, "abstract data types" should be "algebraic data types".

Currently, some code examples are inlined into the latex files directly. These should be split out and included in the examples/ directory, and an appropriate harness created for compiling them.

Currently, type patterns are used to describe the syntax for function and method declarations, though not lambdas. However, this does not reflect what the Whiley parser does.

The list generator syntax is [e;n]

I think the loop needs to increment the loop counter i!

(It is also not obvious to me why it mutates and returns the input list xs, instead of the copy zs?)

There is no section in chapter 6 "Expressions" for the type test operator is.

There is currently no syntax for lambda constants. For example, expressions like this:

type fun is function(int)->int

function f(int x) -> (int y):
    return x+1

function create() -> fun:
    return &f

In Section 4.7 it should include array assignment and array length.

For example:

(int x, int y) = swap(1,2)

and

int x
int y
(x,y) = swap(1,2)

The syntax for reference lifetimes is not given in the language specification at this stage. The full syntax is given here:

http://homepages.ecs.vuw.ac.nz/~djp/files/MSCThesisSebastian.pdf

In the syntax of DoWhileStmt, IfStmt, SwitchStmt and WhileStmt, there are raised cursive letters (φ, ω, l, γ) without any explanation on what they mean.

After some confusion I came to the conclusion that they indicate the indentation of the corresponding syntactic elements, but that is not mentioned anywhere (neither in the Indentation section nor in the Block section nor anywhere in the Control Statements section).

LVals are referred to in section 5.3 "Assignment Statements", but there is no grammar defined anywhere for them.

Chapter 4 Types & Values overview mentions intersection and negation types.

As a result of issue 427 the syntax of cast and bracketed expressions has changed somewhat. This needs to be reflected in the Specification.

specification doesn't match implementation, note the missing commas in the specification.

In Haskell there are no commas, e.g. \x y -> x + y.
But we need to have the types, so I guess commas are good and it is an issue with the specification rather than implementation.

There is currently a serious problem with the rules describing operator precedence. For example, they indicate that !x.f should parse as (!x).f which is definitely broken.

Thanks to @richdougherty for pointing this out.

Section 4.5 "References" indicates lifetime syntax.

Issue 418 removed implicit coercions from the language. All documentation needs to be updated accordingly.

The terminology in Whiley is set to change. The "list" type is to be replaced with the "array" type. Hence, all documents need to be updated in two ways:

1. Should refer to array types and array expressions.
2. Should use array type syntax, rather than old list syntax.