Well, that’s the interesting question … one which I’m hoping to find out the answer to soon enough!!

(I have been an unabashed fan of units and measures in programming for some years. Once when creating a simulation creation platform, I decided to add JScience to provide some clarity and flexibility to end users, allow for automatic conversions between equivalent units, and provide some basic operations on those measurements. Once I had integrated them into my code, they pinpointed an error in the simulation that otherwise would have gone unnoticed for quite some time… and they worked beautifully for all the reasons I had intended to use them as well.)

/**
*
*
*
**/
public class Alias {

private T val;

// create an alias for a “type”
public static Alias create(T elem) {
Alias val = new Alias();
val.val = elem;
return val;
}

// create an alias alias or a copy ;-P
public Alias me(boolean forceCopy) {
if (!forceCopy) {
return (Alias) this;
}
Alias val = new Alias();
val.val = (T) this.val;
return val;
}

// holding value!
public T value() {
return val;
}

@SuppressWarnings(“unchecked”)
public <S extends Alias> S as() {
return (S) this;
}

} // END

/**
* The Class That Use Alias
*
**/
class UsingAlias {

public void aMethod(Alias aliasIntArray, Object someOtherValue) {
System.out.println(someOtherValue + ” –> ”
+ Arrays.toString(aliasIntArray.<Alias> as().value()));
}

public static void main(String[] args) {

int[] arr = { 1, 2, 3, 4, 5 };
Alias sorted = Alias. create(arr);
Alias sort2 = sorted. me(false);
Alias sort3 = sorted. me(true);

System.out.println(sorted + ” –> ” + sorted.value());
System.out.println(sort2);
System.out.println(sort3);

UsingAlias user = new UsingAlias();
user.aMethod(sorted, “Hello World!”);

}
}

Yeah, this is strongly related to SSA form. However, it’s a bit easier for me since Whiley doesn’t have unstructured control-flow.

Yeah, that’s a common complaint against structural typing. I may well include some constructs to help with this kind of situation. For example, something like Units in F# would be interesting …

define Temp as { int degrees; }
define Bearing as { int degrees; }

Temp heatInDirection(Bearing b):
// TODO Somehow calculate the temperature seen in direction b
return b // Oops, type system didn’t stop us doing something dumb!

That’s the beauty of structural typing. The name is only superficial. Think of it as like a C macro which is always expanded. So, LongMove is really just the type {Piece piece,LongPos from,LongPos to} — nothing more. Whenever you see LongMove, the compiler automatically expands it. So, before the assignment, m has type {Piece piece,ShortPos from,LongPos to} and then afterwards its type is the same LongMove’s.

The critical issue resolves around the statement m.from = matches[0]. This retypes variable m from ShortMove to LongMove…

How does it know to retype m to LongMove? Since it seems to be a forward analysis, and there are no loops in the function, I’m assuming it can’t use the subsequent return statement to infer the new type.

Let’s say there is another type X in scope with a field LongPos from. Will it retype m as LongMove | X ?

Yeah, that’s basically what I do. I call it “tunneling”, since I have to do both directions: wrapping I/O exceptions with CoreExceptions and vice versa.

Dave

Once you reach a certain scale, you‘re no longer thinking in terms of a single codebase—the boundaries of any significantly large system are very blurred. It’s difficult to determine where the system system starts and ends, when it’s interacting with large volumes of data, external services, and real-time feeds from the outside world.

In these situations (especially where very large codebases are unavoidable), a strict compiler might be useful in constraining local boundary conditions of a function, but in any case, regardless of static or dynamic, the architectural emphasis needs to be on immutability. If a codebase cannot be constrained to control mutable objects and data structures, then the amount of unit+integration tests needed will increase enormously, and this is just as true for static languages as dynamic ones.

“100 functions operating on 1 data structure is better than 10 functions operating on 10 data structures.”

Actually, in fact, there’s nothing wrong!! At the moment, compile-time checking of constraints is disabled. Basically, because I’ve been working on getting the core language to work properly.

These constraints are checked at runtime, and in the very near future I will be turning compile-time checking back on. In the meantime, if you’re interested in the compile-time checking, then use version 0.3.1 — that’s the last good version compile-time checking turned on. In that version, you need to used “wyjc -V” to enable compile-time checking of constraints.

Thanks,

Dave

I thought I would give Whiley a spin, after playing around with ATS for a while. Having some of the same type precision as ATS yet coexisting with the Java ecosystem is very appealing.

However, I ran into a problem right away, attempting to run an example from the video demo.

The following code compiles without error, which it should not:
===========================================
int f(int x) ensures $ > 1000:
return x
===========================================

In fact, the following simpler version also compiles, incorrectly:
===========================================
int f(int x) ensures $ > 0:
return x
===========================================

I am using version 0.3.14 on java 1.6.0_22.

The command I used was:
bin/wyjc test.whiley

Am I doing anything wrong?

Thanks.

“the presenter claimed that for Java (and possibly .Net), the ratio should be roughly 1:1″

I don’t agree. You’ll typically need a much ratio of LTC to LPC. Think how many lines of JUnit it takes to cover a single condition.

The only empirical evidence I’ve seen was a survey that Agitar commissioned of open-source projects, and it’s own code base. This concluded that a ratio of about 1:4 (LPC:LTC) was sufficient for about 80% test coverage. [This was published at openquality.org, but the site has been taken down.]

And using a TDD approach, I’d say I write the same number of tests for static and dynamic languages.

When using dynamic languages, I do find that the test code is shorter. However this is negated by the reduction in IDE support for generating production code from failing tests (eg. create missing classes, create missing methods, add parameter etc). This is certainly the case for Groovy in Eclipse, maybe less so for other languages/IDEs?

Yeah, I agree, annotations are a good solution here — why did I think of that!!

D

alias int[] sorted;

private alias int[] sorted; // as in type to name
This is more inline with
private static String thing; // as in type name

The idea just introduces some syntactic sugar without for any guarantees, the sorted does not actual guarantee that is sorted. So I think that an actual object SortedIntArray seems more reliable. And reliability > syntactic sugar.

@Retention(RetentionPolicy.SOURCE)
@Target({ElementType.METHOD, ElementType.FIELD, ElementType.Parameter})
@interface Sorted {
}

then use it with:

int findLowest(@Sorted int[] arr, int value) {
…
}

OR

@Sorted char[] myArray;
@Sorted String[] myStringArray;

OR on return values:

public @Sorted int[] getFunctionName()

If all you’re looking for is documentation, this is the better strategy than trying to type alias. This is also more accepted and easier to read than type alias.

class MyType extends WhateverYouWant {}

Granted, it’s a bit hackish and may incur a tiny weeny performance overhead, but it seems to work well otherwise. You’ll need a cast once a while tough.


private static Class actualClass = ID;

public static ID create();
public static void setClass( Class clz );


And then set adaptor with setClass, and in create use actualClass to create the instance.

in clojure Path.ID would be a protocol that the plugin could extend to IPath

java style interfaces have the problem of not being injectable/extendable to types you don’t own

http://clojure.org/protocols
http://book.realworldhaskell.org/read/using-typeclasses.html

Obviously when building new things that use Path.ID you’ll have to test against both versions.

Yeah, so basically have different versions of Path.ID, depending on whether I’m compiling for Eclipse or stand-alone. Yeah, that’s workable … but still not exactly elegant

D

My guess is that IPath will probably provide more methods then Path.ID, so you might want Path.ID to actually be an abstract class that can fill/stub the functionality.

Technically you would only use Path.ID extends IPath when you want eclipse support (via an optional jar or similar) so you wouldn’t _require_ eclipse.

So, pretty much what you describe is what I would expect to happen. The key thing is that the decoder *should* produce an error message if it’s asked to decode an invalid file. The constraints are a form of backup. If the programmer forgets to check something, then we still want it to fail. With compile-time checking of constraints, this works even better because the programmer cannot construct an instance of the data structure without first checking the necessary constraints (i.e. the compiler spits out an error if he/she doesn’t check them and report an appropriate error). Think of it as an additional safety net…

Yeah, there is no bootstrapping compiler. This is a specific choice. Essentially, I think there’s more value in writing these kind of real-world benchmarks first, rather than rebuilding what I already have. However, I am going to start converting the compiler into Whiley. In fact, I’ve already begun … another one of my benchmarks is a library for manipulating Java bytecode. When this is finished, I’ll slot it in to replace the Java library I currently use in the compiler. Towards the end of the year I plan to get serious about rewriting the whole compiler in Whiley.