Attributes syntax change

[WaynePhillipsEA]

As discussed at length in twinbasic/twinbasic#835, the following syntax change has been agreed and due to come into force.

Old attribute syntax:

[ AttributeName (args) ]

New attribute syntax:

@AttributeName(args)

• for boolean attributes, "(args)" are optional (as they are right now)
• whitespace between the attribute name and the opening argument parenthesis will be removed by the prettifier
• multiple attributes on the same line are allowed, immediately following each other, or seperated by a line splitter character ":"
• attributes must appear BEFORE the intended target in ALL cases

Examples...

@Enumerator
Public Function NewEnum() As stdole.IUnknown
   ' ...
End Function 

@PredeclaredId : @ClassId("00000000-0000-0000-0000-0000000")
Class MyForm
   ' ...
End Class

@Serialize(True, "FriendlyName")
Public UnfriendlyName As String

Public Declare Sub MySub(@MarshalAs(LPWSTR)  ByVal A As String, _
			 @MarshalAs(Byte)    ByVal B As MyEnumeration)

NB. MarshalAs() is not a currently available attribute... this is just to show how we might possibly support inline attributes in future.

[mburns08109]

Question:

Given this rule:

• multiple attributes on the same line are allowed, immediately following each other, or seperated by a line splitter character ":"

and This example above:
Public Declare Sub MySub(@MarshalAs(LPWSTR) ByVal A As String, _ @MarshalAs(Byte) ByVal B As MyEnumeration)
Would this be valid syntax?

Public Declare Sub MySub(@MarshalAs(LPWSTR) : ByVal A As String, _ @MarshalAs(Byte) : ByVal B As MyEnumeration)

...or would that confuse the parser?
...and if not, then how will we eventually do this:

Public Declare Sub MySub(@MarshalAs(LPWSTR) : @ObsoleteAsOf("Version 3.0") ByVal A As String, _ @MarshalAs(Byte) : @ObsoleteAsOf("Version 3.0") ByVal B As MyEnumeration)

...assuming we eventually get Custom Attributes?

[Greedquest]

v1 blocker

_{Presumably we don't want to keep the old attributes around if we do the new syntax, since that will just be confusing to have 2 ways to do the same thing, and we may want to reuse those [square brackets] down the line for something else. Will break existing tB code to remove old attribute syntax therefore must come before v1}

[fafalone]

Is it only enum item descriptions prompting this syntax change? Because I've thought up several alternatives that while a little clunky just for enums would avoid this syntax change for all attributes. I much prefer the brackets.

[WaynePhillipsEA]

I think at this stage we need to also (re-) consider the effort required to change this now. Let's just sound out alternatives, although bear in mind we probably don't want to re-open the whole debate 😭

[fafalone]

Ok, some proposals for enums:

1. New attribute: [ ItemDescription(index, string) ]. Multiple attributes are allowed, they can be one per line:

[ Desciption("Description of enum itself)" ]
[ ItemDescription(0, "First item") ]
...
Enum foo
   Item0
...
End Enum

Or combined, following the existing protocol for multiple attributes.

2. Detect [ Description() ] is used on enum, and parse as quoted list: [ Description("Item0", "Item1", ... ]

3. New Attribute [ EnumDescriptionUseComments(Position) ]. Just use comments in existing enum as descriptions. Position would inform it which to use:

Enum foo
    'Above
    Item0 'Adjacent
    'Below

Bonus here is VB programmers already have a lot of enums commented this way, so would have a much easier time adding them. Downside is this would be more difficult to transition to external sources for localization. The other two would use whatever method is implemented for regular [ Description() ]

Could probably think of more, and of course maybe these could be better named.

[WaynePhillipsEA]

I guess the question on my mind is, is it likely that we will ever want any OTHER attribute, other than Description for an enum member? If it's likely that there isn't any other use case for attributes in this context, then that does simplify the problem somewhat.

To expand further on my thinking... the chances of breaking back compat would be really very slim if we had the parser only accept the [ Description("") ] attribute syntax in this context, allowing [ AnythingElse ] to be treated as a regular enum member, for back compat.

Potentially, if we wanted to allow a little more scope for future flexibility, we could probably also safely say that anything that contains parenthesis would be considered an attribute in this context. e.g.[ Restricted(True) ] or perhaps [ Hidden(True) ] would be parsed as an attribute. Again, I would think there's very little real world code that would trip us up with back compat problems doing it this way.

[fafalone]

Even if we did, option 1 would be available; any attribute could be organized per item.

What about a generic?

[ ItemAttribute(Name, Value) ]

---

If we did just want to enable it per item like in Type... what if we required an affirmation? Only parse that way if [ EnableItemAttributes ] was specified for the enum? Then the documentation for that attribute would make it clear you either couldn't have members using [ ], or that any [ ] item matching an attribute would be interpreted that way.

You know, I bet this is pretty similar to the conversation that led to PtrSafe... when tB is dominant 20 years from now, "Why do we need this useless thing?" "Because in ancient times..."

[EduardoVB]

I never liked the "[ " I mean the spaces after the opening and before the closing of the square brackets, but it seems very established already, and perhaps there is a reason for that.

[WaynePhillipsEA]

I think it needs to be consistent with the rest of the language attributes ideally, so keeping it as [ Description("")] would be ideal. Did you see my edited proposal about detection of parenthesis to determine attribute vs enumeration member?

Having an [ EnableAttributes] on the parent enum could indeed work too.

[WaynePhillipsEA]

I never liked the "[ " I mean the spaces after the opening and before the closing of the square brackets, but it seems very established already, and perhaps there is a reason for that.

This is due to parser auto-correction where it adds spaces for some syntax. The extra spaces were never actually intended, and I should probably fix it so they get auto removed.

[fafalone]

@EduardoVB -- the spaces are just formatting. The prettifier often misses closing ones for me but it still works fine.

Re: Detection of parenthesis... I'm having the same thoughts about consistency with how things currently work-- does putting [ Hidden ] without parenthesis not enable it being hidden? It might be confusing to have () required, only in enums.

[WaynePhillipsEA]

Yeah the True argument is optional in other contexts, so if we want to keep consistency the extra attribute on the parent Enum sounds like the most valid option.

[EduardoVB]

I like the idea of only allowing Description attributes in Enums (if I understood that correctly).

Anyway, if there are other attributes in enums they should always have parentheses [AttributeName()] then that disambiguates that it is not an enum entry.

[mansellan]

Putting member attributes at the top level seems like a compromise too far IMO. In every other context, an attribute appears immediately before the thing it's attributing. I think its valuable to keep this paradigm.

Is it worth revisiting earlier ideas?

1. Using < and >
2. Using an "escape character"

1 Has the advantage that those characters are almost unused in VBx outside of expressions, so shouldn't clash. And a further advantage that it's the path VB.Net chose, so may be more natural to that target audience.

2 As an example, in C#, you can't use event as a parameter name, as it's a language keyword. But its also quite a common word that you might want to use. So they allow you to prefix it, so that @event is allowed. For example we could use @[Hidden], with the @ being optional except in the case of enum members, to avoid clashing with existing syntax. This option has the advantage that it could be generalised to other clashing edge cases. It has another (sizeable?) advantage in that it could be done later - keep the existing syntax, accept that it can't be used to attribute enum members yet, and circle back to it after v1.

(My preference is 1)

PS. Loving that the prettifier no longer adds spaces, that always looked weird to me.

[bclothier]

FWIW, this is a compile error in VBA:

Public Enum foo
    [Description("")] [Description("")]
End Enum

Therefore, if we say that an enum member can be only decorated with an attribute on the same line, that would avoid backcompat issues and avoid locking us into a set of attributes allowed for enum members.

[mansellan]

That could be genius, would also solve how to handle parameter attributes later on - they have to be on the same logical line.

[mansellan]

Although I'm still kinda fond of option 1... < and > seem under-used at the moment, and VB.Net already chose them for attributes.

Just thinking about conversions here - if a VB.Net developer saw familiar attributes like <Hidden>, they might feel more comfortable to explore further...

I realise that VB.Net (and .Net in general) is not universally popular here. But there's no point alienating potential customers for the sake of it. From the point of view of a VB.Net developer, the more familiar the syntax is on some random SO or blog post, the more likely they are to keep reading, and perhaps get involved.

[fafalone]

VB.NET developers would see [Hidden] and feel uncomfortable, but <Hidden> is comfortable?

C# uses [brackets]. How many .NET people are so isolated on the VB.NET side they'd be put off by brackets?

But requiring it on the same line is also breaking consistency. Everywhere else, you can put it on the line before.

I know none of these solutions for enums are perfect, but again, it's preferable to changing them for everything just to accommodate not having a special rule for enums.

[bclothier]

But requiring it on the same line is also breaking consistency. Everywhere else, you can put it on the line before.

Keep in mind that currently there are no inline attributes but it doesn't mean there won't be. We may want inline attributes for parameters which would not be able to adhere to the line above convention. At that point, the inline enum member attributes would be consistent.

[fafalone]

Isn't [TypeHint()] inline? But that makes sense; because it's not a one-element-per-line situation.

[Description()] is meanwhile allowed on types:

Type foo
    [Description("Member 1")] Member1 As Long
    [Description("Member 2")]
    Member2 As Long
End Type

[mansellan]

VB.NET developers would see [Hidden] and feel uncomfortable, but <Hidden> is comfortable?

Well not uncomfortable, but using their native syntax just makes things feel a bit more homely.

The main reason I suggest < and > though is that it seems likely to work for all places we'd want to use attributes, without using unpleasantries like escape characters. I can't see much downside, unless I'm missing something.

[wqweto]

If I have to be honest overloading square brackets for "quoted identifiers" and attributes is a poor decision with unneeded consequences provided that there already are attributes in VB.Net as prior art and these use < and > with no apparent down-sides.

As an example, in C#, you can't use event as a parameter name, as it's a language keyword. But its also quite a common word that you might want to use.

In TB you are supposed to use [event] and always get a token of type identifier from the parser i.e. disambiguate on keywords with the same name which a very good and straightforward idea. I might like to call my vars [if] and [then] for some fun reason.

[Greedquest]

I'm confused the consensus or final decision at the top of this post after lengthy discussion was to use the @ symbol

Surely the question here should be between do nothing and stick to square brackets as that is easier, or justify the swap to @ symbol which will be disruptive but valuable, as described at the top of this issue post? Why reopen the discussion on angle brackets? Sorry I have not been involved with much of the discussion around this so I may be missing something.

[mansellan]

Apologies, I know this has dragged on. But it's important to get this right before v1, as it would be breaking to change it afterwards.

I strongly believe a @ prefix, with no suffix, is not the best choice. Let's look at some examples:

@Hidden
@Description("Gets the count of collection items")

vs

<Hidden>
<Description("Gets the count of collection items")>

Both would work, so this is a cosmetic choice. But brackets (in this case angled) have the advantage of delineating both the start and end, rather than relying on an implicit end of token (here, a line break, potentially any whitespace for inlines in future).

Neither has any prior art in VBx. But < and > at least have prior art in other BASIC dialects, whilst @ only has prior art in Java (and derivatives).

[fafalone]

I just don't think < > offers enough advantages over [ ] to be worth the disruption. VB.NET uses them (C# uses [ ] ) and it makes things very slightly less awkward for adding descriptions and maybe hidden one day to individual enum items. In exchange every tB project written over the last 3 years has to be fixed (unless we're keeping both, which, please no).

I vote just go with one of the slightly more awkward options for enums alone and keep the [ ]. Is [EnableAttributes] that bad for what isn't exactly a common use and not exactly something beginners will be doing? I'd even prefer requiring they be inline or requiring () for enums only over changing at this point; tB could even pop up a note about it when it detects [] and " on the same line in an enum.

(De novo, I'd have prefered < > over @, but not over [ ] anyway. Too much like HTML for my preferences. Reminds me of the hell modern web design has become. And I think VB.NET users will still recognize them as attributes which they're comfortable with, but associate them with the 'more powerful' C#.)

[mansellan]

If there is ever a time to be disruptive, it's now. Before v1.

[ and ] were poorly chosen, as wqweto says, because they clash with existing VBx syntax. We should change this before v1, either for @ as in the OP, or < and >.

I appreciate this may be disruptive for existing users, but that's the nature of beta software, nothing is set in stone. Far better to finalise it now than to break a shipped release.

[mansellan]

We've had extensive discussions over many threads about this. V1 is near, so a decision will need to be made.

@WaynePhillipsEA

[fafalone]

They clash in exactly one scenario, providing individual attributes for enum members. There won't need to be a break after v1 because there's solutions that don't involve changing it for everything besides enums.

If it was just the disruption and the change brought a substantial benefit overall, yeah you can chalk it up to beta. But it's not; it's a very slight benefit for one specific, unusual usage, in exchange for an overall system that's anywhere from no benefit to worse for the other 99.99% of usages, depending on preference.

But yes this does need to be settled now.

[wqweto]

They clash in exactly one scenario, providing individual attributes for enum members.

The syntax in ambiguous for UDT members too and for something as simple as procedure parameters. Using square brackets for attributes prevents these to appear before regular identifiers like enum entry names, UDT entry names, parameter names and every other language construct which does not have a dedicated "introductory" keyword (e.g. dedicated Function, Type, Module, etc. keywords)

It's not possible to overload square brackets here unless attributes use some other symbol inside the square brackets to disambiguate e.g. prefix with @ like [@attrib] or suffix with parens like [attrib()]. Overall too much hassle for something which has already been dealt with in VB.Net. It's like coming up with new syntax for generics instead of using (Of Type) or whatever VB.Net is using. Why?

[fafalone]

How is it ambiguous for UDT members? [ ] isn't allowed in variable names; [Description()] is already available for them and works fine.
Procedure parameters too; [TypeHint()] works fine so I'd imagine Description would too; can you give an example of VB6 legal syntax that can't be used with the current attributes or ones without () in the future? If you can it's a very strong argument, but I'm struggling to think of anything besides individual enum members.

Also again my reply to VB.NET is C#. C# uses [ ] for attributes.

[bclothier]

Just to note: there's also the matter of external names. I don't think they are featured regularly in VB6 but they are common in VBA projects especially with Excel or to less extent Access as the host. See this and that.

As long as the attributes are only defined on the signatures and not within the procedure body, there'll be no clash because external names can be only used within the body. But if we one day end up with local or anonymous procedures, that might make it possible to need attributes in the body, and that would limit the language's flexibility.

[wqweto]

How is it ambiguous for UDT members?

It is but Wayne got away with it by "anchoring" on As keyword probably and for parameter attributes even more shenanigans will be needed (counting consequtive identifiers, etc.) which might work for enum entries too if attribs are required to always end with closing parenthesis. This way closing parenthesis + optional whitespace + closing square bracket can be used as a distinguisher between an attribute and a quoted identifier provided that closing parenthesis is not allowed to end quoted identifiers which is not a big deal.

Yes, this is possible and not very disruptive for the language IMO. Limiting quoted identifiers, requiring parentheses on (ambiguous) attributes and so all this will allow keeping existing code intact.

[mansellan]

Yes, this is possible and not very disruptive for the language IMO. Limiting quoted identifiers, requiring parentheses on (ambiguous) attributes and so all this will allow keeping existing code intact.

I'm worried that we're talking about language disruption whilst we're still in beta. At this point, we should be thinking about how best to lay the foundations for the language going forward.

I appreciate that a lot of code may have been built on the beta release, but is it really worth compromising the base design to avoid rework? Perhaps a regex search/replace could fix up any breaking changes?

The key question should be: is [ and ] the best choice for the language? If not, we should change it while we still can.
The follow on question is then: What is the best replacement?

[fafalone]

Again, if it was only the disruption that would be one thing. It's not though. I think [ ] is the best option.

[mansellan]

@fafalone, I'm not following. Why do you think that [ and ] are the best choice for the future, given that they clash with existing syntax whilst other proposals don't?

[fafalone]

Both [ ] and < > are better than @ because they more clearly delineate the start and end. Combining more than one is really not good, Function foo(@TypeHint(x)@MarshalAs(LPWSTR) x As LongPtr) or Function foo(@TypeHint(x), MarshalAs(LPWSTR) x As LongPtr)?

Between the two of those, I think aesthetics have a nonzero value (if you're interesting in a lengthy pontification on why I think [ ] wins here, let me know lol) and just don't give such high importance to one single, unusual scenario where a special rule has to apply because of a conflict. So that's how I'd have resolve a day-0 conflict. Then with the disruption, it takes it from mostly preference to strong argument. Again, it's not that nothing can be broken now, it's just that invalidating all existing code in dozens of places is no small change you can just chalk up to 'it's beta'. For a change this big, < > would have to offer substantial benefits, not make one rare niche usage not even possible in VBx not require slightly special handling like attestation or requiring ( ) if we ever want to, for some reason, support [Hidden] or [Restricted] or some other default value-having attr on individual enum members, something that's not exactly on any wishlist I've seen.

[mansellan]

I guess it boils down to priorities. This syntax is new to twinBASIC, and has only just begun to find application. What happens when we want to apply attributes to parameters? Or lambdas? Or...

We've already seen an example of it not working in existing code, what happens when the language wants to expand?

[ and ] are poor choices because they already have semantic meaning in VBx, which has to be respected. < and > don't.

This is what betas are for - to try things out, find what works and what doesn't, and fix things before release.

[mansellan]

Let me put it this way... If Wayne had chosen < and > and code had been written for it, would you be advocating for [ ]?

[fafalone]

If you're hypothesizing about conflicts with syntax that doesn't yet exist, how can you suggest < > wouldn't be a conflict too? New syntax is just that-- new. It's designed to work with the existing ruleset. C# uses [ ] for attributes and has the features you describe, so it's not some global standard we'd be in conflict with. Lambas or whatever new feature would be designed to not conflict with existing syntax.

IMO you're still making way, way, way too much out of a conflict in a single scenario, that's also a potential new feature, but not in conflict with VBx compatibility, and I don't think there's any reasonable argument people will be inordinately confused or upset if they have to use [Hidden(True)] instead of just hidden in the single spot where it conflicts, attributes for individual enum members.

Let me put it this way... If Wayne had chosen < and > and code had been written for it, would you be advocating for [ ]?

Day one? Yes. Year 4? No, I wouldn't think the benefit outweighs the disruption.

[wqweto]

Btw, in rust they use #[Attrib()] with explicit # for no apparent reason but probably to make parsing easier.

Main benefit of < and > is ease of parsing, second one is prior art in VB.Net which might be a counter-argument :-))

[mansellan]

If you're hypothesizing about conflicts with syntax that doesn't yet exist, how can you suggest < > wouldn't be a conflict too? New syntax is just that-- new. It's designed to work with the existing ruleset. C# uses [ ] for attributes and has the features you describe, so it's not some global standard we'd be in conflict with.

C# used [ and ] for attributes from v1, and C# was entirely greenfield (other than a general idea of "make it C-like"). So they knew they couldn't conflict even though C# uses those symbols for indexers.

VB.Net didn't have the same luxury - one of its main design goals was to keep to familiar VB6 syntax, and thus not repurpose symbols. And they chose < and >, presumably so as not to clash. So far, it seems to have worked well.

Day one? Yes. Year 4? No, I wouldn't think the benefit outweighs the disruption.

I thought this might be an exaggeration, but I just checked and twinBASIC went public 1st March 2021, so yes we're about to enter year 4. Wow, time flies...

My point stands though - I appreciate (in both senses) that you've built a lot of code on the beta. But all being well, once twinBASIC goes live there will be vastly more code written and published on the internet. If there's a problem with the syntax, surely it's better to fix it now than post-v1?

Is it really that onerous to do a regex search/replace for [whatever] to <whatever> and ship a new version? I feel like I'm missing something here.

[fafalone]

VB.Net didn't have the same luxury - one of its main design goals was to keep to familiar VB6 syntax, and thus not repurpose symbols. And they chose < and >, presumably so as not to clash. So far, it seems to have worked well.

It did have that luxury. The syntax is in no way compatible with VB6. The complete lack of familiarity was and still is the primary complaint against it as a "successor" to VB. It's VB in name only.

You know, I'd wager more people are familiar with [ ] as an attribute-like notation of optional arguments in Intellisense/Object Browser than are even aware you can use it in the names of enum values.

Is it really that onerous to do a regex search/replace for [whatever] to and ship a new version? I feel like I'm missing something here.

Is it really that onerous to have a single, rare, scenario where you need to use () in your attribute? Once again, I feel like you're making a mountain out of the molehill of a the one single, very uncommon, still theoretical, situation of attributes for individual enum items without ( ). If it wasn't for this one single isolated situation where there's a potential future incompatibility with a feature almost certainly to be exceptionally rarely used, would you still be arguing for < >, and on what grounds?

[bclothier]

JFYI, VB.NET does not accept weird names for either the enum or enum members. It won't allow you to bracket the weird names even though you can bracket the normal name, so VB.NET already breaks the compatibility in this area.

This can be verified via .NET Fiddler:

Imports System
				
Public Module Module1
	Public Enum FooBar
		Foo
		[Bar]
		_Bizz
		[_Bazz]
		'[Fizz$] 'Won't compile
		'[Fizz Buzz] 'Won't compile, either
	End Enum

	Public Sub Main()
		Dim fb As FooBar
		For Each fb In System.Enum.GetValues(GetType(FooBar))
			Console.WriteLine(fb)
		Next
	End Sub
End Module

Thus, those wanting to migrate their VB6 to VB.NET with their funny enums are out of luck (not that they'd have far more problems beside this case). But more importantly, the example invalidates the rationale that they chose < > because of compatiblity.

[wqweto]

Btw, not compiling [Fizz Buzz] is ridiculous. Raison d'etre of quoted identifiers is free use of whitespace.

This means that enum's from regular VB6 code cannot be migrated in some cases.

[mansellan]

The syntax is in no way compatible with VB6. The complete lack of familiarity was and still is the primary complaint against it as a "successor" to VB. It's VB in name only.

I wasn't claiming that the two languages are equivalent, they're clearly vastly different beasts. Just that the operators (in fact most of the keywords) have similar (identical?) semantics in both, and that was by design.

Anyway, I think we've raised all relevant discussion points, over to Wayne to make a call.

[mansellan]

@bclothier I'm wondering if there's some underlying limitation of the CLR that causes that, or maybe it's just so that VB.Net can interop with other CLR languages.

[fafalone]

One last point to note I want to clarify, when I say "disruption"... I don't mean just the need to find/replace the user code from me and others (if you're inexperienced with RegEx it's a little more complicated because there's no simple way to catch all the endings), I also mean, how much is this going to delay v1 for Wayne to recode everything to use a different symbol, run the tests on it, update all the tB internal code... how many bugs/regressions will be introduced, how long will it take to fix those... I really doubt it's a simple regex for him. So that's part of what I mean by disruption; with that plus the user code; I just can't see resolving such a small, obscure potential future issue as worth it.

[mansellan]

Good point.

[mansellan]

I'm not so much worried about this particular obscure case, I'm sure we can find a way to work around it. I'm mainly concerned that other cases will emerge as attributes get enabled for use in more places after v1. My hunch (and it is just a hunch) is that angle brackets are a lot less likely to cause problems in the future, purely because they are valid in fewer settings in VBx (only in expressions?)

[mansellan]

Also, I'd like to apologise if I overheated this discussion, I meant no offence. I know everyone wants to make twinBASIC the best product possible.

[bclothier]

@bclothier I'm wondering if there's some underlying limitation of the CLR that causes that, or maybe it's just so that VB.Net can interop with other CLR languages.

Possibly but it doesn't matter if that was the reason, given that the sample code disprove that the compatibility was a factor in choosing the < > syntax for VB.NET. This section on escaped name seems to support the theory that compatibility wasn't the primary factor. Thus, I think that's enough to demonstrate that's not the primary reason VB.NET went with the < > for the attributes. The actual reason they chose the < > syntax is moot now that we've established it wasn't because of compatibility.

I'd like to apologise

Hey, we're professional dead horse beaters here! This is what we do! No apologies needed.

[fafalone]

I'm not so much worried about this particular obscure case, I'm sure we can find a way to work around it. I'm mainly concerned that other cases will emerge as attributes get enabled for use in more places after v1. My hunch (and it is just a hunch) is that angle brackets are a lot less likely to cause problems in the future, purely because they are valid in fewer settings in VBx (only in expressions?)

The big concern with that is inline attributes... right now we only have one, [TypeHint()]; is there a possible conflict if inline attributes are introduced to arg lists without ()? That would be a more significant issue as I definitely see the need to add [Out] in the future. But if it's just conflicts with new syntax-- again it wouldn't be a concern because any new syntax would be designed to work with the existing rules for the language.

Also, I'd like to apologise if I overheated this discussion, I meant no offence. I know everyone wants to make twinBASIC the best product possible.

I was worried about coming across that way too, but I think we've kept this entirely civil and issue focused... great debates like this where we explore all the issues in depth between people who want what's best for the language is how you get great solutions. So also sorry if I've come across that way, I just enjoy a good debate, you've raised a lot of good points too and I know you're also thinking about what's best for tB.

[mansellan]

Agree, I think this has been a lively but civil debate. Ironically, on a purely cosmetic level, I actually prefer square brackets, angle brackets for attributes just look... ugly (at least IMO).

[fafalone]

Not just that but more technical and unapproachable IMO; and that does matter a little in a BASIC language.

[mansellan]

I think I'm just paranoid about v1, that we'll make a wrong turn and regret it later. Maybe for this, maybe for something else. Maybe it'll all be fine. Certainly Wayne has the best view on all of this, he knows more than I could ever dream of knowing...

Maybe I just need to chill out :-)

Certainly I know that you've done wonders for twinBASIC @fafalone - at the last count you'd submitted more code to twinSERVE than anyone. Huge respect for your contributions.