#Enigma simulator franklin heath limited code#
#Enigma simulator franklin heath limited windows#

Also includes runically unrelated blackletter writing style and pigpen cipher. (March 2009) (Learn how and when to remove this template message)Įdward Larsson's rune cipher resembling that found on the Kensington Runestone. Please help to improve this article by introducing more precise citations. This article includes a list of references, but its sources remain unclear because it has insufficient inline citations.

In general I avoid using on lists - just write map.For other uses, see Cipher (disambiguation). May be more simply written as: all (`elem` letters) msgĪnd is a lot more readable. This expression: (and $ (`elem` letters) msg) The same same as the input ec except that the positions field has changed. Not only is it shorter, but it is also clearer that the returned value is

This is (fortunately) close to the typical mathematical formulation, in which mappings are represented as a composition linear operators that permute the alphabet: The expression used in componentMapping to determine the mapping preformed by a component c that is in a given position p, is a bit more verbose than it needs to be: rotMap (1-p) letters !! (numA0 ch)) (rotMap (p-1) (wiring c))īut I was aiming to have something close the physical process by which rotating a component changes its mapping. In the context of a larger package, this would serve as an 'internal' representation (that would have an inaccessible value constructor) and I would provide a more user-friendly 'safe' constructor that parsed conventional specification strings. My type for the configuration, or state, of an Enigma machine, EmigmaConfig, will be unfamiliar to people who haven't though about the internals of how an Enigma works, and focuses on the minimal physical set of values that fully define it's state, rather than conventionally exposed things like the letters at the 'windows'. Since my goal is to be educational, and not to create a cryptographic tool, this is acceptable to me but comments about other approaches are welcome. This also lets me compute encodings by rotating mappings, which corresponds directly to what the Enigma machine is doing physically. Effectively, I determine what the encoding of every letter at every stage would be, and then use that to figure out how a given (single) letter is encoded. Overall, this is a bit (perhaps considerably?) less efficient that many alternative approaches might be, because rather determining encoding based only on a minimal state specification, I determine the complete mapping of each component of the machine as part of my encoding calculations. I'm also particularly interested review of following aspects:

#Enigma simulator franklin heath limited code#

I'm also curious how clear the code - on its own, with out comments - is. I'm especially interested in review of any errors or missed opportunities to exploit Haskell features or idioms.

#Enigma simulator franklin heath limited windows#

Which can then be represented in one of the conventional ways: ghci> windows cfgĮxamined more deeply: ghci> putStr $ unlines $ stageMappingList cfgĪnd used to encode messages: ghci> let msg = 'FOLGENDESISTSOFORTBEKANNTZUGEBEN' This code allows for the creation of a machine from a simple specification: ghci> let cfg = EnigmaConfig (I expect to post a follow on where a more complete package is reviewed but this should stand on its own.) As my first (keep that in mind!) Haskall program (full code at end) I've written a simple Enigma machine and would like feedback on the core code related to its stepping and encoding - stripped of comments to see how it fares without them.