Will appreciate comments on the implementation/design choices.

TheDong · on Oct 28, 2018

I think you'll get more comments if you include specific code samples.

How would you implement the Fibonacci sequence in whack? How might one organize a simple game of hangman?

If it's suitable for use as a tcp server/client, how about a "echo" client?

Things like that can really show off the stdlib and the syntax choices.

Relatively few people will read through the code, and even those that do will likely understand the code better if they start from "this is the syntax or idea that needs to be implemented" as expressed in example code.

Documentation is also, obviously, more coherent to read than implementation code, and you don't seem to have any documentation explaining what features whack has (other than a note that it doesn't have a comprehensive type system).

wycliffb · on Oct 28, 2018

There's a sample file main.w in the snapshot folder, there's also a grammar file at the source root.

dan-robertson · on Oct 28, 2018

In that file I saw the line:

  r.amazing();

But that function is defined as taking a Bool. What is this call supposed to do?

I’m also curious how you plan to implement match type. How would this work if you give it eg a char ? Will the compiler know what the type is and pick the right clause. I don’t really see a way to do it by inspecting the data at runtime so maybe the pointer would have to have runtime type information attached to it, but you would then need to transform that info when dereferencing the pointer as this info can’t live in memory next to the pointed-at objects if you want C compatibility.

I also can’t really tell what match type is for from your example. Are you intending to have inheritance and then using match type as a kind of ad-hoc polymorphism (eg is my Animal a Dog or is it a Cat?), or some sort of weird template-like thing, or something else entirely?

If you allow subtyping then does “func(Dog->Int)” successfully match something of type “func(Animal->Int)”?

wycliffb · on Oct 28, 2018

Will commence working on a doc to explain some design choices, and what some non-obvious code fragments do; will update here when I commit. There's no subtyping being done currently. The 'match type' construct matches the type of an expression at compile time. I should also add that some design choices may be reviewed before the first release.

dan-robertson · on Oct 28, 2018

Surely if match type is compile time and there is no subtyping then it is basically a no-op type assert. I.e. it’s like writing (e : t) in ML?

Or is it supposed to allow for some kind of ad-hoc polymorphism like:

  func foo(x) string {
    match type(x) {
      char** : return “an array of strings”
      int : return “a number”
      default : return “not sure”
    }
  }

And this gets transformed into something like:

  func foo(Type x_t, x_t x) string {
    match(x_t) {
      pointer_t(pointer_t(char_t)) : return ...
      ...
    }
  }

wycliffb · on Oct 29, 2018

Interesting suggestion! Will be sure to add that when I can.