boriel Wrote:You can't. :?
Remember when you commented about strings not having fixed length? Well, that's a problem when you want to initialize them.
Uh uh. And I was indeed looking at a pile of text setups I was thinking of using, too :-)
(Wait until I start wondering how to do text compression inline...)
boriel Wrote:Anyway, I will implement string initialization (just a hidden LET a$="XXXX") for the DIM.
That will do it. Right now we're left with hard coding
Code:
DIM p$(3)
LET P$(1)="Inky"
LET P$(2)="Blinky"
LET P$(3)="Winky"
etc.
Ugh. At least a hidden "LET" will be less ugly.
Quote:I will also implement READ & DATA. I've think up a way to implement them. The hardest case will be something like this:
Code:
READ x
DATA VAL a$ * INT(RND * 7) + 1
definitely UGH. There's a good reason no Spectrum basic compiler I ever saw worked with VAL. I wouldn't worry too much about this. If the programmer tries to do that and not use a function, they are doing something far too weird! VAL$ was one of the most useless functions. (I think it was used for recursive functions perhaps?). VAL is not all that useful either. It tends to be used in weird cases - such as the one you listed above - mostly. We can probably live without those.
It's also used to make programs smaller - VAL "23" is shorter in basic than just 23 because of the 5 byte numerical coding. We don't really have that issue here, since I doubt the x86 computer exists that can't hold a text file that would make more than enough to fill a spectrum!
Almost all READ and DATA statements seem to be used to fill arrays, or fill memory - like setting the UDG. We already have a very good way to make the UDG thing work by poking the UDG location to an array. (Very neat, that, incidentally). And we can pre-fill numerical arrays, so good there. Strings, not so much.
The only other thing I ever used READ and DATA for was for putting odd graphics on the screen by poking it directly. Far easier to hold the data in an array and use the advanced poke you have now...
That said, it would be nice to have READ and DATA working for compatibility purposes. Did you ever talk to Dunny (who wrote BASin) about connecting this compiler with his programming environment? He was, at some point, working on a built-in compiler; but it never materialised...