INTYBASIC 1.2 problems

[freewheel]

 

I've resisted to implement C-like syntax. Instead I've made x=x+1 to be so efficient as x += 1 or x++

 

I actually agree with you. Mostly because this isn't C - but also because to be honest, incrementing by one isn't something terribly common in IntyBASIC. It happens lots with FOR loops, but of course you don't need to manually increment your variable there

 

I've always been a fan of very explicit instructions. Those little C shortcuts save a bit on typing but make code mildly less readable if your brain isn't in C mode. I just find that x=x+1 fits in with x=x+6 and x=y+6 and x=a+b. The shortcuts look somehow "different" in a quick scan. But that's just how my brain works.

[+DZ-Jay]

 

 

 

I've resisted to implement C-like syntax. Instead I've made x=x+1 to be so efficient as x += 1 or x++

 

I agree with Oscar on this. There is no ++ or += in BASIC, let's keep it simple.

 

-dZ.

[+DZ-Jay]

 

I actually agree with you. Mostly because this isn't C - but also because to be honest, incrementing by one isn't something terribly common in IntyBASIC. It happens lots with FOR loops, but of course you don't need to manually increment your variable there

 

I've always been a fan of very explicit instructions. Those little C shortcuts save a bit on typing but make code mildly less readable if your brain isn't in C mode. I just find that x=x+1 fits in with x=x+6 and x=y+6 and x=a+b. The shortcuts look somehow "different" in a quick scan. But that's just how my brain works.

 

 

Well, you lost me there. I think ++ and += are superior. Even the simple Pascal Inc() and Dec() functions are more explicit. To be honest, whenever you are teaching programming to n00bies from scratch, with no programming background, it is actually quite a task to explain that to increment a value you have to add to it and re-assign. The entire order of precedence and left-right-binding rear its ugly head. It is not as intuitive as you may think, especially for an operation that people naturally assume is a single step (Increment "x").

 

However, that is the path BASIC has taken, and I rather IntyBASIC follow it.

 

Whoever wants to can create macros. I've done so in P-Machinery: I've defined the following:

MACRO ++(x)
  (%x% + 1)
ENDM

MACRO --(x)
  (%x% - 1)
ENDM

MACRO ~(x)
  (%x% XOR $FFFF)
ENDM

Of course, the syntax in IntyBASIC is different.

[freewheel]

 

 

Well, you lost me there. I think ++ and += are superior. Even the simple Pascal Inc() and Dec() functions are more explicit. To be honest, whenever you are teaching programming to n00bies from scratch, with no programming background, it is actually quite a task to explain that to increment a value you have to add to it and re-assign. The entire order of precedence and left-right-binding rear its ugly head. It is not as intuitive as you may think, especially for an operation that people naturally assume is a single step (Increment "x").

 

It's intuitive to anyone who's learned basic arithmetic, but not programming. The concept of "increment x", in algebra, is still x = x + 1.

 

a = b + c

a = b + 5

a = a + 1

a += 6

a++

 

The last 2 stand out like sore thumbs, and yet they're all basic additions. Do the number of plus signs mean how much you're incrementing by? (Serious question I've been asked at least twice). And what the hell is +=? How does *= work, then? Is this some kind of exponentiation? (Again, been asked that before).

 

To people who learn assembler, or other older "pre-C" languages, sure - incrementing and decrementing are natural, logical operations. "Assignment" into values is also a concept. But "most people"? What's on the right becomes what's on the left. This may be different for younger folks who learn programming as they learn math, but definitely not when BASIC was designed.

 

Remember, I'm talking people who you have to spend an hour explaining the difference between "=" and "==". I won't even get into the confusion of ++x vs x++. Or why := always made me giggle a little - I learned Pascal grudgingly in school.

 

But it probably depends on an individual's brain. From a purely mathematical perspective, a++ and a += 1 looks like VERY different operations on the surface (some magical computer fuckery, essentially), even though they're not. And a += 2 and a = a + 2 also look rather different, even though they're really not (in terms of final result). When I start thinking of things in terms of how they compile (without an optimizing compiler), then yeah, they look completely different and should be treated as such. But using BASIC is supposed to allow us to avoid thinking about the low-level operations. It's designed for someone who learned grade 4 algebra and that's it. Which is still the majority of the population.

[+Tarzilla]

I still type := frequently enough to make boggle my mind.

 

I still remember Error 41 Unknown identifier or syntax error, mainly because I edited the error message in the message file and added F#CKING in caps after the Unknown part...

[intvnut]

 

It's intuitive to anyone who's learned basic arithmetic, but not programming. The concept of "increment x", in algebra, is still x = x + 1.

 

If you want to bring algebra into this... the biggest hurdle I've witnessed in someone trying to learn programming, was that statements like x = x + 1 are logical falsehoods in algebra, equivalent to the statement 0 = 1. Getting over the difference between assignment and equality, and the fact that variables in programming aren't anything at all like variables in algebra was an interesting hurdle that had never occurred to me.

 

Systems of equations in algebra are stateless. Procedural programming is all about mutating state. If I had known about functional programming at the time, I would have pointed the person I'm thinking of in this example in that direction... They didn't get 'for' loops either, but they got Excel just fine. (And Excel is a bit closer to functional, if you just stick to formulas.) And in Excel, putting the formula A1 + 1 in cell A1 is an error.

 

I guess disconnects like these are part of the reason Pascal and its variants used := instead of = to specify assignment.

 

 

As for whether the += and ++ operators are simpler or more complex... It really depends on your mental model. K&R themselves actually put it in the "unusual" column, but only partly, introducing them thusly:

 

 

C provides two unusual operators for incrementing and decrementing variables. [...] The unusual aspect is that ++ and -- may be used either as prefix operators (before the variable, as in ++n), or postfix (after the variable: n++). [...]

 

I guess you could argue that the only "unusual" thing they call out is the prefix/postfix nature. Other than that, they seem to think they're pretty natural operators. On assignment-operators, they actually put them in the "more natural" column:

 

 

Quite apart from conciseness, assignment operators have the advantage that they correspond better to the way people think. We say "add 2 to i" or "increment i by 2," not "take i, add 2, then put the result back in i." Thus the expression i += 2 is preferable to i = i + 2. In addition, in for a complicated expression like:

 

yyval[ yypv[p3+p4] + yypv[p1+p2] ] += 2

the assignment operator makes the code easier to understand, since the reader doesn't have to check painstakingly that two long expressions are indeed the same, or to wonder why they're not.

 

Now whether or not you agree with K&R, the fact of the matter is that they're arguing in favor of their own design decisions for C. I think C is cool, and I've been programming it for ~24 years. It comes very naturally to me. But it isn't BASIC.

 

As far as I'm concerned, BASIC could include these as extensions, and it wouldn't hurt the language. Folks who don't like them could simply choose to not use them. Or BASIC could leave them out, and it would still very much be BASIC. The latter approach is what nanochess seems to have taken here, and that doesn't bother me at all.

 

My point is, "what feels natural" and "what doesn't fit in" ends up being very particular to each person's experience, with less overlap than you'd expect. Witness this entire conversation.

 

I'll use myself as an example. For me, the += and -= felt really natural because I had programmed way too much two-operand assembly language by the time I had learned C. Compare x86's "ADD AX, BX" to C's AX += BX. Something tells me that that puts me far away from the center of IntyBASIC's target demographic.

Edited September 13, 2015 by intvnut

[intvnut]

I still type := frequently enough to make boggle my mind.

 

I still remember Error 41 Unknown identifier or syntax error, mainly because I edited the error message in the message file and added F#CKING in caps after the Unknown part...

 

:rolling:

 

I remember when I first transitioned from TurboPascal to Turbo C++, I would often leave the parentheses off of function calls that had no parameters in the C code. This, amazingly, is not a syntax error. But, it does give you the warning: "Code has no effect."

 

You run it, and sure enough, it does nothing! GEE THANK YOU FOR THAT F%ING REPORT. Why does it have no effect?!?

 

And if you have Pascal-trained eyeballs like I did at the time, you'll stare at it (in my case, sometimes for hours when I was first starting out) wondering why the F*#! it doesn't work.

[+Tarzilla]

I was still using TP3 for utility programming when I started what has been my job for the last 25 years (back then menu programs for Novell Netware, DOS based things etc) One day my boss is looking over my shoulder when I was compiling something and the:

 

Unknown F*CKING identifier or syntax error

pops up, after several years I didnt even notice it any more, meanwhile he is laughing out loud saying, "you shouldnt swear at work, this is a school district! Think of the children!"

 

Miraculously I found my last Turbo Pascal 5 folder, that has survived 20 years and uncountable number of hard drive and computer upgrades. This is not Turbo Pascal 3 where I did all the editing of error messages...

 

[Click to enlarge]

 

last compiled exe was 27/08/1999

[artrag]

Humm, I think I've spotted a small missing detail in warnings

 

If you define a constant

 

const x = 5

 

and after you use it as a variable

 

x = y +2

 

the compiler does not report any warning and allocated the latter X as it were a new variable....

 

PS

the test is evolving: no collision jet but you can fire bullets and choose enemies by 0 1 2 3 on the second controller

dzgorf.rom

Edited September 13, 2015 by artrag

[freewheel]

 

If you want to bring algebra into this... the biggest hurdle I've witnessed in someone trying to learn programming, was that statements like x = x + 1 are logical falsehoods in algebra, equivalent to the statement 0 = 1. Getting over the difference between assignment and equality, and the fact that variables in programming aren't anything at all like variables in algebra was an interesting hurdle that had never occurred to me.

 

Oh absolutely, that's probably the biggest mental hurdle when it comes to learning any language - that we overload things like the equals sign for assignment. Hell, just the fact that we always(?) use left-assignment is a bit of a mental hurdle. There's nothing intrinsically wrong with a language where you do the computation "first", and then assign it: b+c = a, for example. I can't think that I've ever seen this, but I'm sure someone's tried it.

 

 

 

As for whether the += and ++ operators are simpler or more complex... It really depends on your mental model.

 

 

Yup. And I can always tell people who either learned assembler early on, or at least became very comfortable with it later (folks like yourself and DZ being good examples). To you, having a separate increment operation (i++) just makes sense, because the native hardware supports this as a single operation. And having a+=b is the same as ADD A,B because of the inherent way in which we pass values into registers and such. There's an exposure into the underlying architecture here that just "clicks" in your brain. Mine too, to be honest, although it took a lot of years to really understand the "why".

 

But presuming we follow the standard programming paradigm that what is to the right of the equals sign gets assigned to what's on the left - and this goes far deeper than arithmetic; tons of object-orientation paradigms use this a la myObj = newObj(param)...

 

On the surface a = a + b is an addition and then assignment. It is no different to the casual programmer than a = b + c. There is no "short form" for the latter, so why is there a short form for the former? And extend this into anything non trivial. Once you're doing ANYTHING but just simple incrementing or adding to the "assignee" variable, you are always writing it out long form anyway: a = (x * 2) + (y --6) + func(value) or whatever. The short forms stick out and the traditional rationalization for them comes down to "well, they're more efficient in the compiled code". Which hasn't been true for a lot of years in most situations.

 

In case I'm not clear: I'm not arguing AGAINST them per se. In fact I use them constantly at work. I just think they miss the mark when it comes to what BASIC is.

[+5-11under]

 

If you want to bring algebra into this... the biggest hurdle I've witnessed in someone trying to learn programming, was that statements like x = x + 1 are logical falsehoods in algebra, equivalent to the statement 0 = 1. Getting over the difference between assignment and equality, and the fact that variables in programming aren't anything at all like variables in algebra was an interesting hurdle that had never occurred to me.

 

When I learned Basic (ZX80, ZX81), we needed to use a "LET statement", which made great sense, I thought:

LET X=X+1

[+DZ-Jay]

 

Yup. And I can always tell people who either learned assembler early on, or at least became very comfortable with it later (folks like yourself and DZ being good examples). To you, having a separate increment operation (i++) just makes sense, because the native hardware supports this as a single operation. And having a+=b is the same as ADD A,B because of the inherent way in which we pass values into registers and such. There's an exposure into the underlying architecture here that just "clicks" in your brain. Mine too, to be honest, although it took a lot of years to really understand the "why".

 

Actually, I was arguing what intvnut said first: that people without programming experience have a VERY hard time grasping some of these concepts because they are not intuitive or natural, and they most likely do not conform to their non-programming view of the world. That has been my experience trying to train others.

 

I don't feel comfortable with "x++" and "y += 3" because that's how I've used it in Assembly Language. I feel comfortable with it because, in my arithmetic-driven mental model, I think "Increment x" or "increment y by 3," and the symbols are just a quirk of the language that say the same thing. Contrast that, like intvnut said, to "take the value of y, add 3 to it, then assign it back into y," which is how I read "y = y + 3." That machine language happens to implement the former convention out of utility, is just icing on the cake.

 

Personally, I think that the nature of the language is verbose enough and things like "++" and "+=" will not decrease typing significantly. My biggest gripe with languages like Pascal and BASIC is having to "IF...THEN...ELSE...END IF" or "FOR x...NEXT x" all over the place. However, we're not about to start arguing for putting braces into IntyBASIC, are we?

 

-dZ.

Edited September 14, 2015 by DZ-Jay

[+nanochess]

 

However, we're not about to start arguing for putting braces into IntyBASIC, are we?

 

-dZ.

 

Better not to invoke the wrath of ancient gods discussing braces in IntyBASIC

[Kiwi]

 

Better not to invoke the wrath of ancient gods discussing braces in IntyBASIC

Opps, I was going to ask for braces next for the next IntyBASIC release to make it more like a C programming language.

 

I'm very very content with IntyBASIC. Please don't sic the ancient gods after me.

[+DZ-Jay]

Opps, I was going to ask for braces next for the next IntyBASIC release to make it more like a C programming language.

 

I'm very very content with IntyBASIC. Please don't sic the ancient gods after me.

And when we finally all settle on The One True Brace Alignment Format, lets tackle tabs vs. spaces, and vim vs. the world!

 

dZ.

[+Tarzilla]

Opps, I was going to ask for braces next for the next IntyBASIC release to make it more like a C programming language.

 

I'm very very content with IntyBASIC. Please don't sic the ancient gods after me.

As a guy who recently had to wear braces (on my teeth) I say NO to braces in IntyBasic. I'm sure if someone wants to create Inty-C then they are more than happy to brace to their heart's content, then be prepared to suffer the war of "proper { placement" that would ensue.

[+DZ-Jay]

As a guy who recently had to wear braces (on my teeth) I say NO to braces in IntyBasic. I'm sure if someone wants to create Inty-C then they are more than happy to brace to their heart's content, then be prepared to suffer the war of "proper { placement" that would ensue.

So, tell us, Tarzilla, are the braces on your teeth aligned to the statement, or to the block?

[+Tarzilla]

So, tell us, Tarzilla, are the braces on your teeth aligned to the statement, or to the block?

to the Malocclusion...

[artrag]

IntyC ?

It would never be a true C port due to hw limits.

IntyBASIC is a good compromise between high level coding and efficency

As basic has no reference (not a standard, only dialects) I'd add some twists but for now it seems to have all the essential tools needed for inty games (which usually are small and action oriented).

 

Maybe one thing could be (a bit more) useful in a framework where you have only 300 bytes of ram.

Local automatic variables in procedures/functions and parameters for procedures/functions.

Note anyway that local varables and parameters need stack management and a certain amount of complexity in the generated asm code that in turn becomes cpu overhead, so apart the extra work on the compiler (!) the result could disappoint more than one.

In the end, Oscar thanks for the great work, and do what you like

 

 

Ps

Yes you can have "compiled" local variables and parameters, but in this case their allocation is static so the ram is not reused

Edited September 17, 2015 by artrag

[Kiwi]

IntyC ?

It would never be a true C port due to hw limits.

IntyBASIC is a good compromise between high level coding and efficency

As basic has no reference (not a standard, only dialects) I'd add some twists but for now it seems to have all the essential tools needed for inty games (which usually are small and action oriented).

 

Maybe one thing could be (a bit more) useful in a framework where you have only 300 bytes of ram.

Local automatic variables in procedures/functions and parameters for procedures/functions.

Note anyway that local varables and parameters need stack management and a certain amount of complexity in the generated asm code that in turn becomes cpu overhead, so apart the extra work on the compiler (!) the result could disappoint more than one.

In the end, Oscar thanks for the great work, and do what you like

 

 

Ps

Yes you can have "compiled" local variables and parameters, but in this case their allocation is static so the ram is not reused

When I make a Colecovision games in C, I declare all my variable globally. I never use int variable since Colecovision is an 8-bit processor, and not a 16-bit. I usually only know functions provided in the cv_programming manual, and they usually call the BIOS function of the Colecovision. When dividing /8 /16 adds the shift functions to the project.

 

IntyBASIC is really awesome and able to use what I learned from smileBASIC used in Petit Computer for DS, and C programming to IntyBASIC. I don't think IntyC is necessary since IntyBASIC produce good result. Also, I don't have to deal with TOKEn issue for forgetting semi-colon.

 

Both can produce games, so that what's matter to me the most.

[+DZ-Jay]

IntyC ?

It would never be a true C port due to hw limits.

 

Careful, them are fightin' words!

 

I recall a couple of people said the same thing about an Intellivision BASIC compiler.

 

Anyway, I agree that it is not needed, and certainly it is not necessary to turn IntyBASIC into C.

[artrag]

Well a standard c compiler (think to the standard libreries) is such a huge work that I feel safe to say that none will ever embrace the idea of such a project.

Even in case you get such a compiler, pratically you would not able to compile a single existing C source, so why bothering with a standard language?

 

Different is if you want to port a subset of the language (IntyC--?) but than you can stay with intyBasic, that can be freely contaminated with any feature you like

[artrag]

About new features, what about a way to copy to a from the backtab ram a rectangle of tiles from and to an array in rom or ram?

[+DZ-Jay]

Well a standard c compiler (think to the standard libreries) is such a huge work that I feel safe to say that none will ever embrace the idea of such a project.

Even in case you get such a compiler, pratically you would not able to compile a single existing C source, so why bothering with a standard language?

 

Different is if you want to port a subset of the language (IntyC--?) but than you can stay with intyBasic, that can be freely contaminated with any feature you like

 

I have no interest in starting another silly argument with you, but I do not see why people can "contaminate" IntyBASIC with whatever they want, but wouldn't be able to do so with IntyC.

 

Anyway, I'm not saying a C compiler is coming, or that anybody should be interested in one. I'm just saying that the same words from your post were said for a BASIC compiler; yet here we are.

 

-dZ.

[+DZ-Jay]

About new features, what about a way to copy to a from the backtab ram a rectangle of tiles from and to an array in rom or ram?

 

You mean, a block-copy? I thought IntyBASIC had a statement for this... Oscar?

 

Updated: In reading the IntyBASIC manual, it seems that the SCREEN statement does this. You give it a label to your array, an offset, and the block dimensions in columns and rows.

 

I haven't verified, so can someone confirm?

 

-dZ.

Edited September 18, 2015 by DZ-Jay