TOPIC:

Hello,

what about VO specific keywords in the Core dialect?

IMHO things like access/assign should not be permitted in the Core dialect, and therefore reserved words like "instance" should have no special meaning there.

I have come to this when I tried to write a singleton class - and in most implementations the property "Instance" refers to the singleton object itself.

The property can be declared of course as @@instance, to be consistent with C# samples, but it is not ideal.

Please take this not as request or wish - it is more a question.

Wolfgang

Hi Wolfgang,

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

Chris

Hi Chris,

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.

Wolfgang

Hi Wolfgang,

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#.

Frank

Wolfgang,

Good question.

We have not officially decided on this, as you can "guess" from the response from Chris.
Some thoughts:

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.

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 ?

Robert

Examples of keywords and rules that could be "omitted" from the Core dialect:
GLOBAL
DEFINE
xBase Types: ARRAY, DATE, CODEBLOCK, USUAL etc
UNION, VOSTRUCT, MEMBER
INSTANCE
BEGIN SEQUENCE .. END, RECOVER USING, BREAK
INIT Procedures
FIELD
HIDDEN
_DLL FUNCTION

Hi Robert,

thank you for taking the time to answer.

Unfortunately I haven't seen all these con's - so it may be better to let the keywords as they are.....

Sorry!

Wolfgang

Robert,
1) didn't know that this abbreviation worked in VO - wouldn't miss it
2) sounds reasonable
3) i like Accesses/Assigns...
4) seems a sensible error message, better leave this as is.
my .01
Karl

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.

jm2c.
Otto

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.

Frank

Hi Frank,

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.

Chris

Chris,
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.
Frank

Hi Chris,

I agree that a "clean" dialect would be a desired thing, but as you wrote, there are other priorities now - the runtime and the RDD IMHO are at the top of the list.

Regarding access/assign, I think they could be replaced automatically by an XPorter module or n XIDE plugin - doing exactly what the compiler does not under the hood.

Wolfgang

Hi Wolfgang,

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.

Chris

Hi Chris,

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!

Wolfgang

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.

Otto

Hi Otto, Wolfgang,

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..

Chris

wriedmann wrote: I agree that a "clean" dialect would be a desired thing

Wolfgang,
now the interesting question is: what exactly is "clean"? Nothing left, what might remind Vo?

FFF wrote:

wriedmann wrote: I agree that a "clean" dialect would be a desired thing

Wolfgang,
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.

Wolfgang

As specific language dialects (Vo/Vulcan etc) exist, I think is better to have a pure .NET Core dialect for the new projects.

George