ok ... by using "newtype", we are constricting/constraining to a subset of
CInt .. e.g. something like a "subtype" of CInt?? (where by "subtype", I
mean like the notion of subtype in languages like Ada). For our audience,
can you perhaps distinguish (in a typeful way) between the Haskell notion of
"type", "newtype" and "data"? Or maybe let's distinguish between these
notions not only in a typeful manner, but also in a historical motivation?
.. ... motivations are always IMO very, very enlightening!
Regards, vasili
On Mon, Oct 6, 2008 at 12:47 AM, Don Stewart
Used wisely, newtype prevents accidentally constructing illegal values of Signal type, by treating them as CInts. You can restrict the valid values of the Signal type to be just those signals you define, not arbitrary bit patterns that fit in a CInt.
Thanks Don. Maybe both for me and others in order to take the fight to
Klingons and other Baddies, please explain the "typefulness"
that "newtype" affords over the "Klingon " "type" ... In the code
contributed to the library, I like to think that I used "newtype" appropriately but not perhaps with full understanding.
Thanks, Vasili
On Mon, Oct 6, 2008 at 12:37 AM, Don Stewart <[1]dons@galois.com> wrote:
vigalchin: > Hello, > > I am reading some extant Haskell code that uses Posix signals.... I am > confused by the motivation of the following ... > > type [1]Signal = [2]CInt > [3]nullSignal :: [4]Signal > [5]internalAbort :: [6]Signal > [7]sigABRT :: [8]CInt > [9]realTimeAlarm :: [10]Signal > [11]sigALRM :: [12]CInt > [13]busError :: [14]Signal > [15]sigBUS :: [16]CInt > > OK .. "type" is really just a synomym and doesn't invoke type checking > like "data" type declarations do .. so why don't we have all
vigalchin: the protection that I the
"CInts" > substituted by "Signal"? I.e. what did I miss?
Looks like it should all be Signal, and probably should be using a newtype, to prevent funky tricks. The Posix layer is a bit crufty. -- Don
References
Visible links 1. mailto:dons@galois.com