EDBT 2026 Demo / reviewers in the wild / expert
Ifaz Kabir
dblp:202/2276
· DBLP profile ↗
3ranked-venue papers
1as first author
0since 2021 · last 2020
—ORCID · none
Domains — the database's venue-derived domains; a paper can count in several
Software engineering, systems software and programming languages · 3 · 1 first-authorTheory of computation · 1
Expertise — from the expertise taxonomy: the topics of the expert's papers under the CCF categories. A weight counts papers with recency: 1 for a paper about the topic, 0.3 when the topic is its context, halved every five years.
| Software engineering, system software, and programming languages
3 papers |
Programming languages and type systems · 68% Software testing · 19% Program verification · 12% | |
| Theoretical computer science
1 paper |
Automated reasoning and model checking · 100% |
Topics — the 12 heaviest of 12, each with the papers that count most for it
| Topic | Weight | Papers | Last | Evidence papers |
|---|---|---|---|---|
Programming languages and type systems › type theory › dependent types
dependent object types |
0.7 | 2 | 2020 | ιDOT: a DOT calculus with object initialization · Proc. ACM Program. Lang. 2020 A simple soundness proof for dependent object types · Proc. ACM Program. Lang. 2017 |
Programming languages and type systems › computational effects
effect systems |
0.4 | 1 | 2020 | ιDOT: a DOT calculus with object initialization · Proc. ACM Program. Lang. 2020 |
Programming languages and type systems
type systems |
0.4 | 1 | 2020 | ιDOT: a DOT calculus with object initialization · Proc. ACM Program. Lang. 2020 |
Program verification › formal proof
soundness proof |
0.4 | 2 | 2020 | A simple soundness proof for dependent object types · Proc. ACM Program. Lang. 2017 ιDOT: a DOT calculus with object initialization · Proc. ACM Program. Lang. 2020 |
Software testing
fuzzing |
0.3 | 1 | 2018 | StringFuzz: A Fuzzer for String Solvers · CAV (2) 2018 |
Software testing › fuzzing
SMT solver fuzzing |
0.3 | 1 | 2018 | StringFuzz: A Fuzzer for String Solvers · CAV (2) 2018 |
Automated reasoning and model checking
satisfiability modulo theories |
0.3 | 1 | 2018 | StringFuzz: A Fuzzer for String Solvers · CAV (2) 2018 |
Automated reasoning and model checking › constraint solving
string constraint solving |
0.3 | 1 | 2018 | StringFuzz: A Fuzzer for String Solvers · CAV (2) 2018 |
Programming languages and type systems › type systems
type soundness |
0.3 | 1 | 2017 | A simple soundness proof for dependent object types · Proc. ACM Program. Lang. 2017 |
Programming languages and type systems
type theory |
0.3 | 1 | 2017 | A simple soundness proof for dependent object types · Proc. ACM Program. Lang. 2017 |
Programming languages and type systems › language semantics
core calculus |
0.1 | 1 | 2017 | A simple soundness proof for dependent object types · Proc. ACM Program. Lang. 2017 |
Programming languages and type systems › functional language
scala |
0.1 | 1 | 2017 | A simple soundness proof for dependent object types · Proc. ACM Program. Lang. 2017 |
Methods — techniques the papers use, named apart from their topics
fuzzing · 0.7subheap reasoning · 0.4coq · 0.4modular proof strategy · 0.3
| Year | Publication | Venue | Position |
|---|---|---|---|
| 2020 | ιDOT: a DOT calculus with object initializationabstractThe Dependent Object Types (DOT) calculus serves as a foundation of the Scala programming language, with a machine-verified soundness proof. However, Scala's type system has been shown to be unsound due to null references, which are used as default values of fields of objects before they have been initialized. This paper proposes ιDOT, an extension of DOT for ensuring safe initialization of objects. DOT was previously extended to κDOT with the addition of mutable fields and constructors. To κDOT, ιDOT adds an initialization effect system that statically prevents the possibility of reading a null reference from an uninitialized object. To design ιDOT, we have reformulated the Freedom Before Commitment object initialization scheme in terms of disjoint subheaps to make it easier to formalize in an effect system and prove sound. Soundness of ιDOT depends on the interplay of three systems of rules: a type system close to that of DOT, an effect system to ensure definite assignment of fields in each constructor, and an initialization system that tracks the initialization status of objects in a stack of subheaps. We have proven the overall system sound and verified the soundness proof using the Coq proof assistant. Ifaz Kabir, Ondrej Lhoták |
Proc. ACM Program. Lang. | 1 |
| 2018 | StringFuzz: A Fuzzer for String SolversabstractIn this paper, we introduce StringFuzz: a modular SMT-LIB problem instance transformer and generator for string solvers. We supply a repository of instances generated by StringFuzz in SMT-LIB 2.0/2.5 format. We systematically compare Z3str3, CVC4, Z3str2, and Norn on groups of such instances, and identify those that are particularly challenging for some solvers. We briefly explain our observations and show how StringFuzz helped discover causes of performance degradations in Z3str3. Dmitry Blotsky, Federico Mora 0002, Murphy Berzish, Yunhui Zheng, Ifaz Kabir, Vijay Ganesh 0001 |
CAV (2) | 5 |
| 2017 | A simple soundness proof for dependent object typesabstractDependent Object Types (DOT) is intended to be a core calculus for modelling Scala. Its distinguishing feature is abstract type members, fields in objects that hold types rather than values. Proving soundness of DOT has been surprisingly challenging, and existing proofs are complicated, and reason about multiple concepts at the same time (e.g. types, values, evaluation). To serve as a core calculus for Scala, DOT should be easy to experiment with and extend, and therefore its soundness proof needs to be easy to modify. This paper presents a simple and modular proof strategy for reasoning in DOT. The strategy separates reasoning about types from other concerns. It is centred around a theorem that connects the full DOT type system to a restricted variant in which the challenges and paradoxes caused by abstract type members are eliminated. Almost all reasoning in the proof is done in the intuitive world of this restricted type system. Once we have the necessary results about types, we observe that the other aspects of DOT are mostly standard and can be incorporated into a soundness proof using familiar techniques known from other calculi. Marianna Rapoport, Ifaz Kabir, Paul He 0002, Ondrej Lhoták |
Proc. ACM Program. Lang. | 2 |