The previous post on “Fundamentals of Monads” suggested that monads empower the programmer with abstraction of context (algebraic data type) details, as well as order of evaluation, with the latter bringing us one step closer to the model of imperative languages when we need it, while still maintaining all the beautiful properties of the functional language that Haskell is. If you haven’t read the previous post, you may want to, as some of the terminology and intuition described there is used here.
Every (algebraic) data type is created for a very specific purpose. A data type isn’t made because you feel like making one (even if you can). Those data types which exist for no reason, in general, will have difficulty being generalized (into monads, as we will see later). However, let’s assume we’re all keen and astute programmers who won’t do that for the heck of it, and that we’re actually trying to accomplish something.
A Queer Example However, just to clarify things and hopefully get a better mental picture of how Haskell really treats types, let’s play with a really weird typeclass, and find a way to make an instance of it. class Weird p where weird :: j k -> p k j The weird function takes one parameter, and returns a single, concrete type. We look for -> to determine parameters and return values.
Types of Types We’ve seen, at an observer level, how Haskell deals with types and type classes. But how does it actually formalize that so that it can get the checking right? While values have types (and expressions generate values), and we can use types to guarantee that functions which expect a type gets exactly that type. How then does Haskell guarantee that type constructors get the type it expects?
TypeClasses And then you have typeclasses, which is basically a class (absolutely nothing to do with OOP classes in C/C++ or Java or similar languages) to which types may belong, and the typeclass defines certain behaviors that types belonging to it will exhibit. For instance, in the standard library, Eq is a typeclass, and the behavior that Eq defines is that two values can be “equated”, whatever the meaning of equating two values of a type may mean.
The Basics Haskell has an incredibly expressive and powerful type system, but in understanding it there needs to be some mental concepts that one needs to get right. The key one (for me) is the very conscious and internalized distinction between what is a type constructor and what is a value (or data) constructor. I’ll use value constructor here though both terms represent the meaning just as well to me.
I’ve been thinking about the way Apple presents itself to its users, and their “it just works” philosophy. Basically, whether that’s marketing, or is it true to some extent? Now there’s already been much thought, books even, on the matter of why Apple is so successful as a company, so this isn’t some attempt to rehash those same things. So, Apple is famous for not releasing something when the product isn’t complete, or up to their satisfaction.
This article is on what is loosely but oft referred to as “monadic functions”. It contains my personal and intuitive way of thinking of monadic functions, and it may not suit you well. However, for who out there who this may help, I hope it makes that little difference for you. I notice that in most monad tutorials, there is tremendous detail in how monadic composition works, as well as examples on how the >>= bind operator is implemented in various commonly seen monads (Maybe, , State, etc), but there is very little what exactly are monadic functions.
Windows has long moved to 64-bit, and the kernel is 64-bit. However, we also notice that 64-bit Windows can run 32-bit code with seemingly no issues at all. The reason for this is that Microsoft implemented a translation layer between the 32-bit code and the 64-bit OS, and this is (largely) implemented in wow64cpu.dll and wow64.dll. Put very simply, the core task of wow64cpu.dll is to save the 32-bit state, convert everything to 64-bit, and call Wow64SystemServiceEx(), which is found in wow64.
exploitPattern generates the metasploit exploit pattern string in Python. It also allows a user to search for a given substring in the pattern. Arbitrary length patterns may be generated and searched. However, beyond ‘Zz9’, uniqueness is no longer guaranteed. Usage: exploitPattern.py <length> | <pattern to search for> e.g.: exploitPattern.py 10000 (generate pattern of 10000 chars) exploitPattern.py Ms0 (find "Ms0" in pattern) GitHub: https://github.com/eugeii/exploit-pattern For those who do reversing and/or exploitation, using an exploit pattern to feed as input to your target is something common.