<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>theory on Mature Pessimizations - A programming blog by Theodoros Chatzigiannakis</title>
    <link>https://blog.tchatzigiannakis.com/categories/theory/</link>
    <description>Recent content in theory on Mature Pessimizations - A programming blog by Theodoros Chatzigiannakis</description>
    <generator>Hugo -- gohugo.io</generator>
    <language>en</language>
    <lastBuildDate>Sun, 03 Mar 2019 20:00:00 +0300</lastBuildDate>
    
	<atom:link href="https://blog.tchatzigiannakis.com/categories/theory/index.xml" rel="self" type="application/rss+xml" />
    
    
    <item>
      <title>Generics as super-functions</title>
      <link>https://blog.tchatzigiannakis.com/generics-as-super-functions/</link>
      <pubDate>Sun, 03 Mar 2019 20:00:00 +0300</pubDate>
      
      <guid>https://blog.tchatzigiannakis.com/generics-as-super-functions/</guid>
      <description>&lt;p&gt;This post is the beginning of a series in which we will look at generics more closely, we will consider their implementation details across various languages, and we will explore their potential in solving problems we have today (with static analysis in mind).&lt;/p&gt;

&lt;p&gt;As usual, we will use C# as for our examples because its generics syntax will be self-explanatory to developers familiar with C++, Java, Rust, etc. Also, for the purposes of this post we will use the terms &amp;ldquo;function&amp;rdquo; and &amp;ldquo;method&amp;rdquo; interchangeably.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Undefined behavior can literally erase your hard disk</title>
      <link>https://blog.tchatzigiannakis.com/undefined-behavior-can-literally-erase-your-hard-disk/</link>
      <pubDate>Mon, 04 Sep 2017 20:00:00 +0300</pubDate>
      
      <guid>https://blog.tchatzigiannakis.com/undefined-behavior-can-literally-erase-your-hard-disk/</guid>
      <description>&lt;p&gt;It is no secret that C and C++ are chock-full of pitfalls of undefined behavior. The C++ standard describes it as:&lt;/p&gt;

&lt;blockquote&gt;
&lt;p&gt;behavior for which this International Standard imposes no requirements&lt;/p&gt;
&lt;/blockquote&gt;

&lt;p&gt;Modern compilers, with optimizations on, often assume that undefined behavior is never invoked in the program and try to make sense of the code under that assumption. When a program actually does invoke undefined behavior, this conflicts with the assumption under which the compiler generated code, often resulting in strange, or even outright paradoxical results. (I like to call those cases &amp;ldquo;paranormal behavior&amp;rdquo;, but it still hasn&amp;rsquo;t caught on.)&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Implementing multiple dispatch polymorphism</title>
      <link>https://blog.tchatzigiannakis.com/implementing-multiple-dispatch-polymorphism/</link>
      <pubDate>Wed, 15 Mar 2017 20:00:00 +0300</pubDate>
      
      <guid>https://blog.tchatzigiannakis.com/implementing-multiple-dispatch-polymorphism/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://blog.tchatzigiannakis.com/implementing-single-dispatch-polymorphism/&#34;&gt;As we saw previously&lt;/a&gt;, many popular OOP languages support subtype polymorphism with single dispatch. This means that the dynamic resolution of a polymorphic call happens with respect to one argument only: the &lt;code&gt;this&lt;/code&gt; reference.&lt;/p&gt;

&lt;p&gt;The problem with this limitation is that it&amp;rsquo;s completely arbitrary. In a well-written program, there is no natural tendency for polymorphism to be useful only in one dimension. Quite the contrary – if a program is written with best OOP practices in mind (e.g. &lt;a href=&#34;https://en.wikipedia.org/wiki/Single_responsibility_principle&#34;&gt;one responsibility per class&lt;/a&gt;), chances are that the need for multidimensional polymorphism, also called &lt;em&gt;multiple dispatch&lt;/em&gt;, will eventually arise.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Implementing single dispatch polymorphism</title>
      <link>https://blog.tchatzigiannakis.com/implementing-single-dispatch-polymorphism/</link>
      <pubDate>Wed, 15 Mar 2017 20:00:00 +0300</pubDate>
      
      <guid>https://blog.tchatzigiannakis.com/implementing-single-dispatch-polymorphism/</guid>
      <description>&lt;p&gt;Many object-oriented languages have support for subtype polymorphism with single dispatch over the &lt;code&gt;this&lt;/code&gt; argument.&lt;/p&gt;

&lt;p&gt;To implement polymorphic calls, they need a way of accessing information about which override should be selected at runtime. At least for compiled languages, the most obvious way to store this information is in the form of function pointers. The structure that contains these function pointers is called a &lt;em&gt;dispatch table&lt;/em&gt;.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Applications of substructural typing</title>
      <link>https://blog.tchatzigiannakis.com/applications-of-substructural-typing/</link>
      <pubDate>Mon, 06 Mar 2017 20:00:00 +0300</pubDate>
      
      <guid>https://blog.tchatzigiannakis.com/applications-of-substructural-typing/</guid>
      <description>&lt;p&gt;&lt;a href=&#34;https://blog.tchatzigiannakis.com/structural-rules-and-substructural-logics/&#34;&gt;In a previous writing&lt;/a&gt;, we mentioned a family of types called &lt;em&gt;substructural types&lt;/em&gt;. A type is substructural if it disallows any of the three structural rules: contraction (the ability to use a variable more than once), weakening (the ability to leave a variable unused), and exchange (the ability to reorder usages of two variables with respect to their declaration order).&lt;/p&gt;

&lt;p&gt;In this writing, we will look at several problems that substructural type systems can help us solve at compile time, in ways that common unrestricted type systems are simply unable to do.&lt;/p&gt;</description>
    </item>
    
    <item>
      <title>Structural rules and substructural logics</title>
      <link>https://blog.tchatzigiannakis.com/structural-rules-and-substructural-logics/</link>
      <pubDate>Mon, 06 Feb 2017 20:00:00 +0300</pubDate>
      
      <guid>https://blog.tchatzigiannakis.com/structural-rules-and-substructural-logics/</guid>
      <description>&lt;p&gt;There is a family of unusual type systems called substructural type systems. Many programmers have never encountered them, while other have encountered them without realizing what they are or what&amp;rsquo;s the idea behind them.&lt;/p&gt;

&lt;p&gt;We will try to shed some light on where substructural type systems come from, by giving a quick tour of their theoretical background, which comes from &lt;em&gt;sequent calculus&lt;/em&gt;. To keep this short enough, we will go only over the parts that are useful for examining type systems.&lt;/p&gt;</description>
    </item>
    
  </channel>
</rss>