IntyBASIC compiler v1.0 crunchy&tasty :)

[intvnut]

Perhaps some kind of Lint style warning could be added to warn of variables used before initialisation.

 

I'll think about it.

 

 

Heck, what about a 'strict' mode (like Perl's 'use strict') that requires you to declare variables before using them? (Or at least warns.) That would have caught this very quickly.

 

That's perhaps easier than a "used before assigned to" lint warning, especially as the compiler is a one-pass translator without control flow analysis (at least as I understand it), and program lines may not be reached in the order they appear.

 

Years of compiling with -Wall -Wextra -Weverything-I-can-think-of-and-can-be-bothered-to-deal-with in belt-and-braces languages like (most recently) C++14 have made me lazy in a strange way I guess. :-) I have to do more work up front to be warning and error free, but I can rely on the compiler being incredibly picky and sensitive about 1 character typos. That particular omission, waffletimer vs. waffle1timer, wouldn't have even made it past perl's 'use strict' without an error.

 

 

(If you're curious, here's the warning flag list I use for jzIntv / SDK-1600. WARN is for C code, WARNXX is for C++. I used to use more flags, but some have migrated into -Wall, -W, or -Wextra. C++ has fewer than C because not all are supported / needed under C++, such as -Wstrict-prototypes. There's some add'l flags I need to add someday, such as -Weff-c++, which is damn hard to get 100% on.

.

 WARN    = -Wall -W -Wextra -Wshadow -Wpointer-arith
 WARN   += -Wbad-function-cast -Wcast-qual -Wc++-compat
 WARN   += -Wmissing-declarations -Wmissing-prototypes
 WARN   += -Wstrict-prototypes -Wmaybe-uninitialized

 WARNXX  = -Wall -W -Wextra -Wshadow -Wpointer-arith
 WARNXX += -Wcast-qual -Wsequence-point
 WARNXX += -Wc++11-compat

.

Yep... belt and braces. AS1600 still has a few warnings, owing to its heritage as a pre-ANSI K&R C program. But it's mostly (entirely now?) const-correct!)

Edited June 22, 2015 by intvnut

[freewheel]

While in a complex environment I like forcing explicit variable declaration, there's something very liberating about being able to just use a variable when I damned well please. Maybe my subconcious thinks I'm somehow making them "local" by having any mention of them restricted to one function or something. It's just nice to not have to jump back and forth in code if I choose to rename something (I find I do this a fair bit as I run out of variables and start re-using them depending on context). Or I'm just exceedingly lazy.

 

Just please don't take this all the way down the "=" != "==" C path. For the love of all that is holy.

[intvnut]

While in a complex environment I like forcing explicit variable declaration, there's something very liberating about being able to just use a variable when I damned well please. Maybe my subconcious thinks I'm somehow making them "local" by having any mention of them restricted to one function or something. It's just nice to not have to jump back and forth in code if I choose to rename something (I find I do this a fair bit as I run out of variables and start re-using them depending on context). Or I'm just exceedingly lazy.

 

Just please don't take this all the way down the "=" != "==" C path. For the love of all that is holy.

 

 

Please understand my proposal appropriately. I think something like Perl's 'use strict'/'use warnings' is useful in two ways. (1) It's off by default. (2) It can be turned on by those who are interested. And maybe it provides a tool for chasing bugs once your project gets more complex than you were expecting.

 

As for the = vs. == thing... that's one part 'context-free grammar' and one part 'all expressions are interchangeable, and comparison and assignment are both operators in expressions.' The same hack that lets you say "a = b + (c == d)" requires different operators for = vs. ==. IntyBASIC already crossed that syntactic bridge and rejected C's approach¹ here. :-)

 

I'm just asking for something strictly optional like this:

.

   USE STRICT
   DEF var1, var2, var3, etc...

.

We already have to DIM arrays after all.

 

__________________________________

¹To be fair, it's not strictly C's approach. Pascal started down this path before C with = vs. :=. This whole mess may have originated with ALGOL, but I'm too lazy to look.

Edited June 22, 2015 by intvnut

[+DZ-Jay]

I believe Microsoft BASIC had that as "Option Explicit" (or was it Visual Basic?). I agree with intvnut that such an compiler option is very useful.

[freewheel]

It's absolutely useful. As is strict typing on variables. I'd also be interested in C-style function brackets, return values from procedures, and a whole host of other things.

[+Tarzilla]

 

I'm just asking for something strictly optional like this:

.

   USE STRICT
   DEF var1, var2, var3, etc...

.

We already have to DIM arrays after all.

 

__________________________________

 

 

I concur, it would be useful in this exact way without having to overcomplicate it. Out of habit I always define all my variables at the top, in IntyBasic's case it is just a bunch of variable assignments and DIM's for any arrays. The issue in the waffle thread that brought this up is minor and happens to me frequently enough courtesy of old age but misspelled variables are now the first thing I look for when something goes wonky.

 

I use Notepad++ with the default VB style and it definitely helps catch these kind of typos but is no replacement for USE STRICT

[Click to enlarge]

[+DZ-Jay]

It's absolutely useful. As is strict typing on variables. I'd also be interested in C-style function brackets, return values from procedures, and a whole host of other things.

 

Are you being facetious? Because I would imagine adding a warning for uninitialized variables to the compiler should be a lot easier than designing some of those features into the BASIC language.

[intvnut]

 

Are you being facetious? Because I would imagine adding a warning for uninitialized variables to the compiler should be a lot easier than designing some of those features into the BASIC language.

 

Look up TI Extended BASIC (Read starting at page 182) and the original QuickBASIC (and its free step-child QBASIC). I believe both had subroutine support with local variables, call signatures and return values.

 

That said, those things generally require dynamically allocated scope—ie. automatic variables. And that is the main feature most BASICs lack. If you can handle automatic variables (whether heap allocated or stack allocated or some other scheme), then a whole bunch of things open up. TI-XB and QBASIC showed that.

 

Right now (and likely 'forever'?), IntyBASIC is statically allocated. I agree that adding warnings such as what I asked for are probably an order of magnitude simpler.

Edited June 23, 2015 by intvnut

[freewheel]

Just to double-check: IntyBASIC has no support for the ECS controllers, yes?

 

Are there plans for this?

[First Spear]

 

 

[snip]

It's GPLed. If the "specialized sound effect generator" mode of using the Intellivoice is interesting to IntyBASIC, I'm happy to work on adapting and relicensing the necessary bits.

 

 

 

The specialized sound effect generator mode is (still) interesting to IntyBASIC.