Compile time syntax analysis of APL programs

Weiss, Zvi; Saal, Harry J.

doi:10.1145/390007.805380

Cited by 4 publications

(2 citation statements)

References 7 publications

Supporting

Mentioning

Contrasting

Order By: Relevance

“…Though such methodologies can be cam:led over to MATLAB, it is not cleat how these techniques can be incorpowated in an optimizing compiler fwamework. Approaches such as [17] parse and compile a class of APL programs that do not utilize features that could dynarnicaily change the syntactic meaning of the program's statements. This approach is probably justifiable in light of empkical evidence that suggests that most APL coders abstain from using language features that alter the syntactic structure of the program with each execution instance [16,6].…”

Section: Related Workmentioning

confidence: 99%

Handling context-sensitive syntactic issues in the design of a front-end for a MATLAB compiler

Joisha

Kanhere

Banerjee

et al. 2000

SIGAPL APL Quote Quad

View full text Add to dashboard Cite

tIn recent times, the MATLAB language has emerged as a popular alternative for programming in diverse application domains such as signal processing and meteorology. The language has a powerful array syntax with a large set of pre-defined operators and functions that operate on ax_rays or array sections, making it an ideal candidate for applications involving substantial ax_tay-based processing.Yet, for all the programming convenience that the language offers, designing a parser and scanner capable of mimicldng the language's syntax has proven to be an acutely difficult task. The language has many context-sensitive constructions, and though numerous front-end implementations of MATLAB and MATLAB-Iike languages exist, not much has been discussed regarding the effident compile-ume parsing of such languages or how its syntax impacts the patsJug process.In this paper, we present the design and implementation of a compiler front-end for the MATLAB language. We discuss in detail both the indigenously designed grammar responsible for syntax analysis as wen as the lex/cal specification that comp]ements the Permission to make digital or hard copies of all or part of this work for personal or classroom use is granted without fee provided that copies are not made or distributed for profit or commercial advantage, and that copies bear this notice and the full citation on the first page. To copy otherwise, to republish, to post on servers or to redistribute to lists, requires prior specific permission and/or a fee. APL00, 07/00, Berlin, Germany ~001 ACM 1-58113-398-7 / 00/0007 5.00 g~.mmar. In the course of ore: attempts to emulate M_A_TLAB's syntax, we were able to un~vel certain key issues relating to its syntax, such as the complications arising in parsing command-form function invocations within a compile-time cnvitonrnent, the context-sensitive interpretation of the single quote charactor, and the "translation of white space 'within matrices into dement separators.The front-end effects a conversion of the original source to an inte.tmediate form in which statements are represented as abstract syntax trees and the flow of control between statements by z control-flow graph. .All subsequent compiler passes work on this intermediate representation.The front-end was designed and implemented as part of the MATCH project, which addresses the translation of a MATLAB program by a compiler onto a heterogeneous target consisting of embedded and commezdd-off-the-shelf processors.

show abstract

Section: Related Workmentioning

confidence: 99%

Handling context-sensitive syntactic issues in the design of a front-end for a MATLAB compiler

Joisha

Kanhere

Banerjee

et al. 2000

SIGAPL APL Quote Quad

View full text Add to dashboard Cite

show abstract

“…Weiss and Saal instead applied interprocedural data-flow analysis to resolve the syntactic classes of variable names in APL code (Weiss & Saal, 1981). This analysis is not complete for APL itself due to the possibility that reassignment of a variable name will change how some line of code parses.…”

mentioning

confidence: 99%

The Semantics of Rank Polymorphism

Slepak¹,

Shivers²,

Manolios³

2019

Preprint

View full text Add to dashboard Cite

Iverson's APL and its descendants (such as J, K and FISh) are examples of the family of "rankpolymorphic" programming languages. The principal control mechanism of such languages is the general lifting of functions that operate on arrays of rank (or dimension) r to operate on arrays of any higher rank r ′ > r. We present a core, functional language, Remora, that captures this mechanism, and develop both a formal, dynamic semantics for the language, and an accompanying static, rankpolymorphic type system for the language. Critically, the static semantics captures the shape-based lifting mechanism of the language. We establish the usual progress and preservation properties for the type system, showing that it is sound, which means that "array shape" errors cannot occur at run time in a well-typed program. Our type system uses dependent types, including an existential type abstraction which permits programs to operate on arrays whose shape or rank is computed dynamically; however, it is restricted enough to permit static type checking.The rank-polymorphic computational paradigm is unusual in that the types of arguments affect the dynamic execution of the program-they are what drive the rank-polymorphic distribution of a function across arrays of higher rank. To highlight this property, we additionally present a dynamic semantics for a partially erased variant of the fully-typed language and show that a computation performed with a fully-typed term stays in lock step with the computation performed with its partially erased term. The residual types thus precisely characterise the type information that is needed by the dynamic semantics, a property useful for the (eventual) construction of efficient compilers for rankpolymorphic languages.

show abstract