Basic Like Glue Language

Is something similar to BasicLanguage, with simple control structures, sufficient for smaller GlueLanguages meant to tie together complex building blocks?

Moved discussion from BasicLanguage:

I'm (slowly) working on an open-source web-based query tool that is kind of half-Toad and half DesktopDatabase-like. I've added a table-based scripting "language" that feels a lot like early BASIC (and a tad like MicrosoftAccess "macros"). I imagine some will complain about the non-structured nature of it, but almost nobody complained about the GOTO days until programs grew to more than a page or two. BASIC was mostly created for math and statistical students where most of the domain logic was in math formulas, not conditionals.

Typical "apps" at Dartmouth first prompted for a few parameters (constants), then had a single loop that read data cards/rows and applied the main formula to each row. Matrix apps typically had two or three nested FOR loops for the dimensions of the matrix, and matrix usage is possibly the only reason that FOR is the only block-oriented control structure built into the early language. These apps were pretty easy to follow without structural nesting. Only when they started writing things like games and spreadsheet processors did GOTO's and variable scoping start being questioned. Similarly, most of the power of my tool will be from SQL statements, not imperative conditional statements. Thus, the justification is similar. IF by chance the tool catches on and grows in complexity and use, THEN structured adjustments may be warranted. YagNi.

Here's a simplified example of a "script table" that runs a given set of queries until there's no records:

  Sequence|.Label..|.Command..|Target-Label|.SQL...
  --------|--------|----------|------------|-------
  ...10...|.reLoop.|..........|............|SELECT * FROM bliff...
  ...20...|........|If-No-Rows|.exitLoop...|(none)  //comment: jump to end of loop if no records
  ...30...|........|..........|............|SELECT * INTO firg FROM nog..
  ...40...|........|goTo......|.reLoop.....|UPDATE firg SET ...
  ...50...|exitLoop|..........|............|DELETE FROM ...

(Dots to prevent TabMunging)

The basic set of commands are "Goto", "Stop", "If-No-Rows", and "If-Rows". There may be others such as value tests and "Gosub" and "Return". It performs the commands (test) after performing the row's query, if any. If it's blank, then it checks the most recent query performed.

It differs from BasicLanguage in that it uses named labels instead of line numbers (sequence numbers). It is a bit more reader-friendly that way. This was done because the labels are also to optionally identify a given query statement in long lists. AKA, a "title". If one doesn't want query titles and control statement labels to overlap, they can optionally leave the SQL statement blank on a line such as 50, and move it to a separate row below.

There are other key features besides just executing "lists" of SQL statements that are not shown here because they are off-topic. Otherwise, one could just embed SQL into their favorite scripting language to get the same thing.

--top

"I imagine some will complain about the non-structured nature ..."

I'm curious: Why non-structured?

Simplicity. Less to learn to use scripting; and it keeps the tool simpler from a construction stand-point. The tool is meant for ad-hoc and internal (IT shop) batch querying, not end-user applications. It does have a GOSUB-like construct, which is semi-structured, but I may disable/hide it in the first release. It may be feature overkill.

Implementing typical flow control structures is only marginally more complex than implementing GOTOs, and the former can be trivially implemented on top of the mechanisms for the latter.

I disagree. Implementing and documenting conditional jumps are an order of magnitude simpler than parsing, displaying, validating, and managing nested blocks.

{I suppose that might be true if you're not using a parser generator to help you.}

Further, I'd first like to see what users would be doing to warrant something complex enough to benefit from nested-block-oriented control structures. The tool's "scripting" is only meant to "glue" a handful of query statements together, not implement PacMan. It's not intended for general programming (at least not outside of what "assisted" SQL can be used for).

I'd want to inspect actual long scripts to see if there is not some underlying concept or pattern that can be built in such that explicit conditionals and loop's wouldn't really be needed anymore for that pattern. Or perhaps I'll discover that users really are trying to write PacMan in this tool, in which case I'll snicker and then ignore them. Again, YagNi.

It may also be that some users are not sufficiently skilled in SQL to push the burden of complexity off to it. In such a case, perhaps some more tutorials and examples could be included to illustrate how to shift complexity and processing to SQL instead of large numbers of nested control structures. That's the primary point of the tool: to leverage SQL by making it easier to work with, mainly by managing and/or hiding the grunt work and repetition of "column lists" using reference-based text "includes" and data dictionaries.

{There's probably an argument to be made that encouraging any unstructured programming is a bad idea.}

We can't fear PickTheRightToolForTheJob. Using tool A for job X may make one grow too familiar/fond of tool A such that they try to use it on job Y also. That's just human nature. For small scripts, nested blocks are overkill. Plus, newbies are not its target audience because it assumes the user knows SQL fairly well. And I'm building a tool for specific usage patterns, not a training device. Further, once you see how the tool is laid out, the design choice will make more sense. (If I stop procrastinating and finish the bugger.)

I propose that withOUT visual indentation, GOTO's are competitive with blocks as far as readability. Early languages avoided "wasting" indentation because 80-column punched cards and teletypes were the standard of the day. -t

Status May 2012: I got feature-happy, made it too big a project, and thus sat on it. I decided to skip some of the fancier features I had planned, such as inter-vendor data transfer, and finish whats already almost there......soon....I hope.... -t

You may want to take a peek at ScriptBasic?. It runs on Windows, Linux. OSX (32/64 bit) and Android Linux. A Java version of ScriptBasic? in development. (SB4J)

Well, maybe, but I'm reluctant to create too many install dependencies. OSS with lots of install dependencies is annoying. Project update: Windows crashed, perhaps due to a Flash virus, messing up my test environment, and I still haven't got around to repairing that portion because I'm a lazy SOB. -t