jazzyfresh / koan-lang Goto Github PK

Which one do you want? Choose one or forever hold your peace.

I vote hashes. they're cooler. who needs objects anyways?

Static Typing sounds like it might be a boon for koan. Everyone is in favor, counting non-verbalizing as an affirmation.

What do we want our types to be, and what do we want our types to look like?

From class:
I recall we were opposed to a char type, and we wanted a catch all number class for floating point and integer numbers.

But that's the extent of my notes.

I recall Dr. Toal suggesting the absolute value symbol |x| as notation for getting an array/list/set's size... and I think it's totally awesome. I think we should adopt this and put it into our readme.

The only thing this creates conflict with is the ruby block parameter (if that's what they call it); i.e., the
0.upto(100) {|x| puts x }
If the |x| is on the inside of the block, there can be conflict if we were to use the array-size notation immediately after. Well, it's not really a conflict syntactically, but it becomes confusing for the programmer. I suggest the following fix:
8: 0..100 x { puts x }
8: 0..|a| i { a[i] := i }

should we have one? or should we leave it as just the last statement of the function

for clarity, it would be cool to have a return statement, but clojure doesn't have them which is kinda sexy too.

if yes, we can use

<-

or

r:

as a return statement notation.

If we have anonymous functions, it might be good to just leave it as is (i.e. the return statement is the value of the last statement evaluated).

I like the special return statement notation, but why not both?

Because our language doesn't allow expression statements, an if-statement like this

??: (a % b == 0) ? a : b ??; 

does not parse (as the arm and else clause of the if-statement contain expression statements). However, the last line of a function declaration is implicitly also the return statement, and in certain situations, we may just want to return the result of an expression, like so:

f gcd := f: (x,y) -> { ??: (a % b == 0) ? a : gcd(b, a % b)??; };

An obvious flaw in our language design, which, I recall, we saw a mile away, but neglected to do anything about it. Our options: add expression statements or return statements to our grammar. Any thoughts?

How does static typing work with return types?

When we have the declaration of a variable that is a function, where do we specify what return type it is? Can we specify the return type of the function in the spot where we would normally put what type the object is? Do we have to specify the return type at all? OCaml is statically typed and just infers what the return type is...

# let average a b =
    (a +. b) /. 2.0;;
val average : float -> float -> float = <fun>

I'd like to take the OCaml stance, how does everyone else feel about it?

With the language design almost done, we need to decide on a syntax for the following object oriented operations:

• classes or prototypes?
• class definition (continuous like in ruby?)
• object declaration (mandatory or optional constructors?)
• method calls
• accessors/writers
• static variables, instance variables
• inheritance
• singleton methods

For fn declaration we need a parseFun in addtion to parseFunCall

Adding
private String name
to Function class
with getter and setter

f: x(#i) -> {i + 2} (10)

x(200)
when a function is called are we recreating a new function or referrencing the original function?
id est
x(200) creates
x(200) -> {200 + 2} (10)
OR
x(200) creates
x.params = 200 (set)
x.body = {x.params + 2}

gcd(300, 539)

These are notes that I took on Dr. Toal's comments during the presentation on 5 Feb 2013:

List Comprehension -- The context in which we have used it in our README is incorrect. List comprehension returns a list; it is not a statement. Would we consider adding List Comprehension?

Thin Arrow vs. Hash Rocket(Fat Arrow) -- I went through a few of the dictionary comparisons on hyperpolyglot and it appears that no other interpreted language (like Ruby) uses the thin arrow.

Note: CoffeeScript actually does use the both the thin and fat arrow for functions. The thin arrow defines the function:

CoffeeScript                                   c:koan
square = (x) -> x * x                          square := f:(x) -> {x := x * x}
cube   = (x) -> square(x) * x                  cube := f:(x) -> {x :=  square(x) * x}  

and the fat arrow binds the function:

CoffeeScript:

Account = (customer, cart) ->
@customer = customer
@cart = cart    
$('.shopping_cart').bind 'click', (event) =>
    @customer.purchase @cart

JavaScript:

var Account;    
Account = function(customer, cart) {
      var _this = this;
      this.customer = customer;
      this.cart = cart;
      return $('.shopping_cart').bind('click', function(event) {
           return _this.customer.purchase(_this.cart);
 });
};

Not going to lie, this seems pretty cool. But opinions.

We have the opportunity to either keep it or change it to be more in line with Ruby dictionaries. Also, since the hashmap and the function use the thin arrow, difficulties can arise when a function is declared within a hash. I'm not sure if I'm remembering correctly, but I believe we said something along the lines of only anonymous functions being able to be declared within hashes? Either way, we need to choose.

Top Level Anonymous Functions

Truthy/Falsy -- or lack thereof. Requiring Boolean variables, or rather disallowing truthy/falsy associations, means Runtime type-checks.

We need to start generating sample code for testing now. Please create separate files in src/test/koan with each file focusing on testing a different feature of the language. You can also have some files that focus on testing multiple parts of the language, such as writing some popular algorithm in our language.

How are we formatting the print statements that contain both strings and variable references? In the sample code, that is, the 99 bottles script, I left it as:

p: "%d bottle%s of beer on the wall,\n", bottles-left, plural;

Is this optimal or are we looking for something more like:

p: bottles-left + " bottle" + plural + " of beer on the wall \n"

What do we like better? If we choose the bottom, is this a reflection on how we do string concatenation?

We have 19 of these warnings when we javacc koan.jj:

Warning: Choice conflict involving two expansions at
         line 41, column 7 and line 45, column 7 respectively.
         A common prefix is: <CHARLIT> <CHARLIT>
         Consider using a lookahead of 3 or more for earlier expansion.

Let's get them resolved by learning what Lookaheads are and applying them to our syntax checker.

We discussed on Thursday that we wanted to allow a for loop to run a statement a certain number of times (depending on the size of the range/array given) without requiring the programmer to give a dummy block parameter if it's not needed. In other words, our grammar is

FORLOOP --> 8: EXP (ANONFUN | ID? STMT)

(taking note of the optional ID) so one could potentially write

8: 1..10 x doThisThing(x)

or

8: 1..10 doAnotherThing()

but they could also write

8: 1..10 x := x + 1

where x is not intended to be the block parameter (ID) for the statement, but part of the statement itself. Thus, you can see the choice conflict more clearly.

Anyways, as a quick fix, I rewrote that part of the grammar to make the ID required, but that is a bit limiting. I just wanted to know what you guys wanted to do about this as I'm not quite sure how messy it would be to resolve this with lookaheads.

Need to make syntax checker functions return the objects that correspond to each lexeme

Essentially, subscripted variable references (i.e. array references) parse correctly as expressions, but don't seem to be working on the left side of assignment or swap statements. Anybody up to figuring this out? It's had me puzzled for a bit.

Relevant Test Files

• swapper.kn
• assignments.kn
• variable-references.kn