VO specific keywords in Core dialect

[wriedmann]

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

[Chris]

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

[wriedmann]

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

[Frank Maraite]

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

[robert]

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.

Code: Select all

FUNCTION Start() AS VOID
LOCAL i as LONG
FOR i := 1 to 9
   IF i < 3
      ? i,"Small"
   ELSEI i < 6
      ? i,"Medium"
   ELSE
      ? i,"Large"
   ENDIF
NEXT
Console.ReadKey()

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

[wriedmann]

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

[FFF]

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

[Otto]

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

[Frank Maraite]

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

[Chris]

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