Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!uunet!mcsun!ukc!newcastle.ac.uk!turing!ncmh
From: Chris.Holt@newcastle.ac.uk (Chris Holt)
Newsgroups: comp.graphics.visualization,comp.lang.visual
Subject: Re: Terminology for discussing next generation visual languages
Message-ID: <1990Nov15.041642.8153@newcastle.ac.uk>
Date: 15 Nov 90 04:16:42 GMT
References: <1990Nov14.192736.660@ariel.unm.edu>
Sender: news@newcastle.ac.uk
Organization: Computing Laboratory, U of Newcastle upon Tyne, UK NE1 7RU.
Lines: 68

In article <1990Nov14.192736.660@ariel.unm.edu>
 rasure@sherman.unm.edu (John Rasure) writes:

>The following is a proposed list of components that should be considered
>in the design of a second generation data flow oriented visual language
>programming environment.  Our motivation for posting this is two-fold:
>1) we would like to test our terminology and see if it is reasonable and
>2) provide a basis for comparison of the various data flow oriented
>visual systems.
>
>	1.  User Interface
>		a)  programming paradigm (data flow, forms/menus)

Can the user ever have control over this?

>		b)  workspace/visual editor
>		c)  access to language primitives (selection of operators)

Since this isn't in the language spec., I assume you mean the
primitives of the editor, for constructing programs?  Are these
in the language as well, so you can write programs to construct
programs (is it reflective)?

>	2.  Visual Programming Language Specification
>		a)  syntax (graphical/lexical elements)
>		b)  semantics (meaning of elements)
>		c)  expression evaluation (setting operator parameter)
>		d)  hierarchy (visual complexity)
>		e)  documentation (program explanation)
>
>	3.  Operating System Supporting the Visual Language
>		a)  compiler/interpreter (prototyping vs. production)
>		b)  computational model (demand or data-driven)

Should this not be in 2?

>		c)  scheduling (static vs. dynamic, parallel vs. serial)
>		d)  execution mode (continuous or triggered execution)
>		e)  data transport model (representation - files, pipes,
>				      shared memory, sockets, streams, blocks)

Is this supposed to be in the underlying implementation?  If it's
visible, shouldn't it be in 2?

>		f)  debugging support (preventing errors, correcting errors)
>		g)  recoverability (saving program state)

If an application area is to include the construction of dependable
programs, this should be in the language definition as well?

>	4.  Library of Operators
>		a)  application domain
>		b)  level of abstraction
>		c)  interface specification (executable or linkable)

Are specifications first class objects?

>		d)  interoperability  (data compatibility)
>
>	5.  Development Support for Retargeting/Extending
>		a)  user interface development system
>		b)  data token description and typing
>		c)  operator code generation
>		d)  configuration management
-----------------------------------------------------------------------------
 Chris.Holt@newcastle.ac.uk      Computing Lab, U of Newcastle upon Tyne, UK
-----------------------------------------------------------------------------
 "He either fears his fate too much, or his programming tools are small..."