Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
DIM issue
#1
Why does

Code:
DIM list(1) AS uByte => {24,2}

compile just fine, but

Code:
DIM p(1) AS String => {"Word","Word"}

Will not. I thought initializing arrays this way was a replacement for READ and DATA, which are not supported! I love being able to block fill an array at compile time with numbers. Can I not do the same thing with strings? How do I replace:

DATA "STRING","STRING","STRING" then?
Reply
#2
You can't. :?
Remember when you commented about strings not having fixed length? Well, that's a problem when you want to initialize them.

Anyway, I will implement string initialization (just a hidden LET a$="XXXX") for the DIM.
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

As you might see, this is an anonymous function :!:

Well, please, be patient.
Maybe we should move this to the "Wishlist" :?:
Reply
#3
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...
Reply
#4
britlion Wrote: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...

I'm very sure, Dunny does not want to use a extended Basic in BASin. But I'm working on a editor for ZXB using Scintilla. It can now load, save, compile and add Graphics mode characters,... It will be extended, but I still have no working lexer...
------------------------------------------------------------
http://lcd-one.da.ru redirector is dead
Visit my http://members.inode.at/838331/index.html home page!
Reply
#5
Did you put this into any of the later versions?

Right now I have a program that sets up its internal text with a huge list of:

Code:
Let name$(1)="Name"
Let name$(2)="Name"
Let Name$(3)="Name"

Etc.

This works, but yeow it looks ugly.


Also for UDG - is there a cleaner way of putting them in than CHR$(144) ?
Reply
#6
I'm sorting out the phorum.
I will move this thread to Wishlist sub-folder. There's also a new Bug-report folder, BTW Wink
Reply


Forum Jump:


Users browsing this thread: 2 Guest(s)