Differences

This shows you the differences between two versions of the page.

Link to this comparison view

Both sides previous revision Previous revision
Next revision
Previous revision
Next revisionBoth sides next revision
publications:bibtex [2017/08/23 18:26] hnvpublications:bibtex [2018/08/30 20:56] – test hnv
Line 50: Line 50:
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
  
 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 +% 2018
 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 +
 +
 +@inproceedings{SinkBernViesSchoARRAY18,
 +  author    = {Artjoms Sinkarovs and
 +               Robert Bernecky and
 +               Hans{-}Nikolai Vie{\ss}mann and
 +               Sven{-}Bodo Scholz},
 +  title     = {A Rosetta Stone for array languages},
 +  booktitle = {Proceedings of the 5th {ACM} {SIGPLAN} International Workshop on Libraries,
 +               Languages, and Compilers for Array Programming, ARRAY (at PLDI) 2018, Philadelphia,
 +               PA, USA, June 19, 2018},
 +    abstract  = {This paper aims to foster cross-fertilisation between programming language and compiler research performed on different array programming language infrastructures. We study how to enable better comparability of concepts and techniques by looking into generic translations between array languages. Our approach is based on the idea of a basic core language Heh which only captures the absolute essentials of array languages: multi-dimensional arrays and shape-invariant operations on them. Subsequently, we investigate how to map these constructs into several existing languages: SaC, APL, Julia, Python, and C. This approach provides us with some first understanding on how the peculiarities of these languages affect their suitability for expressing the basic building-blocks of array languages. We show that the existing tool-chains by-and-large are very sensitive to the way code is specified. Furthermore, we expose several fundamental programming patterns where optimisations missing in one or the other tool chain inhibit fair comparisons and, with it, cross-fertilisation.},
 +  pages     = {1--10},
 +  year      = {2018},
 +  doi       = {10.1145/3219753.3219754},
 +  timestamp = {Tue, 10 Jul 2018 08:34:20 +0200},
 +}
 +
 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 +% 2017
 +%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 +
 +@inproceedings{SinkSchoStewViesIFL17,
 +  author    = {Artjoms Sinkarovs and
 +               Sven{-}Bodo Scholz and
 +               Robert Stewart and
 +               Hans{-}Nikolai Vie{\ss}mann},
 +  title     = {Recursive Array Comprehensions in a Call-by-Value Language},
 +  booktitle = {Proceedings of the 29th Symposium on Implementation and Application
 +               of Functional Programming Languages, {IFL} 2017, Bristol, UK, August
 +               30 - September 01, 2017},
 +  abstract  = {Recursive value definitions in the context of functional programming languages that are based on a call-by-value semantics are known to be challenging. A lot of prior work exists in the context of languages such as Scheme and OCaml. In this paper, we look at the problem of recursive array definitions within a call-by-value setting. We propose a solution that enables recursive array definitions as long as there are no cyclic dependences between array elements. The paper provides a formal semantics definition, sketches possible compiler implementations and relates to a prototypical implementation of an interpreter in OCaml. Furthermore, we briefly discuss how this approach could be extended to other data structures and how it could serve as a basis to further extend mutually recursive value definitions in a call-by-value setting in general.},
 +  pages     = {5:1--5:12},
 +  year      = {2017},
 +  doi       = {10.1145/3205368.3205373},
 +  timestamp = {Tue, 21 Aug 2018 17:24:50 +0200},
 +}
  
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%