Cobra Forums

Posted: **Thu Dec 18, 2008 9:38 am**

I'll mostly be off of Cobra today (I have contract work and evening plans), but back on tomorrow.

Items high on my mind are:

-- Entering more tickets (feel free to enter those we have discussed).

-- Marking which tickets are crucial for Cobra 0.9.

-- That contract problem with invariants and derived classes. Still banging on a SmartEiffel sample to investigate how they treat the situation.

-- Axing the "is shared" requirement of "def main". (It's making my mind itch. :-)

)

-- Various syntactic relaxations and conveniences.

Posted: **Fri Dec 19, 2008 5:23 am**

Chuck wrote:-- Entering more tickets (feel free to enter those we have discussed).

Yes, I'll add a couple of them as soon as I have some spare time.

Chuck wrote:-- Marking which tickets are crucial for Cobra 0.9.

Is there a way to so from the Trac interface?

Chuck wrote:Axing the "is shared" requirement of "def main". (It's making my mind itch. )

May I suggest we change main to be a cue? This way it is more clear that we are not defining a regular method, but one with special meaning (entry point) and with some compiler magic going on under the hoods ("is shared" by default, command line args implicit).

class Program
    cue main        # "cue" indicates clearly that this is a special method
          pass

Chuck wrote:-- That contract problem with invariants and derived classes. Still banging on a SmartEiffel sample to investigate how they treat the situation.

I've installed Nemerle, they have contracts as well (the semantics are based on Spec#, or so they say). I'll write a test program to see how they deal with invariants and derived classes as soon as I can. By the way, I like the way Nemerle deals with mutability. By default, Nemerle's variables are immutable (equivalent to C# readonly variables). You have to explicitly declare them as mutable in order to modify them after they're initialized). I think this makes code more clear and readable.

Nemerle also has inference of the return type for private methods and anonymous methods, which its also a nice feature (they don't provide type inference in public and protected methods because they say it's a bad thing, which I agree with). Any chance we'll get that in Cobra someday?

Regards,
Manuel

Posted: **Fri Dec 19, 2008 6:15 am**

jonathandavid wrote:
Chuck wrote:-- Entering more tickets (feel free to enter those we have discussed).

Yes, I'll add a couple of them as soon as I have some spare time.

Chuck wrote:-- Marking which tickets are crucial for Cobra 0.9.

Is there a way to so from the Trac interface?

Yeah, I've already set up the milestone called "Cobra 0.9", but all the tickets are not in. It's not obvious because they call the link "Roadmap".

Chuck wrote:Axing the "is shared" requirement of "def main". (It's making my mind itch. )

jonathandavid wrote:May I suggest we change main to be a cue? This way it is more clear that we are not defining a regular method, but one with special meaning (entry point) and with some compiler magic going on under the hoods ("is shared" by default, command line args implicit).

The command line args are not implicit. If you don't define the args there are no args except through CobraCore.commandLineArgs (and Environment.something). Also, the "is shared" won't be added--your .main will still be an instance method. Instead, Cobra will create a separate class with main() that conforms to the virtual machine and calls yours. JVM, for example, is much more strict about the declaration, so this treatment is necessary if we continue to support no return type vs. int return type and args vs. no args.

Nevertheless, I've considered "cue main" but have not decided.

jonathandavid wrote:
class Program
    cue main        # "cue" indicates clearly that this is a special method
          pass
Chuck wrote:-- That contract problem with invariants and derived classes. Still banging on a SmartEiffel sample to investigate how they treat the situation.

I've installed Nemerle, they have contracts as well (the semantics are based on Spec#, or so they say). I'll write a test program to see how they deal with invariants and derived classes as soon as I can. By the way, I like the way Nemerle deals with mutability. By default, Nemerle's variables are immutable (equivalent to C# readonly variables). You have to explicitly declare them as mutable in order to modify them after they're initialized). I think this makes code more clear and readable.

Let me know as soon as your test is done.

Nemerle's immutable default has to do with it being a functional language. I'm not planning on immutable as the default in Cobra which is more in the vein of Python and C# and less in the vein of Haskell et al.

jonathandavid wrote:Nemerle also has inference of the return type for private methods and anonymous methods, which its also a nice feature (they don't provide type inference in public and protected methods because they say it's a bad thing, which I agree with). Any chance we'll get that in Cobra someday?

Regards,
Manuel

I agree with them on "no inferred return type" on the public and protected. And yes, to inference on the anonymous. It's not clear to me that private methods should have inferred return types. You could argue for it because the method is not externally used outside that class, or you could argue against it for the sake of consistency and in the context of partial classes. When writing one of the partials, you may feel like a consumer of the main class declaration similar to when subclassing.

I favor leaving any "def foo" methods as requiring an explicit return type.

Posted: **Sat Dec 20, 2008 3:08 am**

Perhaps we could look at another keyword ( or keyword and value) for such special handling and or placeholder-thing-for-adding-boilerplate-around
e.g

Code: Select all: ent main pass # expands ( on .Net) to def main is shared pass

'ent' is pretty specific to main as an entry-point though

'spec' - for (platform) specific or special
?other

Posted: **Sat Dec 20, 2008 1:37 pm**

I don't see an advantage to another keyword outside of "cue" and "def". I will probably stick with "def main" as it is not a cue for the object itself the way .init and .equals are. Also, the use of "main" is already a convention that many will recognize.

Posted: **Sat Dec 20, 2008 11:45 pm**

The name 'main' is a convention - its the other stuff around it that varies per platform
- marked as entrypoint explicilty '[entry]'
- access modifiers static/shared/public/private/....
- whether its takes an args list and how they are declared..
String[] args vs List<of String> args vs String[] args, Dict<of String, String> environ vs ...

As mentioned elsewhere its not really a cue and as a def you have to explicitly get its signature correct each and every time

An additional keyword allows the platform specific setups and the signature specifics ( for main) to be elided ( its mainly boilerplate)
and gives scope for providing elided boilerplate for any other constructs

Posted: **Sun Dec 21, 2008 3:52 am**

What about:
I understand what hopscc says but I still don't like the syntax "ent main", it somehow does not sound right to me. What about the following:

class SomeClass
    pro x from var

    cue init
        pass

    def f(i as int)
        print i

    entrypoint
        print 'this is equivalent to our good old main'

This fits in nicely with other special call members such as "invariant" or "test". It's more verbose than "def main" or "ent main" but also it makes more clear what this method serves for. I wish mainstream languages had taken this route long time ago, if you think about it "main" does not communicate much: "main what?".

Posted: **Sun Dec 21, 2008 6:49 am**

Q: main what?
A: main subroutine

Sure they could have called it "entry" instead, but they didn't and a lot of us have gotten used to "main" from C, C++, Objective-C, Java and C#. Even Python uses the module name '__main__'. It's like using "+" for concatenation. It's totally wrong, but it's too late.

While aspects of it vary a bit per platform, Cobra will absorb and generalize those differences like it will for other things.

Since we already have CobraCore.commandLineArgs and could add CobraCore.exit, I wonder if "main" should have no arguments or return type in Cobra.

Posted: **Sun Dec 21, 2008 7:42 am**

Chuck wrote:Since we already have CobraCore.commandLineArgs and could add CobraCore.exit, I wonder if "main" should have no arguments or return type in Cobra.

I realize that Cobra is not trying to emulate Ada, but for what it's worth, that's what Ada does. The main procedure is parameterless and has no special name (you must tell the compiler which procedure is your entry point). If you want to get at the command line you must use a library package. Similarly if you want to return a status code to the environment you must also use a library procedure (it's in the same package as the command line handling stuff).

Posted: **Sun Dec 21, 2008 1:15 pm**

Thanks. I'm always interested in what other languages do and I'm not familiar with Ada so that's interesting info.

Cobra Forums

Schedule and upcoming work

Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work

Re: Schedule and upcoming work