classes!

Class Window

  Private

    Field A
    Field B#
    Field C%
    Field D$

    Function MyFunction(Look!, Rare!, Neverbeenused$, W00000T#)
    End Function

  End Private

  Public
    Field F!

    Function MyFunction2$(ForSale#, Amount_of_Boblets)
    End Function

    Function MyFunction3#(Ebay_comission, Tax)
    End Function

  End Public

  Constructor(x,y,z=1)
  End Constructor

  Destructor
  End Destructor

End Class


M33P=ApplyClass(Window)

M33P.MyFunction3(1,2)

M33p.Destructor()

End

This can't be too hard to read for even the biggest C++ n00b. Perhaps it's slightly more typework, but it's -imho- way more clear and less cryptic. Without some sort of class-mechanism I don't see big/advanced apps to be made. Even if it's just for the datahiding and reusability.

Quote:

PRESET doesn't return a value, so it's not a function but a subroutine. Thus, parentheses shouldn't be necessary when calling PRESET.

Your're right, Arjan, PRESET doesn't return a value, so it's not a function. Clearly, its a subroutine in the most common sense. More precicely, its a procedure. (I only very seldomly used this statement!)

Quote:

What if you call a function, but you don't need the return-value. Should you call it with or without parenthesis? Should it actually be allowed to discard the return-value?

In this case, if you're programming in Pascal, you would use a procedure. If there're no arguments to pass to the subroutine -- regardless if it's a procedure or a function -- you need not specifiy a parameter list, thus no parentheses. You can, e.g. consider 'pi' as a function without parameters returning 3.1415. You also can consider it as a name for a numerical constant.

Quote:

In my experience, using parentheses for functions and subroutines would make it a whole lot easier to program (at least in VB, curse the COM interaction! )

In MSX-BASIC, LOCATE is considered a command, I guess. Thats why there aren't any parentheses. This command is implemented by a subroutine. Compare it with the PRINT statement. The difference may be only according to syntax.

Quote:

I'd also like to see a windowing system (I didn't add it to AdvancedBasic for nothing ). Would make it a lot easier to make editors with a GUI. Of course, you don't HAVE to use it...

It would be possible to improve MSX-BASIC in many ways, but would it be the 'classical feeling'?

For me, BASIC is a language well suited for small and medium sized programs (concerning to MSX),
so you need not doing much improvements. For applications beyond this, it's better to use Pascal!

Long variable names would be good, also labels and WHILE and UNTIL-loops. But wouldn't it violate the classic -- nostalgic? -- feeling? I think, there's no need to improve MSX-BASIC that way. It then stops to be BASIC! The only thing to be improved would be to add some nice debugging features, e.g. to list the variables with or without displaying its
current value:

LIST a-c, LIST a-, LIST x*, LIST a%, LIST a$,x$, LIST a-c,X$,d#-f#, also with LLIST respectively.

Thus, LIST a-z would list all variables, so you easily could find out which variable is not yet used.

Or TRON with specifying variable names, so that you'll get the values of this variables if they're encountered.

Any addition to MSX Basic would corrupt the backwards compatablity and will destroy the "nostalgic" MSX Basic, no matter what the addition is. So I think it's a bit weird to say debug options are good and while loops are bad...

Quote:

Any addition to MSX Basic would corrupt the backwards compatablity and will destroy the "nostalgic" MSX Basic, no matter what the addition is. So I think it's a bit weird to say debug options are good and while loops are bad...

I didn't say that loops are bad. Backwards compatibility is only affected if an already existing feature of MSX-BASIC would be redefined in a possible MSX3-BASIC. Otherwise the added MSX2 screen modes would cause MSX2 not to be compatible with MSX1. I also didn't say that MSX-BASIC is ''nostalgic'' but that some additions to MSX-BASIC maybe could destroy a ''nostalgic'' feeling while working with it.

I stick to my previous points: NO object orientation in our BASIC

Furthermore: more clarity to the dangling 'else'-clause of the if-then(-else)? statement, while is not necessary, as we have IF and GOTO

Tanni: the 'LIST a-c' things aren't feasible in BASIC, because all variable names, types and values are determined at run-time. A workaround for this is declaring them using DEF INT/SNG/DBL/STR, but I don't think this is what we want. I still think MSX-BASIC is quite cool, but sucks syntactically (MSX-BASIC 5.0 anyone? ;-))))))

If no OO .. then we stick to (relative) small apps... that's a choice ofcourse. But 'Basic' ansich is not something holy that should always be like the basics from the early 80's. The language evolves, and moving into OO territory is kinda normal in modern basics, on various systems.

Look at early QBasics compared to MSX basic, that QBasic originates from somewhere around '88 orso? It has block-if's, and all the other stuff you'd wish for.. (no OO however).. is QBasic blasphemious to 'BASIC' then?

Don't ask yourself 'what should a new MSX-Basic look like?'

Ask yourself this: "what kinda apps do I want to make with it, and how big will they be?"

wolf_: I know, that's what BASIC is for in the first place, isn't it ... The switch to C, PASCAL or assembly can easily be made on MSX. I'd rather think that each language has its purpose -- ASM for the real die-hards who want to create killer apps & demos that use every CPU cycle, C and (T)PASCAL for dudes who like to write apps and games with extra speed and ease of programming, and BASIC to get the job done quickly. Using NBASIC is a plus, BASIC programs will speed up greatly then. Struct-like things (from C) are maybe doable in MSX-BASIC, and I'd like to have it too. But complete OO-implementation is just too much (polymorphism/data abstraction/accessibility/etc).

Ok, those things you mention are evil, but a simple mechanism with private/public variables and functions would be very handy.

btw, again you are comparing 'basic' with the OLD basics ... wake up! Basic evolves too.

We're talking about BASIC here; Beginners All-purpose Symbolic Instructional Code !
Why not 'just' start with including KUN-BASIC on-chip ? KUN-BASIC supports inline ASM, is fast and - quite important - it already exists !

I agree with D-Tail, a new version of MSX-Basic with labels, classes and other new/OO features would ofcourse be nice,
but in that case why not make a real OO language like MSX-Java or MSX-C# straight away ?

Ofcourse BASICs do evolve, but don't tell me that VB.NET is a real OO language; and implementing some VBScript-like language anno 2005 is (IMHO) like designing a V8 engine with 50 hp. I assume you can't hack all these new features into the existing MSX-Basic code, so why waste time & effort creating a new BASIC - which syntax is considered deprecated - instead of creating a real OO language ...

Beginners don't want to mess around with line numbers, so a new MSX-BASIC should at least introduce labels (numbers could be labels too, for compatibility).

And actually, VB.Net comes really close to C#. Almost anything that can be done in C# can also be done in VB.Net. Biggest difference is that VB.Net code is more 'verbose'.

* Worships Serial KiLLa

Arjan: A workaround for working with line labels already exists: NestorPreTer. Check Konamiman's MSX Page to see how it works. Actually, I'm pretty much satisfied with the BASIC/MSXDOS2/NestorBASIC/NestorPreTer/Compass combo --
1) Make up a nice source file in Compass
2) Exit Compass, and use NPR in MSXDOS2 to compile the source to a BASIC ASCII listing
3) Go to BASIC, load the ASCII file, save it again with a BASIC header
4) Play

The only thing, which I can think of, is that steps 1-3 could be combined in one IDE orso... Plus that Compass/NBASIC/MSXDOS2 don't always work nicely together either. But the start is already there! wolf_: you should definately take a look at a decent NPR listing. I'd be happy to post one here

I think most important is a decent editor/debugger.
MSX2 Basic with some extensions and labels is ok for me.

[D-Tail]: a nice setup indeed! but real beginners prolly want to press a 'start' button and run the app directly as you're saying yourself already