The Power of Figurative Language

2025-02-06T00:00:00+00:00

I think they are an efficient and concise way to get your point across. A sentence like "Jack is hungry" is brief which normally implies that the meaning it carries is also shallow and unspecific. But, similes and metaphors create an exception to this norm about brief sentences. When you change it to "Jack is hungry as a wolf", it's still brief, but the simile has added dimensionality and depth to the meaning. That is, the pairing simile has upgraded the definition of "hungry" and equipped it with a few layers of depth without having to use or look for a more complicated word that nails down the specific variant you intended to convey with the original phrase. You could've also used an intensifier like "very" to modify this degree of meaning. But, in my opinion, a simile or metaphor is stronger. They're efficient because to exactly describe how Jack is hungry, you could say "Jack is so hungry that he could eat tons of meat, and he's so furious". This has the problem of being lengthy, and possibly lacks a few more descriptions to conceive the desired imagery in your head. Eating lots of meat, and being furious are qualities that a wolf possess—well, stereotypically—so, the sentence could easily be reworded as "Jack is hungry as a wolf". The new sentence is short yet deep, as opposed to the former which is longer and not as deep. You could think of "wolf" as a container of the many unreachable words in your head, that is, "Jack is hungry as a [wolf]" can be rephrased or expanded into "Jack is hungry [{that he can, he is, etc.}-{all the qualities of a wolf}]", and this could end up being a several more sentences while a simile could've done a better job in just a sentence! A shortcoming of this construct though is that the meaning may vary to everyone; it depends on how a wolf looks like in their heads, that is, if they even know what a wolf is. That is true of most usage of figurative language.</p>

I would like to also add that the said shortcoming is most likely same one that Jesus took advantage of when he was teaching the people in parables, to divide his listeners and prevent just anyone from understanding them. The meaning of the parables varied across the people, and his disciplines were the only ones who understood them. Everyone else found them obscure.</p>

I think it's reasonable to claim that the understanding of metaphors among people is never uniform, as people have uniquely different lived experienced and/or socioeconomic conditions. But, I believe that whether this is a shortcoming, depends on the context. I may have implicitly bound it to usage within literature in my first paragraph, but they are evidently problematic in areas like politics, colloquial conversations, and academia. For example, in physics, it's common to use analogies to approach complex ideas, like electricity to water. But, only temporarily. It's agreed upon to be a great analogy, but they certainly don't hold true anymore when you stretch them too far, and try to understand all electricity's properties from the lens of the analogy. At this point, your brain tries its best to repack it within the confines of the analogy, but this even confuses you more, and you ultimately regret knowing the analogy in first place, as its perhaps the easiest/fastest thought your brain recalls when it attempts to understand the real concept outside of its analogical form, and then you're forced to confront the unfortunate reality with no analogies to help you. I think they are like training wheels; you don't realize you can't ride a bicycle until you take them off. However, their usage in areas like literature and so, is fine for the majority of people I believe—except for some with cognitive disabilities who may struggle to comprehend them. I can also imagine metaphors being used to gate keep information or to secretively communicate.</p>

My Haskell Notes

2024-10-26T00:00:00+00:00

type ambiguity with multi type param typeclasses</h2>

when we introduce multiple params to typeclasses, haskell is more likely to raise "ambiguity" errors. consider the following example:</p>

class </span>Foo </span>a b </span>where
</span>  </span>get </span>:: </span>a </span>-> </span>b
</span>
</span>instance Foo Int</span> [</span>Int</span>] </span>where
</span>  get x = </span>[]
</span>
</span>instance Foo Int String where
</span>  get x = </span>[]
</span>
</span>foo </span>::</span> (</span>Foo </span>a b</span>) </span>=> </span>a </span>-> </span>b
</span>foo a = get a
</span></code></pre>
now if want to invoke call</p>
foo </span>2
</span></code></pre>
we get the following error:</p>
• Could not deduce ‘Foo a0 b’
</span>    from the context: (Foo a b, Num a)
</span>    bound by the inferred type for ‘it’:
</span>                forall {a} {b}. (Foo a b, Num a) => b
</span>    at <interactive>:1:1-5
</span>    The type variable ‘a0’ is ambiguous
</span>    Potentially matching instances:
</span>    instance [safe] Foo Int [Int] -- Defined at app/Main.hs:22:10
</span>    instance [safe] Foo String Int -- Defined at app/Main.hs:25:10
</span>• In the ambiguity check for the inferred type for ‘it’
</span>    To defer the ambiguity check to use sites, enable AllowAmbiguousTypes
</span>    When checking the inferred type
</span>    it :: forall {a} {b}. (Foo a b, Num a) => b
</span></code></pre>
this happens because when you call foo 2</code>, haskell tries to resolve Foo a b</code>, which I believe happens before the function
is actually evaluted, so it has solid types to operate on. so it sees a</code> in get :: a -> b</code>, and it knows its Int</code> or
something.
nah dumbass! a</code> is still not a solid type, haskell just puts a Num</code> constraint on it, and that's what it only knows. So both a</code> and b</code> are ambigious. let's be more explicit here</p>
foo (</span>2 </span>:: </span>Int</span>)
</span></code></pre>
Then haskell looks for a Foo Int b</code> instance, do we have one? No. So haskell is confused about which instance of
Foo a b</code> you actually want to use, which the error message helpfully provides for you. To fix such an error, you have to be
more explicit about the type. i.e</p>
(foo (</span>2 </span>:: </span>Int</span>) :: [</span>Int</span>])
</span></code></pre>
tada, now haskell knows that you meant the Foo Int [Int]</code> instance</p>
functional deps</h2>
with the multi type param extensions, you sometimes want one type to decide the other. e.g</p>
class </span>Foo </span>a b </span>where
</span>  </span>get </span>:: </span>a </span>-> </span>b
</span></code></pre>
this means we can do stuff like</p>
instance Foo Int M
</span>  ... 
</span>  
</span>instance Foo String M
</span>  ...
</span></code></pre>
this is fine, but sometimes it isn't desirable. we don't want multiple b</code>s for one a</code>. we only want 1:1
so how do we communicate this to haskell? functional deps.
(enable the ext)</p>
class </span>Foo </span>a b</span> | </span>a</span> -> </span>b </span>where
</span>  </span>get </span>:: </span>a </span>-> </span>b
</span></code></pre>
that's it, now if you try the snippet earlier, haskell would complain, you would have to only keep one of them.
think if b</code> is some certain certain, it doesn't make sense for a state to be associated with different types.</p>
now let's see a more complicated example. the megaparsec</code> library provides a function called single</code>, it's type signature is:</p>
single </span>:: MonadParsec </span>e s m </span>=> Token </span>s </span>-> </span>m</span> (</span>Token </span>s</span>)
</span></code></pre>
roughly, this means that e</code> s</code> and m</code> are related through MonadParsec</code>. that's the signature of the class</p>
class</span> (</span>Stream </span>s</span>, </span>MonadPlus </span>m</span>) => </span>MonadParsec </span>e s m</span> | </span>m</span> -> </span>e s </span>where 
</span>   ...
</span></code></pre>
you see there is a functional dep, which says "m determines e and s". yes so that means we only need to tell it about m</code>, it will take care of e</code> and s</code>
if we try evaluate single '\n'</code>, we would get an ambiguity error, because we don't know m</code>, so we don't know s</code> which is the first argument of single</code>.
it tries to match Char</code> (what we gave it) against what it knows i.e Token s</code>. Nothing it can do abaout it. let's help it out and give it an explicit type</p>
note: it knows Token s ~ Char</code>, but nothing about s</code></p>
(single '</span>\n</span>') :: </span>Parsec Void String Char
</span></code></pre>
so because we know Token s ~ Char</code> (hint from '\n'), we observe how haskell matches the types</p>
m </span>Char
</span>Parsec Void String Char
</span></code></pre>
it sees that the Char</code> is constant in both sides, so it attempts to match m</code> with Parsec Void String</code>, and it should work out.
now we know m ~ Parsec Void String</code>, remember when I said that's what we only need? yes, so because of the functional dependency, you can rest assured that
there is only one instance of MonadParsec</code> where m ~ Parsec Void String</code>, which means there are only one s</code> and e</code> that can fit in here, and those are
the Void</code> and String</code>. So, ultimately haskell knows that we need the MonadParsec Void String (ParsecT Void String Identity)</code>. And if we hoogle it up:</p>
 (</span>Ord</span> e, </span>Stream</span> s) => </span>MonadParsec</span> e s (</span>ParsecT</span> e s m)
</span></code></pre>
we can see that there is indeed an instance with the types we employed.</p>

bwkam

The Power of Figurative Language

My Haskell Notes