TwinBasic

[VB6 Programming]

File I/O is now supported in twinBASIC with v0.13.30
Experimental support for the Encoding argument has been added to support UTF-8 and UTF-16 as well as ANSI.

twinBASIC are now looking at handling migration from a VB6 project (.vbp).
A VB6-compatible Forms engine, including GUI support, implementation of all basic controls and support for ActiveX controls, is expected (in Alpha) in February.

[yokesee]

good job twinBASIC

[VB6 Programming]

twinBASIC update:

https://nolongerset.com/twinbasic-up...ember-12-2021/

Highlights include the File I/O system reaching feature-complete status, an updated twinBASIC roadmap, and experimental text encoding support.

[Niya]

Olaf really can't help himself can he. Someone mentions VB.Net and he is just ready to pounce lol.

Interesting discussion on Tuples though. I don't use them much(though I should) but I think they are a great feature. There's just so many times where you want to return multiple values from a function and it just seems wasteful to define and entire class just for that one function. Tuples solve this problem.

[baka]

well, Wayne can add whatever he wishes, since he is the dev,
for me, I can already do that stuff anyway

Sub DoStuff(U As UDTtype)
U.Name = "MyName"
U.Age = 20
U.Income = 50000
U.Object(1) = "Plate"
End Sub

Sub DoStuff(B() As String)
B(1) = "MyName"
B(2) = "YourName"
End Sub

what would be the use? it just feel bloated and non-intuitive.

like this: max, min = maxmin(a, b)

we could just easily do:

Sub maxmin(Byval A As Integer, Byval B as Long, Min As Long, Max As Long)

[yereverluvinuncleber]

Olaf really can't help himself can he. Someone mentions VB.Net and he is just ready to pounce lol.

Actually, from experience I think that applies much more so to you Niya.

Personally, I would prefer if TB would constrain itself to what VB6 does at the moment. That should be the mantra. Introducing new functionality always introduces new complexity, bugs and more importantly, delays. Just make it work, fix the intrinsic bugs that will be created in any case and then only add new functionality when the product is usable.

We don't need tassles, bells, whistles, basket, foghorn &c. We just want a bike we can ride.

[Niya]

You know I really don't understand you guys. Do you guys want TwinBASIC to succeed or not? Like it or not, the programming world has changed since VB6's prime years. People are now programming with tuples, Async/Await. Functional style constructs are also becoming increasingly popular. This means, functions must be first class citizens to support higher order functions. Python is now being touted as the BASIC of the modern age, a language that is simple and easy to learn and it has all of these things. Simplicity is no longer an excuse to avoid these things. Modern programmers are not afraid of these things. If you want TwinBASIC to take off, then you must bring it up to the expected standards of the modern programmer.

I mean don't you guys want to see a world where TwinBASIC can crack top 10 on one of those indexes you guys like so much like TIOBE? This is what must be done for that to have a chance of happening. Don't you want a vibrant and thriving community akin to other communities like C#, Python and JavaScript? Then you must make the language attractive to the modern programmer. Don't you guys want 100 super talented people like Olaf to come into this community? This is how you attract that talent. You do not do this by artificially crippling your language to the point that it resembles something from the 90s.

One of TwinBASIC's core missions is 100% compatibility with VB6 and most of these things can be implemented without sacrificing that mission. Come on guys. Stop being so afraid of change.

[Niya]

Personally, I would prefer if TB would constrain itself to what VB6 does at the moment.

As per my post above, this is just a terrible idea if it's permanent. I really hope Wayne doesn't give into this sentiment.

[yereverluvinuncleber]

As per my post above, this is just a terrible idea if it's permanent.

You are the master of the misquote and I've seen you do this before.

I definitely said - "only add new functionality when the product is usable" and I explained my reasoning but somehow you fail to see 50% of what is said and only misquote in order to... ? well, frankly I don't know, is it to give yourself something to do?

Please, in future don't do that. It annoys.

[Schmidt]

Olaf really can't help himself can he. Someone mentions VB.Net and he is just ready to pounce lol.

That had nothing to do with .NET.
I'd just like it very much, when the language could remain free of unnecessary "features".

Interesting discussion on Tuples though. I don't use them much...

Nobody is using them much... (aside from a few special, often math-heavy areas).

Tuples are just "dynamically created Mini-Lists" (an aggregation, returnable from a function, or "storable in an outer List") -
and in VBScript/VBA/VB6 we already have the Array() function, to create such Tuples on the fly.

E.g. if your OuterList is a VB6-Collection, one can easily add (and later retrieve) tuples this way:
Dim OuterList As New Collection, Tuple
OuterList.Add Array(1, 2, 3)
OuterList.Add Array(4, 5, 6)
For Each Tuple In OuterList: Debug.Print Tuple(0): Next

All possible, due to the Variant-Type (which I consider one of the strengths of the language).

Olaf

[Niya]

That had nothing to do with .NET.
I'd just like it very much, when the language could remain free of unnecessary "features".

To be honest, I really don't agree with this mindset. I've alreavy detailed why about 2 posts ago.

Nobody is using them much... (aside from a few special, often math-heavy areas).

You are correct but for right now. They aren't that popular a feature but I will be lying if I told you I don't see them showing up more and more when I look up random snippets of code online in other languages. Personally, they are not a feature I'm willing to die for. I would be 100% fine without them. That being said, I think for the good of TwinBASIC, Wayne should not ignore this. Tuples might be necessary if he wants to attract modern talent to his product. Modern programmers expect these things. I think he should implement them.

I get that you guys have your own ways of implementing Tuple-like functionality with the VB6 syntax and base libraries but I cannot envision these young cats out here being enthusiastic about such a primitive way of doing things, especially if they come from environments like Python or C#.

[baka]

if people would skip TwinBasic just because theres no tuples they most be very narrow minded.

the reason I would pick TwinBasic is:

- it can replace VB6
- newer compile
- better optimized and faster
- fix DPI and other issues VB6 has
- eventually cross platform
- eventually fully 64bit

if TwinBasic would be:

- Identical to VB6
- tons of .NET & other languages functionalities
- fully support to tuples
- no cross platform
- no 64bit

I would just keep using VB6.

[Niya]

if people would skip TwinBasic just because theres no tuples they most be very narrow minded.

Tuples alone? No. But Tuples along with most other modern features, definitely yes. If all TwinBASIC aimed to be is just a perfect VB6 clone with no improvements to the language. I would not look it it twice nor recommend it to anyone.

[yereverluvinuncleber]

if people would skip TwinBasic just because theres no tuples they most be very narrow minded.

the reason I would pick TwinBasic is:

- it can replace VB6
- newer compile
- better optimized and faster
- fix DPI and other issues VB6 has
- eventually cross platform
- eventually fully 64bit

Just that...

I have my own list of improvements/additions but I would NEVER muddy the waters at this point and dare to introduce any of them as I want TB/RB to succeed. If that success is jeopardised by the addition of the multiplicity of such small improvements then that is a risk I am not willing to ask anyone to take.

Baka's list above would be in itself a phenomenal achievement.

[yereverluvinuncleber]

Tuples are just "dynamically created Mini-Lists" (an aggregation, returnable from a function, or "storable in an outer List") -
and in VBScript/VBA/VB6 we already have the Array() function, to create such Tuples on the fly.

E.g. if your OuterList is a VB6-Collection, one can easily add (and later retrieve) tuples this way:
Dim OuterList As New Collection, Tuple
OuterList.Add Array(1, 2, 3)
OuterList.Add Array(4, 5, 6)
For Each Tuple In OuterList: Debug.Print Tuple(0): Next

All possible, due to the Variant-Type (which I consider one of the strengths of the language).

Olaf, I love the way that you use the tools at hand to solve a situation, combination of brainpower and the understanding of the tool that you have to use in the first place.

I had always perceived the variant type to be one to avoid given my original intention to migrate my programs to VB.NET. However, I am beginning to revisit variants in the light of my less than positive exposure to VB.NET and the potential of the forthcoming replacement TB (and RB). Should I re-evaluate the variant type and take it off my naughty list? I have tried to avoid it when at all possible.

[baka]

the route for TwinBasic should be:


1. fully vb6 compatible
2. optimization of all vb6 functionality that need improvement
3. how to add features for different "upgrades" of core VB6 functionality (to keep legacy but also fix different issues VB6 has, like DPI aware)
4. how to easily switch 32 to 64bit. to differentiate between the 2 modes, such as API declaration, type declaration etc.
5. how to easily switch between 32/64/cross platform mode
6. add modern gui, that also help bridge the cross platform mode
7. add sound support, that also can be used in cross platform
8. add support for any monitor changes, this so we can easily adapt the code when monitor is changing resolution etc.
9. other feature that are needed for modern rad development that was not needed 20 years ago. and always keep in mind the cross platform compatibility

when all that is done, and we can start working on projects, that we can release in windows but also other platforms,
when the IDE is stable and the compiled executable is well optimized, at that point, other feature could be added,
now when people are using it, it will also be easier to tell what do we actually need.

like VB6, is done and we know the strong and weak points, and the workarounds to make it work when theres some issue.
so we already know what we would need for VB6. but Im not sure what we need in TwinBasic yet.

[Niya]

the route for TwinBasic should be:


1. fully vb6 compatible
2. optimization of all vb6 functionality that need improvement
3. how to add features for different "upgrades" of core VB6 functionality (to keep legacy but also fix different issues VB6 has, like DPI aware)
4. how to easily switch 32 to 64bit. to differentiate between the 2 modes, such as API declaration, type declaration etc.
5. how to easily switch between 32/64/cross platform mode
6. add modern gui, that also help bridge the cross platform mode
7. add sound support, that also can be used in cross platform
8. add support for any monitor changes, this so we can easily adapt the code when monitor is changing resolution etc.
9. other feature that are needed for modern rad development that was not needed 20 years ago. and always keep in mind the cross platform compatibility

when all that is done, and we can start working on projects, that we can release in windows but also other platforms,
when the IDE is stable and the compiled executable is well optimized, at that point, other feature could be added,
now when people are using it, it will also be easier to tell what do we actually need.

like VB6, is done and we know the strong and weak points, and the workarounds to make it work when theres some issue.
so we already know what we would need for VB6. but Im not sure what we need in TwinBasic yet.

I agree 100% with all of this. Don't get me wrong.

What I am saying is that you also cannot ignore some of these requests people are making like Tuples. As a fan of more modern language contracts myself, if I were active over there, I'd be pushing for making functions first class citizens in the language. I don't think I would ever want to use a language long term where this is not the case. I think a lot of people would over look it if it doesn't meet a specific standard which is based on what is already popular in other mainstream languages. TwinBASIC looks very promising so far with features like generics and multi-threading. I would hate to see it to stagnate and not keep pushing for new improvements.

EDIT:-

I'd further state that the only real justification not implementing a feature is such a case that violates the goal of 100% VB6 compatibility. The only potential language improvement I've seen so far that violates this is the removal of that garbage Set statement. The truth is most modern improvements would not prevent TwinBASIC from being VB6 compatible.

[baka]

yeah.

its an inspiration for the DEV, when people give feedback and comments and ideas.
right now I feel that the "improvement" should be about the essentials for VB,

such as "Decimal/LongPtr/LongLong" types, that I would need so I dont need to first declare as Variant and after that change its type to Decimal.
that I wouldn't say anything against. I would say: go ahead. since you are already working with data types, why not add a few more?

unicode and other modes, make the gui work with 24/32bit , well, anything that are about improvement of the core VB6 that is 20 years behind.
if VB6 would improve on its own, Im sure we would have all those things already. thats what TwinBasic should focus first.

but only, if the improvement are obvious and not much time-consuming. like: if the DEV is adding graphic rendering, why not just let it be 24/32bit immediately?
it shouldn't post that much extra work. and like the types, if he adds the VB6 types, its not that much extra work to add a few more.

I think theres an order of things, otherwise its easy you mess up, because theres no end of features, u can always find something new to add.
better stay in course and focus on the basics, since the important thing is to "migrate" all of us first, and we will do that when TwinBasic can do what VB6 can do.
after that we will be part of the ride and will give feedback and bug reports when needed.

[Niya]

yeah.

its an inspiration for the DEV, when people give feedback and comments and ideas.
right now I feel that the "improvement" should be about the essentials for VB,

such as "Decimal/LongPtr/LongLong" types, that I would need so I dont need to first declare as Variant and after that change its type to Decimal.
that I wouldn't say anything against. I would say: go ahead. since you are already working with data types, why not add a few more?

unicode and other modes, make the gui work with 24/32bit , well, anything that are about improvement of the core VB6 that is 20 years behind.
if VB6 would improve on its own, Im sure we would have all those things already. thats what TwinBasic should focus first.

but only, if the improvement are obvious and not much time-consuming. like: if the DEV is adding graphic rendering, why not just let it be 24/32bit immediately?
it shouldn't post that much extra work. and like the types, if he adds the VB6 types, its not that much extra work to add a few more.

I think theres an order of things, otherwise its easy you mess up, because theres no end of features, u can always find something new to add.
better stay in course and focus on the basics, since the important thing is to "migrate" all of us first, and we will do that when TwinBasic can do what VB6 can do.
after that we will be part of the ride and will give feedback and bug reports when needed.

I would say though, there should be a cut off point where it's too much. C# is an example of a language that is loaded to the brim with an unrelenting river of features. I don't think any language that derives from BASIC should go that far but it shouldn't remain where it was 20 years ago either. Tuples, Async/Await, easy mult-threading, higher order functions are just some of the more common things I think a modern language should have even if it's derived from BASIC.

[Niya]

But no-one group is saying that...

Olaf is. He doesn't want the language to be changed that much. Perhaps he would correct me on this but it seems to me that if he had his way, then they syntax would not change at all which is exactly what I think is a bad idea.

[Eduardo-]

My concern about new features is that...
OK, this assumes that RadBasic will succeed. I think Carles is making progress, but I don't have much information about that now.

So, at the moment we have something that is already working, and well (twinBASIC) and something that we don't know (RadBasic).
So, we can't "ask" for nothing on that basis now.

But assuming that RadBasic will succeed, I would like for the VB6 successors to form something like a "consortium", where they could agree on the language.
Of course I don't mean the I want identical products, but I mean as compatible as possible.
For example, if both languages will add tuples, do it with the same syntax.

twinBasic already added lots of new features and syntax, and some of us have been helping on that process (OK, personally I very little). We discuss things trying to find the best way to do something.
I think, "and what would Carles do?". I don't know, but I think that the best syntax for tW will also be the best for RB.

Carles already stated that his route is (like the ideas of yereverluvinuncleber) first to achieve full replacement of VB6 and only after that to introduce improvements and add new features.
But of course he will have to do that at some point (to add new things and syntax), so my concern is that both languages should be as compatible as possible and more important: the language itself should use same syntax.
That is my wish, of course, it is my opinion.

OK, it is still too early.
We'll have to wait until RB is available to the open, and if Carles sticks to the idea of not adding new features until the full replacement is achieved, until then.
But I wanted to express my concern, and my wishes (in advance, for that moment).

[yereverluvinuncleber]

I have always suggested something like the ECMA group but for BASIC. However, if you think about having Olaf and Niya on the same group or anyone similar with strong views it would be a continuous battle. You'd have to physically keep the .NOTters out of the room.

VB6 acts as the design for the basis of both products and we would hope that what is good for one is also good for the other. I believe that Carles' approach is the preferable one. It is both an approach and a goal combined and achieving such an early consensus is something that only a one man team can easily achieve.

Carles and the TB chaps have spoken but I think both of their heads will be down in the code trying to meet their milestones and too busy to work in concert on new functionality. Carles at least will have the benefit of hindsight when it comes to making any decisions on language features as the TB team will have spent their precious time working it all through.

[Eduardo-]

I have always suggested something like the ECMA group but for BASIC. However, if you think about having Olaf and Niya on the same group or anyone similar with strong views it would be a continuous battle. You'd have to physically keep the .NOTters out of the room.

I'm not talking about Niya and Olaf, but Wayne and Carles.
All the others (like us) can be proponent of ideas, express opinions, but don't decide anything.

They could add more people to the "management group" (the consortium) of course, if they want.

[yereverluvinuncleber]

I'm not talking about Niya and Olaf, but Wayne and Carles.
All the others (like us) can be proponent of ideas, express opinions, but don't decide anything.

They could add more people to the "management group" (the consortium) of course, if they want.

Yes of course but I was referring to an ECMA-type group that I had previously suggested. I realised from the outset that the idea was/is a non-starter.

[Eduardo-]

Yes of course but I was referring to an ECMA-type group that I had previously suggested. I realised from the outset that the idea was/is a non-starter.

If you put everybody there, yes.
But I didn't suggest that.

[wqweto]

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

[Niya]

My concern about new features is that...
OK, this assumes that RadBasic will succeed. I think Carles is making progress, but I don't have much information about that now.

So, at the moment we have something that is already working, and well (twinBASIC) and something that we don't know (RadBasic).
So, we can't "ask" for nothing on that basis now.

But assuming that RadBasic will succeed, I would like for the VB6 successors to form something like a "consortium", where they could agree on the language.
Of course I don't mean the I want identical products, but I mean as compatible as possible.
For example, if both languages will add tuples, do it with the same syntax.

twinBasic already added lots of new features and syntax, and some of us have been helping on that process (OK, personally I very little). We discuss things trying to find the best way to do something.
I think, "and what would Carles do?". I don't know, but I think that the best syntax for tW will also be the best for RB.

Carles already stated that his route is (like the ideas of yereverluvinuncleber) first to achieve full replacement of VB6 and only after that to introduce improvements and add new features.
But of course he will have to do that at some point (to add new things and syntax), so my concern is that both languages should be as compatible as possible and more important: the language itself should use same syntax.
That is my wish, of course, it is my opinion.

OK, it is still too early.
We'll have to wait until RB is available to the open, and if Carles sticks to the idea of not adding new features until the full replacement is achieved, until then.
But I wanted to express my concern, and my wishes (in advance, for that moment).

Well the number #1 goal above all else is VB6 compatibility. I think this could be achieved while giving most people what they want.

[Niya]

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

This would make for an interesting discussion. Is the Continue statement worth the incompatibility with projects that use Continue as a line label? I think it is but I'm curious to see any counter arguments to this.

[Eduardo-]

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

I don't think it would be difficult to parse, since labels go after a GoTo or a Gosub, and no more (AFAIK, but may be I'm missing something).
If the "Continue" is after a GoTo or a GoSub, then it is a label, and any "Continue" on that procedure means the label and not the new keyword.

But the parser should first search the whole procedure code to see if there is a "Continue" after a GoTo or a GoSub, because the label could be at the beginning.

I'm not sure if it worth the complication, but possible I think it is possible.

[yereverluvinuncleber]

If you put everybody there, yes.
But I didn't suggest that.

Nor did I.

[Eduardo-]

Well the number #1 goal above all else is VB6 compatibility.

Yes.

I think this could be achieved while giving most people what they want.

I have no idea what that means in the context. I was talking about agreeing on the same syntax for new language additions and improvements.

[Eduardo-]

Nor did I.

OK, then IDK what you suggested.

I think that having as many opinions (qualified ones) as you can get, the better.
But the decisions should be made by a few, namely Carles and Wayne.

[Eduardo-]

This would make for an interesting discussion. Is the Continue statement worth the incompatibility with projects that use Continue as a line label? I think it is but I'm curious to see any counter arguments to this.

I think it does, otherwise now in VB6 you have to use GoTo or to set variables and check conditions.

[yereverluvinuncleber]

The main proposition of TB is to be able to compile VBx code "as is" with minimal modifications. The other direction of code round-trip is non-essential IMO and I would very much prefer to see more extras implemented and generally going forward.

By stumbling upon *generics* in the early alphas of the compiler it was clear that Wayne's intentions were to bring VBx screaming into modernity whoever likes it or not.

Currently enhancing the syntax with new keywords will *always* bring incompatibility with old code e.g. when I recently migrated an old project of mine had to correct this innocuous looking line of code

GoTo Continue

. . . because Continue is already a keyword in TB and the parser is not clever enough to allow labels to match new keywords -- the extra effort is not worth it or it might be impossible to implement correctly.

The compiler has to decide if

Continue:

. . . is a label (as in VBx) or a logical line with two statements -- first a Continue statement and then an empty one?

cheers,
</wqw>

I think Carle's approach is simply cleaner and if it gets RB into a position to correspond to Baka's first list then it is a win for us. I can't comment on the technological approach of each team but if all else is equal and the speed of development is the same then RB's approach would seem to be the one that will get them to that point faster.

Wayne is very good to respond to queries, requests and considering new functionality but isn't that slowing him down from the core goals?

[Niya]

I have no idea what that means in the context. I was talking about agreeing on the same syntax for new language additions and improvements.

What I mean is they can give people modern features while still achieving the goal of VB6 compatibility. All I'm saying is that these two goals are not mutually exclusive.

For example, if I were to use TwinBASIC on a full time basis, I'd want to have higher order functions. It would be one of my biggest wants. I doubt that this would conflict with the ultimate goal of VB6 compatibility. Some people want Tuples and I've seen a whole lot of very interesting suggestions on their GitHub discussions and to my mind, I think most of them can be implemented without impacting the main mission of VB6 compatibility.

[yereverluvinuncleber]

OK, then IDK what you suggested.

I keep wondering why you keep bringing it up...

All else agreed.

[Niya]

I don't think it would be difficult to parse, since labels go after a GoTo or a Gosub, and no more (AFAIK, but may be I'm missing something).
If the "Continue" is after a GoTo or a GoSub, then it is a label, and any "Continue" on that procedure means the label and not the new keyword.

But the parser should first search the whole procedure code to see if there is a "Continue" after a GoTo or a GoSub, because the label could be at the beginning.

I'm not sure if it worth the complication, but possible I think it is possible.

Actually there is a solution. Micorsoft's solution to this was square brackets. In VB.Net if you wanted to use a reserved keyword as an identifier, you surround it in square braces like this:-

[Continue]

Something like this would probably work to solve this problem.

[Eduardo-]

What I mean is they can give people modern features while still achieving the goal of VB6 compatibility. All I'm saying is that these two goals are not mutually exclusive.

For example, if I were to use TwinBASIC on a full time basis, I'd want to have higher order functions. It would be one of my biggest wants. I doubt that this would conflict with the ultimate goal of VB6 compatibility. Some people want Tuples and I've seen a whole lot of very interesting suggestions on their GitHub discussions and to my mind, I think most of them can be implemented without impacting the main mission of VB6 compatibility.

VB6 backward compatibility and full replacement (of VB6 main core, I mean the IDE, compiler) is out of the question. Both have been totally clear about the point.

To enhance it, is also well explicitly set on both cases.
The difference is the path, while RB plan is to achieve the full replacement first, tB path is to add new features in the way, and from the beginning.

I say this based on what I read on their websites.

[Eduardo-]

Actually there is a solution. Micorsoft's solution to this was square brackets. In VB.Net if you wanted to use a reserved keyword as an identifier, you surround it in square braces like this:-

[Continue]

Something like this would probably work to solve this problem.

That won't work for providing backward compatibility.
The VB6 code is already written.

[Schmidt]

Olaf is. He doesn't want the language to be changed that much.

Nonsense.

What I want (doing compiler-development myself), is the developer to concentrate on 1:1 compatibilit first.
That's "hard enough" to do.

Only *after* that goal is reached, extensions to the language should be discussed.
(aside from a few things, which "come cheap" - as e.g. variable initializing in the Dim-Line).

And while discussing such extensions, one should not make the mistake of:
- "intruducing something new", which is already existing

And in case of Tuple-support, we basically already have "full compatibility, to how python handles tuples".
in python, you write:
SomeTuple = (1, 2, 3)
and you access "tuple-members" by specifying a zerobased index:
print(SomeTuple[0])

In VB we would do:
SomeTuple = Array(1, 2, 3)
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

So, one simple thing a compiler-dev could do (if the goal is, to make it "more python-compatible") -
is, to make the Array-Function specifier "optional" (which should not be that hard, when a comma-separated list is enclosed by parentheses).
So, that the "new VB" code could be written this way:
SomeTuple = (1, 2, 3) ' or Return (1, 2, 3) which TB already supports for function-results
and access it in a similar way (via ZeroBased Index:
Debug.Print SomeTuple(0)

Eh voila, python-compatible tuple-support in "new VB"...

As for the kind of new features I would like to see (or implement) in a VB6-successor,
I would always prefer to open it up to the "lower end" - so that it becomes more "C-like".

E.g. an easy way to pre-define Function-Declarations in a Const-Variable -
then passing this "typed Function-Pointer" along into Routines (as a nice, lowlevel way to support "delegates").

VB6 already is as a thin (COM-layer-supporting) abstraction on top of C/C++...
And I would like (in potential new features), when it would "open up a bit more to that lower level" -
(making it easier to access with less typing-efforts, supported by more compiler-checks).

Olaf