The VAL Language: Description and Analysis
ACM Transactions on Programming Languages and Systems (TOPLAS)
Real-time: the “Lost World” of software debugging and testing
Communications of the ACM
Communications of the ACM
Lucid, a nonprocedural language with iteration
Communications of the ACM
GROOVE—a program to compose, store, and edit functions of time
Communications of the ACM
Computer animation with scripts and actors
SIGGRAPH '82 Proceedings of the 9th annual conference on Computer graphics and interactive techniques
Formes: An object and time oriented system for music composition and synthesis
LFP '84 Proceedings of the 1984 ACM Symposium on LISP and functional programming
The design of OWL a language for walking
Proceedings of the 1983 ACM SIGPLAN symposium on Programming language issues in software systems
ACM SIGPLAN Notices
Programming languages for computer music synthesis, performance, and composition
ACM Computing Surveys (CSUR)
Animated graphical interfaces using temporal constraints
CHI '86 Proceedings of the SIGCHI Conference on Human Factors in Computing Systems
A system for computer music performance
ACM Transactions on Computer Systems (TOCS)
Animation using temporal constraints: an overview of the animus system
Human-Computer Interaction
Programs = Data + Algorithms + Architecture: Consequences for Interactive Software Engineering
Engineering Interactive Systems
Hi-index | 0.00 |
Arctic is a language for the specification and implementation of real-time control systems. Unlike more conventional languages for real-time control, which emphasize concurrency, Arctic is a stateless language in which the relationships between system inputs, outputs and intermediate terms are expressed as operations on time-varying functions. Arctic allows discrete events or conditions to invoke and modify responses asynchronously, but because programs have no state, synchronization problems are greatly simplified. Furthermore, Arctic programs are non-sequential, and the timing of system responses is notated explicitly. This eliminates the need for the programmer to be concerned with the execution sequence, which accounts for much of the difficulty in real-time programming.