I'll let Robert give a more "official" reply to this, but here's my quick comment:
In general I agree, although I think everybody (including myself of course!) has a different opinion on what the Core should be like and what it should include and what not. It's hard to do it the way that everybody will be absolutely satisfied with it. Specifically about ACCESS/ASSIGN, I also feel that they should not be part of the Core dialect.
On the other hand, though, I just checked my code in XIDE: Because I had written most of that code (as VIDE back then) in vulcan, even before we had added support for the PROPERTY keyword in the vulcan compiler, my code is full of ACCESSes and ASSIGNs. If ACCESS/ASSIGN was not supported in x# Core, then I would had needed to convert about a thousand of those ACCESS/ASSIGN into PROPERTY when recompiling the IDE code with x#...And most probably this would be the case for other people as well, so at least personally I am glad I didn't need to do this
I asked because VO/Vulcan compatible code with access/assign statements would be needed to compiled using the Vulcan or VO dialect. XIDE of course is a special case as it may be the only large Vulcan application that was moved over to X# in the Core dialect.
My own Vulcan libraries and applications (that are using also access/assign) would be never compile in the Core dialect as they make heavy use of arrays and codeblocks.
I do it with a method named getInstance(). I think this tells better, what really happens.
Then, we compared both our applications. My 'GCR NAS Basistool' seems to be a little bit bigger then XIDE It followed what they call the 'core dialect' even in Vulcan times. I eliminated all these dirty things since I started in Vulcan 2008. This way I had a true 64it with no reference to the Vulcan DLL's app in Vulcan. Together with the many tests (oops) it was a very good test case for X#.
We have not officially decided on this, as you can "guess" from the response from Chris.
1) We can make certain keywords optional at the Lexer level, and include them based on the dialect selected.
At this moment the Lexer recognizes 4 letter abbreviations of keywords when in VO mode, and only accepts complete keywords in Vulcan and Core mode (with the exception of FUNC, PROC, LONG, SHORT and PROTECT)
You do not see the difference in the VS editor but the following code will compile in VO mode and will not compile in Vulcan or Core mode because of the ELSEI keyword.
FUNCTION Start() AS VOID
LOCAL i as LONG
FOR i := 1 to 9
IF i < 3
ELSEI i < 6
2) We can enable/disable rules in the parser based on a dialect. We have done that for the vostruct and union rules in previous builds. These were only recognized when VO or Vulcan was selected. The VOSTRUCT, UNION and MEMBER keywords were recognized in all dialects but had no meaning outside VO and Vulcan.
This had a strange side effect however, because the error messages produced by the parser were not always clear.
In the current build the rules are always recognized in all dialects, but a descriptive message is shown that VOSTRUCT or UNION are not supported in the Core dialect.
3) We were aware that some people (Chris for example) were using lots of assignes and acceses in their code. Forcing them to use the new syntax would make the switch to X# difficult.
4) We are also recognizing the ARRAY, DATE, USUAL etc keywords in the Core dialect and producing an error message that the feature is not supported. When we would not do that the message produced by the compiler would be less clear.
The message is now:
Feature 'DATE' is not available in the selected dialect Core
and would become:
The type or namespace name 'DATE' could not be found (are you missing a using directive or an assembly reference?)
So what would you recommend ?
Examples of keywords and rules that could be "omitted" from the Core dialect:
xBase Types: ARRAY, DATE, CODEBLOCK, USUAL etc
UNION, VOSTRUCT, MEMBER
BEGIN SEQUENCE .. END, RECOVER USING, BREAK
XSharp Development Team
If you really have good arguments why in the ideal situation some language constructs are not wanted in the Core language than eliminate them.
However, you can do that in a less painful process:
- announce what you want to do
- introduce a warning e.g. in version 1.1 of the compiler.
- describe what the better syntax is.
- provide if possible tooling (like a macro or Resharper e.g.) to change the unwanted syntax to the desired one.
- kill the feature e.g. in version 2.0.
I already bore the consequences of wrong choices in our software too long and am glad I finally now can change some of them.
What Otto said: at the end the core dialect should be clean.
As I understand right, it is ever possible to switch from Vulcan to Core forth and back. In XIDE it's easy. Everyone who wants to go to core can do, test and then switch back to eliminate remaining issues. The VO/Vulcan dialect is the save backdoor until the transforming is finished.
Leaving these keywords leads to issues like Wolfgang described. So skip them as soon as possible.
It's easy to switch between x# dialects also in VS, it's just a combobox property in the project settings window.
As I said also to Wolfgang, yeah, I mostly agree about Core being as clean as possible, but I am really not looking forward to spending all the time needed to replace my 596 (just counted them) ACCESS/ASSIGN pairs into PROPERTY! (I agree it would be nice to do it, but I'd prefer spending the time in more productive things..)
Personally, I am leaning towards a different solution, to introduce another dialect in between Core and VO/Vulcan. Core would be the cleanest possible dialect, without ACCESS/ASSIGN, FUNCTION/PROCEDURE etc, the new dialect would include those, but without any dependence on runtime files and the VO/vulcan dialect would stay as it is right now. That should probably keep everyone (including myself ) satisfied, but it really is something for the future, right now the highest priority is to finish the last bits remaining to allow compiling existing code in x# with no changes at all.
changing all ACC/ASS pairs to properties has led my to learn about headers.cfg .
Your solution sounds good to me. I hope it's not not much work for Robert and does not introduce unwanted side effects. But in case of ACC/ASS, I would leave this also in the clean dialect. I see this as an cosmetic issue, not a technical one. And people, who want to use the pros of properties have to change it either.
It's the compiler that is the most important and difficult task, and thankfully we're very close to the finish line (100% compatibility) now. Once the compiler is finished on that regard, everything else is a lot easier to implement.
About the runtime, we know exactly what we need to do and how to do it, after all it's us that we've already done it (and fixed it) in the past already once. With the compiler, we had a lot of unknowns, a lot of things to learn (Roslyn) and unexpected obstcles, while with the runtime things are a lot more straightforward.
yes, the compiler for sure is the most complicated thing. I feel I could contribute to the runtime or to the RDD - but contributing to the compiler or the VS integration? These are things a lot above my programming skills!
I may be a decent application programmer, but building a compiler is a different thing!
Therefore I can only congratulate your group to what you have accomplished in this year - it is really great!
wriedmann wrote: Therefore I can only congratulate your group to what you have accomplished in this year - it is really great!
I second that.
I hope you don't feel we are pushing to hard in entire different directions.
You are (from what I see) a successful and smooth operating team. If the requirements\wishes come in too fast, then you are still the only one that can make the decisions about the (order in the) backlog.
Thanks for your nice words! Yeah, the four of us have known each other and/or worked together for a long time know, so that helps a lot. Please everybody keep your suggestions/wishes/feedback coming, they are both motivating and helpful on deciding on what's the best direction to follow..
wriedmann wrote: I agree that a "clean" dialect would be a desired thing
now the interesting question is: what exactly is "clean"? Nothing left, what might remind Vo?
nothing left, what is not supported in .NET framework, and is transformed under the hood by the compiler.
Best sample may be access/assign, replaced by the properties by the compiler, and maybe there are other things that are better to not support anymore in new code.
I would say: clean does not supports things that are better to not use in new code.