Hello World error

[Charles]

I'm still looking into this and have some mods for the installer which I'm testing.

[DelphiGuy]

charles:

my first cobra program. a triumph. cobra is so much less verbose than what i'm used to, it's quite fun to see such elegant instructions suffice.

there's a goofy MS design decision (read: mistake) in http://msdn.microsoft.com/en-us/library/2dx6wyd4.aspx. notice that maxValue is never returned from this method. i cannot imagine any situation in which a programmer would welcome such peculiar behavior.

so, i have fixed the problem, as my first study of inheritance in cobra...

##################################

namespace RandomSpace

    class RandomDemo

        def main
            r = MyRandom()
            for i in 1:15
                print r.next(0, 2)   #is 2 now returned from the .next method?
             
    class MyRandom inherits Random
    
        cue init
            base.init

        def next(lowValue as int, highValue as int) as int    #fix next from random class,
            assert lowValue <= highValue
            #assert highValue + 1 <= int.MaxValue
            return base.next(lowValue, highValue + 1)

###########################

i thought the ability to have this.next call back to base.next was pretty cool, but obviously that is not specifically a cobra nicety, but rather a common OOP object model nicety. nevertheless, it was fun to see it all work. (particularly after making a zillion syntax mistakes for the better part of a week before i was able to get this running.)

i gather that inherited constructors don't automagically run, but have to be called explicitly. i don't really have my mind around why it is that (at least some) OOP tools are designed that way, but i'm sure the light bulb will go on eventually.

how, please, can i assign the constant maximum value of an int to a variable, without explicitly providing the value? you can see that my attempt in the 2nd to last line won't compile and i had to comment it out.

on another topic, i was curious about the type inference in cobra. can this be turned off so as to force explicit variable declarations? i'm sure this has been discussed before, so perhaps your can link me to your explanation. my understanding has been that the Basic ability to declare variables through inference is considered poor programming, because although convenient it turns compiler errors (for mis-typing a variable name that's already in play) into logical errors, which presumably are more difficult to find and debug. i know you don't make these lang decisions lightly, so i'm curious as to how you decided in favor of type inference. (and i'll be curious to know if my understanding of Basic's "declare variables on the fly" ability is correct and indeed similar to cobra's. i probably played with VB in 1985 or so.)

finally, i like the more straightforward words you use to describe various parts of the language. for example, "int8, int16, int32"..., all makes a heckuva lot of common sense. i wasn't sure why cobra has a float and a double type. for consistency's sake, shouldn't there be a "float32/float" and a "float64" instead? aren't they both just floating point types?

looking forward, my intention is to write a comm'l iphone app using cobra for most all of the engine work. despite the relatively primitive tools, the language is just plain a lot more fun and a lot easier to use than C#, in my humble opinion. in fact, this first study posted above is the beginning of me porting the program from delphi and eventually putting a GUI on it.

-paul

[Charles]

charles:

my first cobra program. a triumph. cobra is so much less verbose than what i'm used to, it's quite fun to see such elegant instructions suffice.

Thanks.

The "inclusive lower bound with exclusive upper bound" is a common approach in math and computer science, often called the "open half interval". See:

-- http://www.velocityreviews.com/forums/t ... range.html
-- http://www.cs.utexas.edu/users/EWD/ewd08xx/EWD831.PDF

But not everyone agrees with this approach, of course.

You said you made a "zillion syntax mistakes". Sorry to hear that. Cobra tries to have a clean, simple syntax and also tries to give good error messages when things aren't right. If you have anything to share about what was difficult, feel free. Also, check out the Samples and How Tos which should help you along.

Re: max value, try "int.maxValue" with a lower case "m" and using the latest Cobra from source. I tested and it works fine. The compiler should have given a nice message about the casing, but that didn't happen. I'll take a look at improving it.

I think old VB's approach to "type inference" was not to infer the type at all, but to assume a special type called "variant" which could be assigned to anything. Not really the same as Cobra where "i = 5" is equivalent to "i as int = 5" and "i" can never be assigned to anything but ints. (You can get around this limitation by saying "i = 5 to dynamic" although the "int" constraint provides better performance and error checking.)

Regarding your concern for errors, I'm sure you're thinking of this:

count = 5
cont = 10  # misspelled
assert count == 10   # fail

But this type of problem does not last long because Cobra warns you about the misspelling:

Code: Select all

foo.cobra(10): warning: The value of variable "cont" is never used.


So you will find that in practice, this is not a real problem.

Re: "double" type, there is none. There is "float32" and "float64" and "float" is a synonym for "float64".

Perhaps you saw "decimal" and got confused. .NET provides a "decimal" type than can, for example, accurately store the number 0.1 where as "float64" cannot. See "Accurate Math" at http://cobra-language.com/docs/python/

When including Cobra code in a post, try <cobra> ... </cobra> instead of <code> ... </code> and you will get syntax highlighting (and of course, I really mean square brackets, not angle).

Thanks for your feedback and questions.

[DelphiGuy]

the "inclusive lower bound with exclusive upper bound" may have common applications in science/math, but i can't see any advantage to using such a scheme when asking for an explicit range of integers. while the articles you linked to were a bit over my head, they seemed to be discussing various options for choosing integers to represent indices. in contrast, in the MS method that's the subject of our discussion, the programmer is (or should be) requesting the actual range explicitly stated as values.

for example, it may be of interest to debate whether we should construct a database for the local playhouse's ticket sales, with an index starting with "0" to represent seat A1, or instead whether we should use a "1" to represent that seat. but i don't think any of us would be too happy if, as consumers, we called the theater's box office and asked for seats A1 through A5, and the box office only mailed us A1 through A4. in short, it seems to me that in discussing the merits of "inclusive lower bound with exclusive upper bound", there's a difference between considering indices used to access a value, and considering the values themselves. but maybe i just didn't understand the articles you sent me.

the reason i wrongly assumed cobra has both a float and double type is because the documentation says so, here: http://cobra-language.com/trac/cobra/wiki/C.

Numeric types specified as int, uint, float and double types (rather than Int, UInt, Float, Double)

regarding the "zillion syntax errors", well, they weren't all syntax errors. some of them, now that i think back, were general .net OOP issues not specifically cobra-related. it took me a long time to understand, for example, that inherited constructors don't automagically run, and i was confused by the wording of the cobra compiler error msg (before i manually inserted a constructor), which said exactly what it meant, but i wasn't OOP-smart enough to understand.

yes, i found the cobra error msgs to be pretty darned helpful along the way, and the compiler did help me to learn more cobra fluency. by the way, i completely agree that the syntax is clean and simple. it's just taking some growing pains (not just the lang, but also .net concepts and general OOP knowledge) to get up and running. since i started becoming even a hair more fluent, i now would prefer to use cobra as my main development lang. i did indeed look at your documentation, some of which was very helpful. again, the biggest problem for me with the documentation was a lack of a comprehensive index, as one might find in the back of a big thick comprehensive paperback guide on how to program with Cobra. the time will come, i'm sure, where there are a number of such books on the market. in the interim, i believe we've discussed before the advantages and disadvantages of the current search feature.

nevertheless, i realize that having a beginner like me write down for you my cobra confusions is valuable info. i'll try to be more proactive about posting here anything i find confusing, before time goes by and i can't remember why i was confused by it.

regarding VB "type inference", thank you very much for the thorough explanation. now that i understand better, i completely agree that cobra chooses wisely in letting the compiler handle as much of the coding as possible, including type inference. looks better. even makes more sense, once i got used to it.

regarding getting the latest cobra from source, i'm confused as to how to do so. i choose your "downloads" menu from the website, right? then what? there's instructions there for using svn to get the source, but i thought you recently told me that your latest method for getting the latest and greatest cobra no longer uses svn. of course, i'm not familiar with svn so maybe that's the problem. FYI, i'm running win 7 home premium 64 bit.

finally, my lower case writing, although admittedly lazy, isn't really as hard to read as it may seem at first glance. i generally insert two spaces between each sentence, which makes it very clear to the eye where the sentences start and stop. the way this text is displayed, though, strips out the extra space, leaving my writing looking more crowded. maybe that's standard HTML behavior. so my apologies to your readers, but my heart was in the right place!

-paul

[Charles]

-- I see what you're saying with "indices" vs. "values".

-- I have corrected the line in the wiki page on C# differences that lead to confusion.

nevertheless, i realize that having a beginner like me write down for you my cobra confusions is valuable info. i'll try to be more proactive about posting here anything i find confusing, before time goes by and i can't remember why i was confused by it.

-- Exactly! I'm glad you understand this too.

-- To get the source code, you need to get a subversion client. I'm partial to the command line myself, but there are also GUI ones such as TortoiseSVN. Whatever client you have, it enables you to download the source code from a subversion repository sitting on some server and accessed via a URL. Then see HowToInstallFromSource.

-- Don't worry about lower case writing. The reason computing migrated away from SCREAMING CAPS which were used on the mainframes, minis and early PCs, is because capital letters are not as easily distinguished as lower case (read that somewhere, but don't have the reference handy). You'll also be interested to know that I have it as a goal to allow Cobra code to be entered in all lower case and have the compiler correct it, provided that there is no ambiguity. In fact, I already have a start on this which you'll notice if you read through the output of "cobra -help":

Code: Select all

cobra -help
...
    -correct-source[:none|case|all]  default is none
    -cs
        Rewrite source files with corrections, only when unambiguous. For example, "string" --> "String". If possible, you should set your editor to
        automatically reload files when using this option.


[DelphiGuy]

charles:

regarding your correction, shown here:

Numeric types specified as int, uint, float/float64, float32 and decimal
Sized int and uint types all have the same naming form

int8, int16, int/int32, int64 instead of SByte, Int16, Int32/int, Int64
uint8, uint16, uint/uint32, uint64 instead of Byte, UInt16,...

may i suggest adding an add'l line:

Numeric types specified as int, uint, float/float64, float32 and decimal
Sized int and uint types all have the same naming form

int8, int16, int/int32, int64 instead of SByte, Int16, Int32/int, Int64
uint8, uint16, uint/uint32, uint64 instead of Byte, UInt16,...
float32, float/float64 instead of float, double

also, aren't the C# data types you cite above generally spelled with lower case?

[Charles]

Yes and yes. If you look at the history of that wiki page, I didn't write it so it wasn't actually me citing them.

Note that a fraction of C# programmers do use the names of the System structs while the majority use the C# built-in names. Basically for anything that can vary in syntax, it will and often with no benefit. That's why I prefer less syntactic variation in a language. Power comes from semantics and clean, consistent syntax. Now I'm rambling.

I have updated the page a little. In the future, don't be shy about updating pages directly. You can login to the wiki with same name and password as the forums.

[DelphiGuy]

Earlier in this discussion topic, Delphiguy (me) said:

for example, it may be of interest to debate whether we should construct a database for the local playhouse's ticket sales, with an index starting with "0" to represent seat A1, or instead whether we should use a "1" to represent that seat. but i don't think any of us would be too happy if, as consumers, we called the theater's box office and asked for seats A1 through A5, and the box office only mailed us A1 through A4. in short, it seems to me that in discussing the merits of "inclusive lower bound with exclusive upper bound", there's a difference between considering indices used to access a value, and considering the values themselves.

Well, on a similar topic, I'm now learning Cobra's numeric "for loops" from:

http://cobra-language.com/trac/cobra/wiki/NumericFor

Is it true {gasp!} that Cobra has only right exclusive numeric "for loop" syntax? You'll please pardon for me for beating a dead horse, but if we don't already have one, is it possible for Cobra to offer a right inclusive numeric "for loop" syntax as well?

Consider the following code:

Code: Select all

for i in 5
    print i    # prints values 0,1,2,3,4

Rhetorically, I think a reasonable argument can be made that the above code should print the values "1,2,3,4,5" instead. After all, the whole reason for higher level development tools is that they insulate us from the persnickety and arcane way the computer thinks about things, and try to give us an interface to the machine that is more ergonomic to the way humans conceptualize. However, admittedly my proposed solution ignores the questions of (a) computer language tradition, (b) what would happen to zero in such a scheme?, and (c) at least "print i" prints five things, as requested.

But more practically, what justification can there be for the following code?:

Code: Select all

for i in 1:10
     print i   # prints values 1,2,3,4,5,6,7,8,9

Indeed, what function does the number "10" even serve in the above statement? It doesn't represent the uppermost value that "i" will reach during the looping. Heck, it doesn't even represent the number of values that the programmer is requesting to be printed. And we've already told the compiler "don't worry right now about the traditional zero-based index thing" that we implied in the previous example (above), because we've explicitly stated "here, the debate over zero vs non-zero based indexes is moot -- just start from 1!" by using this syntax and statement.

Therefore, in this example "10" functions as (from the human perspective) an essentially arbitrary number. Using the same logic, we might as well have instead required the user to put an absurd "11" or a "23" in the statement, if we wanted to request 9 elements to be printed. I.e., we might as well have a rule that says "always add 2 or 14 to the index of the uppermost value you want examined" instead of the current rule which seems to be "always add 1 to the index of the uppermost value you want examined".

The "for loop" basically requests the computer to "sequentially do some thing to the members of this range or set", yes? Using the quote above (about the theater seats), if we requested seats A1 through A5 for a performance we'd be pretty annoyed to later receive tickets in the mail for only seats A1 through A4.

In short: there may be some benefit or logic to the right-exclusive syntax in the first example above, but what's the benefit or logic of using right-exclusive in the second example? I can't even imagine a situation in which it would be more useful or common-sensible.

Is there a right-inclusive numeric "for loop" syntax in Cobra? And if not, could there please be for the reasons stated?

I note, FWIW, that the Delphi (my previous main language prior to moving over to Cobra) "for loop" is right-inclusive:

http://delphi.about.com/od/beginners/a/delphi_loops.htm

Thanks, Charles.

[nerdzero]

These are some interesting points you bring up, DelphiGuy. Correct me if I am wrong, Charles but it seems like the Cobra for loop syntax is inspired by the way you iterate over a list of numbers created via the 'range' function in Python. Here's some Python syntax:

Code: Select all

for i in range(5)
   print i    # prints values 0,1,2,3,4
   
for i in range(1:10)
   print i   # prints values 1,2,3,4,5,6,7,8,9

In Python, the range function returns a list of numbers starting from a given number, up to a given end point, and incrementing by a given step value. Only, the end point is required and is never included in the returned list. The default starting value is 0 and the default step is 1. You can read all about it here if you are interested: http://docs.python.org/library/functions.html#range

So the Cobra for loop, like Python, only iterates across lists (or more generally anything that can be enumerated) with the difference being that if you provide an integer instead of a list, then the list of numbers that a call to the 'range' function in Python would have returned is implicitly created for you.

If you aren't familiar with Python, I can see how this would be confusing. VB, which gets a bad rap when it really shouldn't, solves this by making a distinction between a "classic for loop" and a "for each loop".

Code: Select all

For i As Integer = 1 To 10
   Console.WriteLine(i)
Next i

For Each i As Integer In Enumerable.Range(1, 10)
   Console.WriteLine(i)
Next i

Both of those loops will print 1 through 10. What's that you say?! Yes, you can use Enumerable.Range in Cobra but make sure you reference the correct System.Core.dll.

@ref 'C:\Program Files\Reference Assemblies\Microsoft\Framework\v3.5\System.Core'

use System.Linq

class PrintRange
    def main
        for i in Enumerable.range(1, 10)
            print i

or just do this

for i in 1:11
    print i

or maybe you can convice Charles to add in a new syntax. Something like this perhaps:

for i = 1 to 10
    print i    # would print values 1,2,3,4,5,6,7,8,9,10
    
for i = 1 to 10 step 2
    print i    # would print values 1,3,5,7,9

[Charles]

For the benefit of future readers, you may wish to start new discussion posts when switching topics or asking new questions.

Now then:

Cobra's "for i in n" matches the indexes for lists and arrays:

t = ['a', 'b', 'c', 'd']
for i in t.count
    t[i] = t[i].toUpper

That simple code would break if the numeric for loop started at 1 and/or included t.count.

Furthermore, Cobra has slicing, copied directly from Python. Slices are open half intervals as well:

s = 'aoeu aoeu'
i = 5
# no ops:
s = s[:i] + s[i:]
s = s[:s.length]
# slicing i to j gives a string/list/whatever with length j - i
j = 7
assert 7 - 5 = 2
assert j - i = 2
s = s[i:j]
assert s.length == 2

Python style slicing works really well in practice and Cobra follows.

You'll notice that the numeric for loop follows a similar syntax with the use of a colon:

counter = 0
for i in 5 : 7
    assert i in [5, 6]
    counter += 1
assert counter == 2

You could say that Cobra favors zero-based indexing and open half intervals which fit well with each other and slicing.

Even business logic often benefits from open half intervals btw. Suppose you have a configurable pricing table for a price adder based on the length of a product:

Code: Select all

row | length min | length max | adder
----+------------+------------+--------
  0 |          0 |         10 | $0.00
  1 |         10 |         15 | $0.50
  2 |         15 |            | $1.00


The check for a matching row should be "length >= min and length < max"; note the < rather than the <=. This avoids overlaps which would be ambiguous. Note that using <= with data like 9.99 is dangerous because it can result in gaps.

I'm just adding this last example to further show that open half intervals have their place in computing independent of Python and Cobra.

Getting back to the design of the Cobra language, this is one of those situations where a few different pieces fit together and the explanation for why they look the way they do involves considering them all together.

Is there a right-inclusive numeric "for loop" syntax in Cobra? And if not, could there please be for the reasons stated?

You can slap a "+1" on the end which is two chars. Isn't that sufficient?

Is this coming up for you due to your class that supports 1..N inclusive, or because of certain algorithms or what? Knowing more about the use cases would be helpful.

Thanks to nerdzero for his comments as well. I had started my response here before his was posted. His comments about the tie-in to Python are obviously correct.