Postmodern thought and individual experience: An interpretative phenomenological analysis

This item is only available electronically.Emerging predominately in the late 1970s through to the early 90s, postmodern thought encompasses a radical questioning of previous cultural and belief structures. This has led to criticisms of these ideas as nihilistic and detrimental to individuals’ identity and values, alongside claims of increased freedom and possibility. Given these criticisms and possibilities, the present study consisted of a qualitative investigation into the influence of postmodernism on the self, beliefs, and values. Seven participants participated in semi-structured interviews, which were analysed through an experience-based approach using Interpretative Phenomenological Analysis. Four themes and 15 subthemes were identified in response to postmodernism: ‘ambivalence’; ‘uncertainty’; ‘responses to uncertainty’; and ‘self as an exception’. These findings were both consistent and inconsistent with criticisms of postmodernism, as participants expressed a sense of postmodernism as destabilising, however, the need for action and stability frequently led participants to respond with the strengthening of their beliefs, or an unwillingness to refute them. The experiences and responses of participants to postmodernism challenge the view that postmodern thinking has a negative influence upon individuals and their beliefs, although further research is needed. Based on the present study and its limitations, it is suggested that future research utilise both qualitative and quantitative methods in more targeted samples to investigate the relationship between postmodernism and conceptions of beliefs and values.Thesis (B.PsychSc(Hons)) -- University of Adelaide, School of Psychology, 201

Scope Graphs: The Story so Far

Static name binding (i.e., associating references with appropriate declarations) is an essential aspect of programming languages. However, it is usually treated in an unprincipled manner, often leaving a gap between formalization and implementation. The scope graph formalism mitigates these deficiencies by providing a well-defined, first-class, language-parametric representation of name binding. Scope graphs serve as a foundation for deriving type checkers from declarative type system specifications, reasoning about type soundness, and implementing editor services and refactorings. In this paper we present an overview of scope graphs, and, using examples, show how the ideas and notation of the formalism have evolved. We also briefly discuss follow-up research beyond type checking, and evaluate the formalism

Scope States (Artifact)

Compilers that can type check compilation units in parallel can make more efficient use of multi-core architectures, which are nowadays widespread. Developing parallel type checker implementations is complicated by the need to handle concurrency and synchronization of parallel compilation units. This artifact contains benchmarks and sources for a new framework for implementing hierarchical type checkers that provides implicit parallel execution in the presence of dynamic and mutual dependencies between compilation units. The resulting type checkers can be written without explicit handling of communication or synchronization between different compilation units. We achieve this by providing type checkers with an API for name resolution based on scope graphs, a language-independent formalism that supports a wide range of binding patterns. Our framework is implemented in Java using the actor paradigm. We evaluated our approach by parallelizing the solver for Statix, a meta-language for type checkers based on scope graphs, using our framework. Benchmarks show that the approach results in speedups for the parallel Statix solver of up to 5.0x on 8 cores for real-world code bases

Stack graphs: Name resolution at scale

We present stack graphs, an extension of Visser et al.'s scope graphs framework. Stack graphs power Precise Code Navigation at GitHub, allowing users to navigate name binding references both within and across repositories. Like scope graphs, stack graphs encode the name binding information about a program in a graph structure, in which paths represent valid name bindings. Resolving a reference to its definition is then implemented with a simple path-finding search. GitHub hosts millions of repositories, containing petabytes of total code, implemented in hundreds of different programming languages, and receiving thousands of pushes per minute. To support this scale, we update the graph construction and path-finding judgments to be file-incremental. For each source file, we create an isolated subgraph without any knowledge of, or visibility into, any other file in the program. This lets us eliminate the storage and compute costs of reanalyzing file versions that we have already seen. Since most commits change a small fraction of the files in a repository, this greatly amortizes the operational costs of indexing large, frequently changed repositories over time. To handle type-directed name lookups (which require "pausing" the current lookup to resolve another name), our path-finding algorithm maintains a stack of the currently paused (but still pending) lookups. Stack graphs can be constructed via a purely syntactic analysis of the program's source code, using a new declarative graph construction language. This means that we can extract name binding information for every repository without any per-package configuration, and without having to invoke an arbitrary, untrusted, package-specific build process.Comment: 8 pages, submitted to Eelco Visser Commemorative Symposium 202

The Iray Light Transport Simulation and Rendering System

While ray tracing has become increasingly common and path tracing is well understood by now, a major challenge lies in crafting an easy-to-use and efficient system implementing these technologies. Following a purely physically-based paradigm while still allowing for artistic workflows, the Iray light transport simulation and rendering system allows for rendering complex scenes by the push of a button and thus makes accurate light transport simulation widely available. In this document we discuss the challenges and implementation choices that follow from our primary design decisions, demonstrating that such a rendering system can be made a practical, scalable, and efficient real-world application that has been adopted by various companies across many fields and is in use by many industry professionals today