** Proposal for a system to develop new computer software,
** without any need to enter formal syntax for program structure,
** neither manually keying syntax nor copying&pasting from textual templates,
** nor using an IDE to select syntax-templates from menus.

The essential paradigm for algorithms would be "structured
programming", i.e. layers of functions (also known as
subroutines or procedures), bottom-up tool-building layer by
layer starting from using pre-existing functions to build
the next higher layer of functions and building up higher
and higher. At any point, all functions already built would
be available at any time to call manually from the user
level.

The essential paradigm for development would be
input-to-output, one data-processing step at a time, using
test data to immediately see if that one step is correct
before starting to build the next. Mutable values would be
supported, whereby such a value object can be created once
then later modified at various d/p steps. Overall dataflow
within the body of a function would be handled in a similar
manner to a spreadsheet, whereby a chance in a test input
value would immediately be propagated through all d/p steps
that depend on it. A variation of that idea would handle
conditional branches, whereby the dataflow is activated for
only the correct branch after a conditional split. Loops
would be handled either by conditionals and reconnections
backwards (which later get abstracted to a formal loop), or
by an explicit Dijkstra loop primitive. Either way, the
dataflow/spreadsheet paradigm would be modified to limit the
number of times around a loop during each interactive pause.
The combination of re-assignable local variables and mutable
value objects, with either kind of loop structure, would
then support a full range of iterative algorithms.

The user interface then would work basically like this: The
user selects a type of input data, and the edits that data
value. That may be repeated for as many input data values as
are anticipated to be needed. Then the user selects one or
more of these already-created values to be passed into a
pre-existig d/p function. The IDE then automatically
presents a menu of available functions that work from those
types of data values. Note that *intential* data types are
used here. Thus for example an integer might be intentially
any of several different types: index into array/stream-like
object, UniCode for a character, key for an associative
array (hash/lookup table), bitmap using binary notation,
approximation to a numeric value, exact integer value per
modular arithmetic, etc. Then the user selects the function
to apply to those given test-data values, and the IDE
applies the function to produce a new value, and shows it to
the user. Now one additional value is available to be fed
into later functions. Selecting which of those values will
be used next, and then selecting the function to apply,
repeats until the desired return value(s) have been
achieved. The user then specifies which of the original data
values are supposed to be parameters to the function being
defined, which are constants or parameters, and which values
are to be returned. If this information is consistent (all
input values needed for the specified return values are
either parameters or constants), then the function is
defined. The user must then write a description of what this
function does, so that the function can be entered into the
master database, and so that the function can be included as
an option whenever these particular types of input values
are selected during definition of a higher-level function.

(Note: "higher level" here refers to the layers of
 functions, where a higher level function calls a lower
 level function, not to functions which take function-objects
 as parameters.)


Below is a slightly modified version of a first idea for a
user interface that I previously posted:

Nested radio buttons:
  ( ) String literal:
       ( ) Short string, all on one line (user fills in text field)
       ( ) Long string on multiple lines (user fills in text area)
       ( ) Path+name of file (user interacts with filesystem browser)
  ( ) Integer literal
       ( ) Short/medium size integer (at most 75 digits, from text field)
       ( ) Long integer (from text area, newlines ignored)
       ( ) Load integer from text file
       For the above, radix:  (*) decimal  ( ) hexadecimal  ( ) other ____
       ( ) Load integer from binary file, little end first
       ( ) Load integer from binary file, big end first
  ( ) Call function/method
       ( ) Search CookBook/Matrix for suitable function in library
       ( ) Search your personal library for your function
       ( ) Enter standard name in text field
       ( ) Enter your personally-defined name in text field
SUBMIT

That specific idea is very much subject to amendment before
any serious implementation is started. In particular, I
probably should keep the literal-setup completely separate
from the function-call. For the latter, the user must first
check which pre-existing data values will be given as
parameters to the function, which means the user must first
open the dialog for selecting data values to use, then check
the boxes in that dialog and click submit, then look at the
menus that show available functions that can be applied to
those values. As for the user entering the (standard or
personal) name for a function instead of selecting from a
menu, that would require a consistency check, whether the
checked data values are compatible with the parameters
required by that function. Alternately a different dialog
could be used where the function is selected first and then
menus of available data values are presented for each
parameter to that function. Perhaps both styles should be
allowed? As with any "spreadsheet" model, it should be
possible for a function-call to be specified before all
needed parameters are available, then the user builds any
such needed parameters before returning to the function-call
dialog to finish specifying that particular d/p step. Note
that it would be helpful for others to comment on my ideas
for ways to configure this no-syntax IDE, and suggest which
specific ways would be preferable before anything gets
implemented.


Here's another explanation I previously posted of how this would work:

Programming would all be done by information retrieval
(menus and filesystem browser). You want a literal constant?
You select from menu:
- integer
- string
- filesystem reference
Then you go into an editor or filesystem dialog to design
your literal or find the file whose path+name you want.

Once you have one or more literal values, you check the
checkboxes for the data you want to feed into some
data-processing operation, and the system gives you a menu
of appropriate known functions. For example, if you have a
string and an integer, you might want the nth character of
the string, or the sub-string starting or ending at that
position, or the decimal or other radix representation or
s-expression parsed from the string starting at that
location, or you might want to use the string as a format
string with the integer as a substitition parameter to the
FORMAT function.


Below is a comment about bootstrapping this system, whereby
a student who knows nothing about writing computer software
would need to learn just the absolute minimum of a
conventional programming language to get started, then the
rest of the work could be done *using* this new system to
develop itself:

The student would be *learning* how to program in Lisp but
implementing my idea for no-syntax programming, and
eventually could use the no-syntax programming-aid service
to actually develop new code (automatically translated to
Lisp by the service).


Here's another part of my proposal I previously posted:

Consider my proposed no-syntax (except literal values, and
even they aren't the usual syntax in the case of strings):

Suppose the user has previously entered the string "Hello
test", which is just test data for the algorithm, and the
string " ". which is a vital literal constant of the
algorithm. Suppose now the user says he/she wants to search
the CookBook/Matrix, a future version of a fully
database-implmented search engine, vaguely modeled like this
crude incomplete preliminary WebPage:
 <http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html>
The user finds this method:
 <http://www.rawbw.com/~rem/HelloPlus/CookBook/Matrix.html#Arr>
   Array indexing: Given an array already allocated, of dimension k, and
   integer indexes i1, i2, ... ik, reference the element at that position
   within the array:
which applies to special cases of vectors (one-dimensional arrays)
and strings (vectors of characters). So the user realizes he/she
first needs to set up the integer 0 as an index into the string,
thus the user backtracks to set up that literal integer, then gets
back into array indexing and actually selects the function for
retrieving an element from a vector. The system then asks what
string to use and what integer index to use, offering a menu of
just that literal strings "Hello test" and " ", and just that
literal integer 0 since that's all the user has set up so-far.
So internally the system is doing (aref " " 0) or equivalently (elt
" " 0), either of which returns #\Space, which is presented to the
user as a diagram:
  +---------------+
  | Character     |
  | Name: Space   |
  | Unicode: 0040 |
  +---------------+
The user can, if desired, select to show such characters in some
other more compact notation such as ' ' (C sytax) or #\Space
(Common Lisp syntax) or U+0040 (unicode notation) or &#20; (HTML
syntax) etc.

Next the user selects function from searching library again, and
this time finds:
   Find character in string: Given string str, and character ch, find
   first instance of ch as element of string:
The system prompts for string (user selects the test data string
this time) and the character (the space character obtained just
previously).
Internally the system is doing (position #\Space "Hello test")
The result is the integer 5.

Next the user selects function from searching library again, and
this time finds:
   Select sub-string: Given string str, and integers ix1,ix2 which are
   indexes within the string, return a newly-allocated string containing
   just the characters between those two positions.
The user selects that test-data string again, and the indices 0 and
5 from earlier, and gets back the string "Hello", which is
displayed in a diagram I won't bother to draw right now.

Eventually the user has completed building the steps needed to
break a string into two sub-strings according to some delimiter
such as #\Space. Then the user selects the option of completing the
function definition (not offered earlier when I showed the nested
radio buttons because there weren't any steps to incorporate yet),
tells which local variables are given as parameters (the test-data
assignments for these parameters are then discarded except as test
data for an automated test script), and which variables are to be
returned as values, and picks a name for this user-defined
function, and now or later can write a documentation string for it,
but the system might provide default documentation that at least
vaguely gives some idea what's going on, for example:
 ;Given a string, and a character:
 ;(algorithm missing)
 ;Return two sub-strings of the original string.
The user need fill in only the middle part:
 ;Split the string where that delimiter occurs, generating two
 ; sub-strings (before and after that delimiter).

Of course the system would automatically enter the user-defined
function in the private addendum to the CookBook/Matrix, in the
section deailng with Strings and Characters, and optionally the
user could submit the function-definition for public beta testing,
to discover any bugs in the algorithm, or to discover problems with
the documentation, or to suggest alternate code already available
elsewhere that is more flexible/general, or to get glowing
recommendations that the algorithm be formally published for
general use by adding it to the public CookBook/Matrix, etc.

* (The only syntax would be for *data*:
   - integers, in whatever base the customer wants
   - strings, given as highlighted/boxed text rather than
      quotemark-delimited inline strings
   - ordered lists, presented just about any way the customer wants
      that we can implement easily
   - higher-level objects designed by the programmer, typically some kind
      of "intent wrapper" around a restricted set of nested lists
   When I say "no syntax", I mean no syntax for algorithms.
   There's still syntax for *data*.)


Another previously posted snippet:

I've recenty proposed a no-syntax programming environment
where you browse a library of functions available and select
from a menu what you want and never need to even *see* the
actual name of the function you're calling from your new
"code".


More previously posted descriptions:

The general idea is that instead of writing sytnax for
function/method calls, you specify what input data to pass
as parameters and get a menu of functions/methods (by
description, not name) that take such parameters, organized
by the intentional type of parameters and return value, and
just select from the menu. As I envisioned it up to today,
one-call-at-a-time development would be mostly one-shot,
whereby you set up test values for parameters, specify and
execute one line of code at a time, and at some point say
"that's the return value I want", and the IDE automatically
builds a function with all lines of code whose output
affects the return value. (SIde branches whose return values
never get used toward the final return value are deleted at
that point.)

You work from the intentional datatype via menus to select
previously-defined operations available on the given
datatypes. In some sense it's like you are programming in
dataflow diagrams and D-charts, except you never have to
draw anything, you just select from options in context. Each
time you connect some input data nodes via a menu-selected
operation, you thereby create a new output data node that
can be used as input for future operations.

 ... using intentional datatypes of previously generated
data objects to direct menus of available operations upon
those objects, whereby the D-chart gets drawn automatically
any time you want to see it as a visual aid.