Cobra Forums

eric.sellon wrote:Obviously it is very important to allow access to platform-specific libraries. However, writing portable programs is important too. This portablilty is obviously achieved with having standard parts to the language (especially the standard library). Picking the contents of the standard library greatly impacts what Cobra third party libraries get written. I would suggest that part of the standard library is written in Cobra and comes with the front end and is pulled from a common directory by the back end. Other parts will be implemented in a platform-specific manner (possibly with the use of third-party libraries like CPython using tkinter) and will be provided by the back end. I'm thinking Cobra.Core for pure Cobra stuff, Cobra.Standard that will mix Cobra with native platform implementation and Cobra.StandardExtended that is most likely pure native platform implementation. Also a back end would have to provide all of Cobra.Standard to be considered a basic Cobra platform. Implementing Cobra.StandardExtended would allow it to be considered a full-featured Cobra platform. For example, sorting algorithms might be in Core or Standard while Web and GUI namespaces might be in StandardExtended. The GUI one makes a good example: it could be implemented with WinForms in .NET/Mono, with Swing on the JVM, with Cocoa for Objective-C, and with a third-party library (such as Qt or something built on top of SDL) for C++.

Yes we need a portable library so that you can write a Cobra program that runs on .NET, JVM, ObjC, etc. Of course, we won't exclude access to native libraries since they are important and since users may have legit reasons for not wanting to use the portable libraries. Such reasons could include:

-- User just wants to use Cobra to replace C#/Java/ObjC/etc. and is not looking to learn a new library.

-- User is writing UI-intensive code which is often done best with platform-specific libraries.

-- Cobra portable library will be incomplete for some time.

Regarding namespaces, it's not clear that "Cobra.Core" means pure Cobra and "Cobra.Standard" means things that must be implemented on each native platform. Nor does it seem important to me to pass that delineation on to the user. Also it seems that could change over time. Maybe a class starts out being pure Cobra but then it's determined that a custom/native implementation on each platform will greatly increase performance. Making that change would imply moving it from one namespace to another.

Regarding things like a GUI lib, a web app server, etc. I'd really like those to be separate projects so they can have their own release schedules, dev teams, etc. and so that people can download what they need. We can certainly endorse key projects on the Cobra web site if we find that users want "de facto choices" for things like "build a cross platform GUI", etc.

Now in addition to the differences in libraries, what about the language? .NET and JVM have their differences, for example. I have more thoughts on this which I will post separately at some point.

I didn't mean to imply that the user wouldn't have access to the Platform's API. That's very important since that's most of our batteries.

What I really wanted to get at was trying to start the process of figuring out what would be available for every Cobra user. I agree that the standard library will be incomplete for quite a while. In support of that I was looking at starting the discussion of what namespaces to use and logical rules as to what goes in there (so that when adding new stuff to the standard library, there would be few questions as where to put it). What I suggested of pure Cobra here and mixed there, was just brainstorming aloud. I do think that these sort of things should all be in namespaces under Cobra to reduce collisions with Platform APIs.

I would like to create a document to start off as a straw man in order to show the organization of what is available to Cobra users based on the standard distribution. To get started with that I would like to get agreement in regards to starting namespaces and a couple thoughts of what we'd like in there. If I could get such a document created it could serve as a good reference for discussion (and eventually implementation).

Should this be pure Cobra? If not (and that's perfectly alright), how do we support back ends that we don't even know about?

One last thing: I suggest changing print to a function from a keyword like Python did. I like simplification and this simplifies the grammar slightly. I expect I'll get shot down on this, but I wanted to throw that out there.

I haven't pursued the Cobra standard library because I wanted to pick up more experience with the JVM libraries and the JVM back-end. I felt that otherwise I would end of favoring the .NET libs too heavily. But if you want to proceed on sketching this out, that's up to you. Re: namespaces, I like the .NET structure such as:

Cobra
Cobra.Text
Cobra.IO
Cobra.Collections

etc.

We don't need a separate Cobra.Collections.Generic because we have generics from the beginning.

I'm not clear on your question "...how do we support back ends that we don't even know about?". I think the answer is that each back-end has the responsibility to implement non-pure portions of the standard library. But maybe I'm not seeing your real question.

"print" is quite convenient and when I heard that Python was changing it to a function, I was surprised. I was even more surprised when I heard the reasoning, none of which was compelling.

Regarding simplifying the grammar, well we could also get rid of "using". We could remove properties and use methods like Java. We could remove if(,,) expressions. And so on. But Cobra is not a minimalist language.

Thanks for the thoughts and raising issues.

Chuck wrote:I'm not clear on your question "...how do we support back ends that we don't even know about?". I think the answer is that each back-end has the responsibility to implement non-pure portions of the standard library. But maybe I'm not seeing your real question..

Actually that was part of my question and your answer lined up with what I wrote in my quote in the first post of this topic. The other question in it is (sort of) a spill over from the other topic that the reference quote came from. Some of the bind phases (like uses and inheritance) are part of the front end and I wonder how platform-specific items will fare. Of course you'll find out with the JVM back end implementation.

I don't really have anything new to add. You've listed a viable namespace structure for the standard library. Perhaps others could chime in and suggest an odd function or two to include.

eric.sellon wrote:Of course you'll find out with the JVM back end implementation.

Yeah, that's exactly how things are proceeding--I'm using the port to find the problems rather than try to detect them ahead of time. If we were implementing Cobra for the first time and planning on two back-ends that might not be so smart. But we already have the compiler for .NET so here we are.

eric.sellon wrote:I don't really have anything new to add. You've listed a viable namespace structure for the standard library. Perhaps others could chime in and suggest an odd function or two to include.

This is another area where the compiler itself will help because it will need the portable library itself.

Chuck wrote:

eric.sellon wrote:Perhaps others could chime in and suggest an odd function or two to include.

This is another area where the compiler itself will help because it will need the portable library itself.

Yeah. That's a good point.