|
Re: Steve Yegge: What the Next Big Language Will Be
|
Posted: Feb 14, 2007 10:59 AM
|
|
> I was just browsing through the Cat site. Looks like it's > coming out great :)
Thank you! > > Yeah I know it sounds like I am reinventing the JVML or > > CLI but there are several key differences: > > > > - I am taking lessons from modern langauge research, > and > > not just emulating a 8086 processor (IMNSHO both the > JVML > > and CLI are not inspired designs, and are seriously > > outdated) > > It would be interesting to know more about your design > goals. Do you have a comparison between Cat, JVML and CIL > available?
No, but that is an excellent idea. > Also, I was browsing through the Cat language primitives. > How is native interop supported via Cat? I take it there > must be an instruction similar to pinvokeImpl in the CIL?
There would definitely have to be. This would be a Cat extension though, "Cat + interop". The core Cat language is designed for maximal portability, so that anyone who uses it has a certain minimal guarantee of portability and safety. Unrestricted interoperability completely blows the lid off of any guarantee.
However, I am in the planning stages of a safer interoperability system between binary libraries written in different languages. This would involve passing type information (including DbC style contracts), across DLL borders.
> Do you propose to allow stuff like pointer arithmetic for > languages that require it?
I wasn't planning on it. Cat is designed to be easily extended though, so I am sure that someone would introduce an unsafe variant which extends the core Cat langauge with pointer primitives. I would have no objection to that, but it won't be part of the core specification. Otherwis it would severely restrict portability, concurrency, safety, and efficiency.
I do however plan on extending a byte block data type, which will provide pointer like semantics inside of a memory sandbox. This will allow languages to offer pointer like semantics, but not unrestricted access to things like the call stack and evaluation stack.
|
|