Quote:

Perhaps because an 'old-fashioned' BASIC is just what it is: a great stepping stone into the world of programming. If you introduce more structure/OO stuff in it, surely an advanced coder will be able to do much nicer things with it, but a complete beginner (especially youngster) will not be very keen on learning the language anymore. ... If MSX-BASIC would have looked like this when I was a 5 year old, I would never have coded a single line of MSX-BASIC on it. Beginners want the 10 PRINT "HEY, THIS WORKS! ": GOTO 10 stuff So please, no declaring variables, block-if, procedures, functions or o.O in the default BASIC. It is very likely to scare people off. A more structural, powerful BASIC might be a great second step in the world of coding tho

You are right, snout, except for you were most likely not able to read that code when you were 5 years old!

Quote:

Something as 'forward compatibility' is not in my dictionary. I could be wrong, but I doubt it ...

Huray for WikiPedia http://en.wikipedia.org/wiki/Forward_compatibility

I didn't say it right though. MSX2 is backwards compatible with MSX1, but MSX1 is not forward compatible with MSX2. Which would be the same with a new MSX3 BASIC. MSX3 would be backwards compatible with MSX2, but MSX2 will not be forward compatible with MSX3. That was what I meant to say. Sorry for the mixup, but you've got a new word in your dictionary at least

Quote:

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? ;-))))))

[D-Tail]: Why shouldn't it be feasable? Typically, this type of command would be used in direct mode. After the startup, if you are in program mode, i.e. you are typing in the BASIC lines, LIST a-z wouldn't show variables and the associated values, even if you would declare them by DEF INT/SNG/DBL/STR. But after the first run, BASIC has enlisted the variables and associated the values of all variables found in the lines executed. And now, you'll get the list of all variables the interpreter encountered during the run. Of course, there may be some variables not in the list because they weren't encountered because the interpreter didn't execute the lines they're in. In the LIST command I propose, if you don't specify a type, the command should list every variable of that name regardless of its type. There's also no need to introduce a new token for it, because the already existing LIST command only allowes line numbers as arguments. So the interpreter can determin what it should do by determine whether the argument is a line number or a letter. (Does anybody know if Sinclair-BASIC allowes variables to be arguments of the LIST command? As far as I have read long times ago, in Sinclair-BASIC, you could do GOTO X, where X was a variable containing a line number.)

I think this command would be very useful to understand programs written by others or to debug porgrams regardless if they are made by others or by yourself. And you would get a list of used variable names and their current content very quickly, avoiding naming conflicts. Yes, MSX-BASIC is still quite cool for smaller private applications.

By the way, wouldn't it be good to automatically add the user name and the date and time of a quoted text?

Actually what about a BASIC compiler?
I mean a true compiler that produce ASM code that can be
manipulates assembled by an assembler and executed
independently from the the basic, in msx dos for example...

XBASIC is nice but for true applications...

@Bart: cool, so forward-compatibility does exist ! I should have googled for it ...
Since I already learned something today; could anyone also tell me howto do the pinguin-smiley ?

BTW: a BASIC-Compiler which produces ASM-source would be cool, but I would prefer the BASIC (or better: JS/VBS) with inline ASM instead. Compiler-generated ASM is not always easy to understand, and it would probably still be quite sub-optimal compared human-typed ASM. And human-modified ASM code would not be reflected in the BASIC source.

You mean ? Just : and )

I thought I already tried that ... strange, must be getting sleepy then ... thanx !
But seriously, since everybody seems to have a different view on things, shouldn't we have a poll about it ?
And is someone really thinking about creating a new language/environment or is the matter pure fictional ...

Quote:

But seriously, since everybody seems to have a different view on things, shouldn't we have a poll about it ?

About the BASIC-compiler?

Quote:

And is someone really thinking about creating a new language/environment or is the matter pure fictional ...

I thought about that long times ago! It was something similar to Forth! Forth is a very cool language best suited for homecomputers, especially 8 bit systems. There once was a homecomputer called Jupiter Ace similar to the ZX81 using Forth as ''default'' language, i.e. with Forth in ROM.

Just several minutes before I logged in today I thought about proposing if we should create a new language for MSX for use as a default language right available after startup. But I think that language should be different to VBS (Visual BASIC Script?) or JS (Java Script?), because they're PC languages. We should create a special unique MSX language, so we can step out of Microsofts shadow. We also should create a new special operating system for that language and for MSX of course not resembling existing ones but taking some ideas from them for convenience.

Wouldn't that be cool?

Quote:

Just several minutes before I logged in today I thought about proposing if we should create a new language for MSX for use as a default language right available after startup. But I think that language should be different to VBS (Visual BASIC Script?) or JS (Java Script?), because they're PC languages. We should create a special unique MSX language, so we can step out of Microsofts shadow. We also should create a new special operating system for that language and for MSX of course not resembling existing ones but taking some ideas from them for convenience. Wouldn't that be cool?

Yeah, let's create something that's completely new and incompatible with anything we know!

I think it's a relativily small step to go from msx-basic to qbasic .. and qb is already an interesting beginner-lang.

Quote:

Yeah, let's create something that's completely new and incompatible with anything we know!

There are several thousand languages all around the world, most of them are said not to survive the century just started a few years ago. And there are lots of people inventing completely new languages never intended to be spoken at all -- except maybe from the inventer itself -- just for fun, as you can see at www.langmaker.com.

So, why not creating something completely new? It need not to be incompatible, it can base on the MSX-BIOS and we can take some features from existing MSX software. If you e.g. run Turbo Pascal on your MSX, would you consider it as incompatible?

Everybody really seems to have a different idea of what kind of language there should be...

How about this: When MSX is started traditional MSX BASIC compatible BASIC is launched to maintain compatibility. There is anyway new commands to load either extentions to this basic or totally new command set/language.

Extending BASIC with own commands is already possible, but extending BASIC with current hook system slows down the whole BASIC. (that is already too slow)

There are also these CALL commands, but they are even more slow and I don't think that writing CALL in front of every new command is nice.

10 COLOR 15,0,0:CLS:KEY OFF
20 EXTLOAD"MP3LIB.EXT"
30 MP3LOAD"Wolf_-~4.MP3":PRINT"Cool Music!!!":MP3PLAY(255,0,-1,128)
40 A$=INPUT$(1)
50 MP3STOP(0)
60 EXTUNLOAD "*"

10 LANGLOAD"BF.LNG","HelloYou.BF"

HelloYou.BF:
>+++++++++++[<++++++++>-]<-.>++++[<++++>-]<+.-------.>+++++
[<++++>-]<-.[-]>++++++++[<++++>-]<.>+++++++++[<++++++++>-]<
+.++++++++++.[-]>++++++++[<++++>-]<.>+++++++++++[<++++++++>
-]<+.----------.++++++.---.[-]>++++++++[<++++>-]<.>++++++++
+++++[<++++++>-]<.-------------.++++++++++++.--------.>++++
++[<------>-]<--.[-]+++++++++++++.---.[-]+[>,-------------]
>+++++++++[<++++++++>-]<.>+++++++[<++++>-]<+.+++++++..+++.[
-]>++++++++[<++++>-]<.[-]<-[<-]>[++++++++++++++.>]+++++++++
+.

Quote:

Everybody really seems to have a different idea of what kind of language there should be...

Yes! But compatibility doesn't mean that BASIC is the only language to be used on MSX!

Quote:

How about this: When MSX is started traditional MSX BASIC compatible BASIC is launched to maintain compatibility. There is anyway new commands to load either extentions to this basic or totally new command set/language.

If you use a disk drive, then MSXDOS executes a AUTOEXEC.XXX-File. I don't know, what has the higher priority, the AUTOEXEC.BAT or AUTOEXEC.BAS file, if there're both on the startup disk. But if there's just AUTOEXEC.BAT, this file will be executed. So startup doesn't always end up in BASIC, even so the MSX is still compatible. So I didn't understand why AuroraMSX complained about lacking compatibility.

So: When MSX is started and there's no disk-/hard disk-/USB-drive or cartridge with higher priority autoexec file traditional MSX BASIC compatible BASIC is launched to maintain compatibility.

Quote:

Extending BASIC with own commands is already possible, but extending BASIC with current hook system slows down the whole BASIC. (that is already too slow)

Yes, also because far calls are involved. The CALSLT routine takes about hundered bytes or so for performing the change of slot in my MSX1. If there are extended slots, then the routine calls itself recoursivly. I hope that the slot-ID to primary and/or secondary slot register assignement can be made by additional logic in the OCM. If not, we can implement this by modification of the VHDL source. In this case, even MSX1 BASIC would run faster, if it uses code accessed by interslot calls.

Quote:

There are also these CALL commands, but they are even more slow and I don't think that writing CALL in front of every new command is nice.

Yes! I think that call commands also involve CALSLT and therefore slow down the execution time. Yes, CALL in front of every new command isn't nice! But with that, you instantly get aware of the new commands!

nyyrikki: a call that does something is not the same as programflow and programming-style ..

Or do you have a suggestion to gain something like:

IF <condition>
'blahblah
'blahblah
'blahblah
ENDIF

using hooks?

Quote:

I think it's a relativily small step to go from msx-basic to qbasic .. and qb is already an interesting beginner-lang.

Can you tell us about qBASIC?