Cobra Forums

Hi, I am looking at Cobra and I think its pretty nice, but there are a couple tweaks I would recommend:

for statements would be better if they used syntax like the following:

Code: Select all

for each integer A in L
    print A

Another idea is nested for/where statements:

Code: Select all

where L is a list
    for each item A in L
        display A

A where statement can be like variable declaration (or term binding).

. . .

Another good feature to add is parameteric constraints:

Code: Select all

def check(checkbox C where (C.checked))
    C.checked = false

number N is non-zero when (N != 0)

def div(number {A, B}  where (B is non-zero)) = A / B

Basically, one should be able to exactly specify complex constraints on valid parameters.

. . .

Also, instead of using the term "def", it might be better to use the term "has" and other keywords in a streamlined way for objects:

Code: Select all

class Foo
    extendes
        ...
    implements
        ...
    requires
        ...
    has
        method bar(s as String?)
            if s  # same as "if s is not nil"
                print Utils.countChars(s, c'x')

. . .

Anyways, just some thoughts. Keep up the good work!

Also, alternatively for for() statements, one could write:

Code: Select all

for all I in L
  print I

when no type is required, instead of the type-annotated:

Code: Select all

for each item I in L
  print I

Regarding the more explicit "for each", I don't think it has any advantage over "for" past the first day of coding. Also, you almost never need to specify the type because Cobra can infer it. If however, you need to type the for variable, you can write "for i as int in someInts". The "<name> as <type>" syntax is ubiquitous to args, local vars, for loop local vars and even class level vars.

My motivation for putting the type last is that the name is more important. I want to read:
You'll eventually notice that class declarations in Cobra line up quite nicely and are easy to scan. They are kind of "bulleted" by their declaration keywords such as "var", "def", "get" and "pro".

Cobra has a feature like your local statement "where L is a list". I call it if-inherits:
You can see that unlike C# and Java, there is no typecast required on t inside the if-inherits.

Regarding parametric constraints they are already there and done in the style of Eiffel contracts. You can also constraint the return value. And you can constrain on the state of the current object, not just the parameters and return value. See How To Declare Contracts.

"def" is kind of a funny word as there are other things you define in Cobra. But I dislike the term "subroutine" so I don't use "sub". The word "has" is already used for attributes as in "What attributes does that class/method have? It has ..." See Cobra 0.7 Release Notes.

The use of "extend" in Java is just flat out wrong. In real life--which is where we take inspiration for our keywords--when you extend something, that something becomes longer or bigger. If I extend my patio, it's bigger afterwards. If I extend an antenna, it's longer afterwards. In Java, after you "extend" a class it's still the same class with the same capabilities. You created something new and distinct, you didn't extend the old. Cobra uses "inherits".

It seems that what you want is there functionally. The syntax isn't exactly what you want, but that would have been a rare coincidence as everyone has a different ideal syntax.

Thanks for responding, and for clarifying the "require" clause. I suppose its a compromise to support more than just parametric constraints.

As far as "as" goes, both syntaxes (I hope) could be doable. It would basically be syntactic sugar allowing one to make programs more readable by using whichever statement seemed best in a given situation.

Also, kudos for the "inherites" operator, which was a really good idea, but I think you missed my point with "where". I was using "where" to declare a variable, not evaluate a logical expression. "where" is somewhat the opposite of "if"-- instead evaluating a logical statement, it coerces logical statements--it forces them true, raising an exception when it is not possible to do so. This is not like an "assert" statement or "require" clause, in which, again, truth is tested rather than made. The "where" statement is used to declare variables and invariants (that hold within the statement). Of course, I don't know how much work implementing "where" would take.

On "extend", the point wasn't to use "extend", which was only a random example of what I was trying to illustrate--the point was to see the syntactic uniformity object declarations will have if you use an action keyword list.

As far as "has" goes,

"What attributes does that class/method have? It has ..."

A class has methods and properties for its attributes (it generically aggregates things). Again, "has" was meant to make the syntax more uniform and flow better, that's all.

I do want to compliment you on your language--it's much closer to what I envision than most programming languages.

TTFN