text:
CVA-01

CVA-01 was a proposed United Kingdom aircraft carrier, designed during the 1960s. The ship was intended to be the first of a class that would replace all of the Royal Navy's carriers, most of which had been designed before or during the Second World War. CVA-01 and CVA-02 were intended to replace HMS Victorious (R38) and HMS Ark Royal (R09), while CVA-03 and CVA-04 would have replaced HMS Hermes (R12) and HMS Eagle (R05) respectively.

The planned four carrier class was soon reduced to three before further being reduced to two and finally, following a government review, in the form of the 1966 Defence White Paper, the project was cancelled, along with the proposed Type 82 destroyer class, which were intended primarily as escorts for carrier groups. Factors contributing to the cancellation of CVA-01 included inter-service rivalries, the huge financial costs of the proposed carrier against ongoing budgetary constraints, and the technical complexity and difficulties it would have presented in construction, operation, and maintenance. Some historians also cite the increased role played by land-based aircraft in providing a nuclear deterrent and that naval leadership at the time presented their need for the carriers poorly in government.

Had CVA-01 and CVA-02 been built, it is likely they would have been named HMS Queen Elizabeth and HMS Duke of Edinburgh respectively.

Origin
In the 1960s, the Royal Navy was still one of the premier carrier fleets in the world, second only to the US Navy, which was in the process of building the 80,000-ton Kitty Hawk-class aircraft carriers.

The British fleet included the fleet carriers HMS Ark Royal (R09) and HMS Eagle (R05), and two smaller carriers, the completely reconstructed HMS Victorious (R38), and the somewhat newer light carrier HMS Hermes (R12), both with 3D Type 984 radar and C3, but limited to air groups of 25 aircraft: at the most 20 fighters and strike aircraft and five helicopters, or alternately 16 fighters and strike aircraft, four turboprop Fairey Gannet AEW, and five helicopters. A fifth carrier, HMS Centaur (R06), was modernised to the minimum standard to operate second-generation Supermarine Scimitars and de Havilland Sea Vixens in 1959, but was never satisfactory or safe for operating nuclear strike aircraft and was a purely interim capability while Eagle was refitting.

While all four of the Navy's large carriers were capable of operating the S.2 version of the Blackburn Buccaneer strike aircraft, only Ark Royal and Eagle were realistically big enough to accommodate both a squadron of Buccaneers (up to 14 aircraft) and a squadron of redesigned McDonnell Douglas F-4 Phantoms, which the Royal Navy intended to procure as its new fleet air defence aircraft. With the remainder of the air group, this would give a total of approximately 40 aircraft, which compared poorly to the 90 available to a Kitty Hawk-class ship. The increasing weight and size of modern jet fighters meant that a larger deck area was required for takeoffs and landings. Although the Royal Navy had come up with increasingly innovative ways to allow ever-larger aircraft to operate from the small flight decks of their carriers, the limited physical life left in the existing ships (only Hermes was considered capable of reliable and efficient extension past 1975 ), and the inability of both Victorious and Hermes, the most effectively and expensively modernised of the carriers, to operate the F-4 or an effective and useful number of Buccaneers, made the order of at least two new large fleet carriers essential by the mid-1960s.

Considerations
Once the Chiefs of Staff had given their approval to the idea of new carriers being necessary, in January 1962 in the strategic paper COS(621)1 British Strategy in the Sixties, the Admiralty Board had to sift through six possible designs. These ranged from 42,000 to 68,000 tons at full load. The largest design, based on the American Forrestal-class aircraft carrier, had space for four full-sized steam catapults but was rejected early on as being significantly too costly, particularly in terms of the dockyard upgrades that would be needed to service them.

The advantages of size were immediately apparent; a 42,000-ton carrier could only hold 27 aircraft, while a 55,000-ton carrier could carry 49 Buccaneers or Sea Vixens. This was an 80% increase in the size of the air group for a 30% increase in displacement. The Board of Admiralty decided in 1961 that the minimum would be 48,000 tons. The carriers would have two main roles: strike carrier (including attacks on airfields) and defence of the fleet. They would also operate early warning aircraft and - later - anti-submarine helicopters. Even with these smaller designs, the cost was a serious issue. The Treasury and the Air Ministry were pushing for a new set of long-range strike aircraft operating from a string of bases around the globe. For the former, this appeared a cost-effective solution for the East of Suez issue, and for the latter, it meant that the Royal Navy would not get a majority of the defence budget.

Four ships were planned but the addition of construction of four Polaris missile nuclear submarines (ordered in April 1963) introduced delays of ten months in expected production. Considerations included the availability of berths at shipyards, sufficient trained welders for use of QT35 steel, drawing office capacity at the shipyards, number of electrical fitters. A new dry dock at Portsmouth was also needed.

By July 1963 it was announced that only one carrier would be built, though there was a possibility that one would be ordered by the Australian Navy.

Details

The "sketch" approved by the Admiralty in July 1963 was for a 890 ft, at the waterline, vessel. Three shafts powered by a new steam plant design would give 27-28 knots and one shaft could be shut down at a time for maintenance. The electrical distribution system, using step-down transformers from 3.3kV, was also new to the Royal Navy.

The CVA-01 would have displaced no more than 54,500 tons, with a flight deck length (including the bridle arrester boom) of 963 ft and 189 ft wide. Overall width was 231 ft. The size of the flight deck, combined with steam catapults and arrester gear would have enabled the carriers to operate the latest jets. The two 250 ft long catapults, which could operate aircraft of maximum weight of 70,000 lb were set at 4 degrees apart. There were four take-off positions to operate V/STOL aircraft.

Initially, no armour was planned but was added to the magazines, ship sides, and hangar bringing displacement up to 54,500 tons.

The sketch included 30 Buccaneer strike and Sea Vixen fighter aircraft. The variable geometry aircraft under design to Operational Requirement OR.346 was expected to be carried out later.

The aircraft complement in the design approved on 27 January 1966 was a mix of 36 British specification McDonnell Douglas Phantom II fleet defence fighters (with secondary strike role) and Blackburn Buccaneer low-level strike aircraft, four early-warning aircraft, five anti-submarine helicopters, and two search-and-rescue helicopters.

Defences included an Ikara anti-submarine system and a Sea Dart anti-aircraft missile (then under development) on the quarterdeck. The Ikara was deleted from the design in February 1965.

The large 'Broomstick' radar dome above the central island on the carrier was planned to be a Type 988 Anglo-Dutch 3D radar, which would subsequently be fitted on the Royal Netherlands Navy Tromp-class frigates, although this would not have been fitted to the final carrier as Britain pulled out of the project.

Cancellation
By early 1963 the Minister of Defence Peter Thorneycroft announced in Parliament that one new aircraft carrier would be built, at an estimated cost of £56 million, although the Treasury thought that the final cost was likely to be nearer £100 million. This was based on the carrier using the same aircraft as the Royal Air Force, the Hawker Siddeley P.1154 supersonic V/STOL aircraft (a larger version of what would become the Hawker Siddeley Harrier). After the General Election of October 1964, however, the new Labour Government wanted to cut back defence spending, and the RAF attacked the Royal Navy's carrier in an attempt to safeguard first its BAC TSR-2 strike/reconnaissance aircraft and then its proposed replacement, the General Dynamics F-111, from the cuts.

The new government, and by extension the Treasury, were particularly concerned about the size issues involved, as these were fluctuating quite frequently. They, therefore, demanded that the Admiralty keep to 53,000 tons. With the navy unwilling to alter the size of the carrier and its air group accordingly the difficulties spiraled, and the final tonnage was much more likely to be nearer 55,000 tons. The design issues also increased, including dramatically reduced top speed, deck space, armour, and radar equipment. When the Cabinet met in February 1966, the new Secretary of State for Defence, Denis Healey, strongly supported the RAF and their plan for long-range strike aircraft, by now the F-111, partially due to the cost issues of running fleet carriers, and partially due to opposition to a strong British military. This meeting resulted in the 1966 Defence White Paper. In this paper, the CVA-01 was finally canceled, along with the remainder of the Type 82 destroyers that would have been built as escorts, of which only HMS Bristol (D23) was eventually completed. Instead, plans were made for the modernisation of Eagle and Ark Royal. The final chief designer of CVA-01 said that by the time project was cancelled, so many design compromises had been made because of size and budget restrictions, that the whole project had become risky. The following year, a supplement to the review marked the ending of a global presence with the withdrawal of British presence "East of Suez". The year after, the purchase of F-111s was cancelled.

One argument about the cancellation of CVA-01 states that the RAF moved Australia by 500 miles in its documents to support the air force's preferred strategy of land-based aircraft. Regardless of the story's veracity, the principal reason for the cancellation was that the Defence Review Board believed adequate cover could be better provided East of Suez by RAF strike aircraft flying from bases in Australia and uninhabited islands in the Indian Ocean, rather than by a small carrier fleet in the 1970s which would have still included Hermes. The Review asserted the carrier's only effective use was to project British power East of Suez, and that the RN carriers were too 'vulnerable' for the RN's other major theatre in the North Atlantic. When the British government later decided in 1967 that it would withdraw from east of Suez, the case for carriers weakened further. The 1966 Review stated that the ability of the RAF to cover 300 miles offshore was enough for the 1970s, regardless of the RAF's contested claim of being able to provide air cover out to 700 miles. The cancellation of 150 TSR2 aircraft by Labour in mid-1965 was the basis of the RAF's argument for the 'island hopping strategy'.

Eagle and Ark Royal
The cancellation of CVA-01 was planned to be compensated for by the minimum updating of both Eagle and Ark Royal to enable them to operate the 52 Phantoms ordered. However, a decision was taken later to completely phase out fixed-wing flying in the Royal Navy by 1972 in line with withdrawal from "East of Suez". Victorious was withdrawn in 1969 and Hermes was converted to a "commando carrier" to replace her sister Albion, in 1971-73.

At the time of the announcement, Ark Royal was beginning a reconstruction with an austere refit of radar systems, communications, partial electrical rewiring, and fittings needed to allow operation of the Phantom (despite the fact that it was a worse base for such a conversion than Eagle), and it was deemed unacceptable either to cancel the much-needed work, or to spend such a large amount of money (approx. £32m) for less than three years continued use. A change of government led, as a consequence, to retain Ark Royal following her 1967–1970 refit, but not to proceed with a refit of Eagle. Eagle was decommissioned in 1972, partly due to damage inflicted in a partial grounding a year before; repairs would have probably required a minimum 18-month refit in 1972–1973 at a cost of around £40 million to operate till 1977. Many of the second squadron of F-4 Phantoms intended for Eagle were immediately transferred to the RAF. Eagle remained officially in reserve as a source of spares to maintain Ark Royal until 1978, but could never have been brought back into service.

"Through Deck Cruiser"
The Royal Navy did not however completely surrender aircraft carrier capability, despite the eventual withdrawal of Ark Royal in 1978. The concept of the "through-deck command cruiser" was first raised in the late 1960s when it became clear that there was a good chance of the Fleet Air Arm losing fixed-wing capability. The "through-deck cruiser" name was chosen to avoid the stigma of great expense attached to full-size aircraft carriers, with these 20,000-ton ships having significantly less fixed-wing aviation capability than the planned CVA-01 carriers. However, they were to function as part of combined NATO fleets, with a primary mission of providing Cold War anti-submarine patrols in the north-east Atlantic Ocean, in support of the American carrier battle groups.

In order to ensure the safety of the battle group around the "cruiser", the facility to carry the Sea Harrier was added at a late stage of development, the intention being that it could give the battle group the capability to intercept Soviet aircraft without having to rely either on land-based or US Navy interceptors. The ultimate result of this was the Royal Navy being able to deploy carrier-based aircraft during the Falklands War. One officer who worked on the CVA-01 believed, however, that had the United Kingdom "built two or three ships to this design, they would now [in 1999] be seen to have been the bargain of the century and they would have made the Falklands War a much less risky operation" due to greater functionality.

CVF
The United Kingdom returned to the fleet carrier idea with the construction of the Queen Elizabeth-class aircraft carriers, which are larger than the cancelled CVA-01s. The two new carriers, initially dubbed CVF (F for 'Future'), are named HMS Queen Elizabeth (R08) and HMS Prince of Wales (R09). The contract for these vessels was announced on 25 July 2007 by the Secretary of State for Defence Des Browne. Following Queen Elizabeth's commissioning on 7 December 2017, Prince of Wales was commissioned on 10 December 2019.

title: CVA-01


text:
Talk:Thomas de Littleton

Untitled
"the spirit of Norman feudalism than that a tenant of lands should dispose of them by will, we find Littleton directing by his will the feoffees of certain manors to make estates to the persons named in his will. In other words, in order to acquire over lands powers unknown to the common law, the lands had been conveyed to feoffees” who had full right over them according to the common law, but who were under a conscientious obligation to exercise those rights at the direction and for the exclusive benefit of the person to whose “ use” the lands were held. This conscientious obligation was recognized and enforced by the chancellor, and thus arose the class of equitable interests in lands. Littleton is the first writer on English law after these rights had risen into a prominent position, and it is curious to find to what extent they are ignored by him."

This text was at the end of the Brittanica article - I could not translate it, if anyone achieves understanding add it to the very end of the Brittanica.--OldakQuill 10:37, 3 May 2004 (UTC)

 * It's referring to the precurser to today's trusts. Littletons left some land to some feoffees (trustees) who would own the legal title to the land but were to control the land for the use of the beneficiaries. The Brittanica author is noting that while Littleton was certainly aware of this developing area of law, it's surprising that he didn't include any mention of it in his text. It's probably not worth putting it back in the article really. Lisiate 22:11, 7 Nov 2004 (UTC)

Why is "Sir" part of the article's name? This is not the convention I've seen on Wikipedia. RedWolf 01:43, May 5, 2004 (UTC)

You are correct and I have fixed it!--Samuel J. Howard 01:53, May 5, 2004 (UTC)

How can one change the note at the end of this article about its incorporating text from the 1911 Encyclopædia Britannica? I want the note to be clearer, stating that, at the moment, the bulk of this article is based wholly (or almost wholly) on the Britannica but that it is not entirely a verbatim transcript. That should be done so that nobody accidentally uses the Wikipedia article, making a verbatim quote of part of the Wiki text, and then saying that the verbatim quote is directly from Britannica—because it may well not be verbatim Britannica stuff anymore, now that edits have been made to the Wikipedia version. President Lethe 14:30, 16 November 2005 (UTC)

license: Creative Commons - Attribution Share-Alike - https://creativecommons.org/licenses/by-sa/4.0/

title: Talk:Thomas de Littleton


text:
Sheriffhales

Sheriffhales is a scattered village in Shropshire, England, 4 mi north-east of Telford, 3 mi north of Shifnal and 4 mi south of Newport. The name derives from Halh (Anglican) and scīr-rēfa (Old English) which is a combination of Hales (a nook of land, small valley) and Sheriff (a king's executive). At the time of the Domesday Book, it was held by Roger de Balliol the Sheriff of Shropshire.

As well as Sheriffhales itself, the modern civil parish of Sheriffhales includes the smaller settlements of Lilyhurst, Burlington, Heath Hill, Weston Heath, Redhill and Chadwell. The parish has a population of about 700 people, however it reached 1019 people in 1850, when the Duke of Sutherland owned most of it. The village was in Staffordshire until 1895 when the border between Staffordshire and Shropshire was moved. The population of the civil parish at the 2011 census was 722.

Despite being a small village of around 100 people, there is a primary school, a Church of England church (St Mary's) and a local post office, as well as a playing field with football goals and a children's playground. The church is a Grade II listed building that dates back to the 12th century.

Between 1663 and 1697, when its founder moved to London, Sheriffhales was home to a dissenting academy run by nonconformist minister John Woodhouse.

Sheriffhales was the site of the World War II PoW Camp 71, located along the drive to Lilleshall Hall. The camp was intended for Italian Prisoners of War and housed up to 2,000 until Italy surrendered in 1943; thereafter it was used to house German PoW's until 1948 when most were repatriated.

The 2007 Tour of Britain bike race passed through the village on the first of September as part of the Wolverhampton to Birmingham stage.

The main farm within the village, Meadow Farm, was a predominantly dairy farm, but has been subsequently converted into an arable farm. It is also the centre for a point to point yard.

Sheriffhales is mentioned (under the name "Hales") in the Ellis Peters novel The Confession of Brother Haluin.

Hope Vere Anderson is Lord of the Manor of Sheriffhales and descends from the senior branch of the Hope Vere's of Lesmahagow, Scotland. The Hope Vere's trace their ancestry to Roger De Vere who was Lord of the Manor of Hales and when he became Sheriff of Shropshire in the 16th century he changed the name of his Manor from that of Hales to Sheriffhales to reflect his importance in being appointed to this additional role.

title: Sheriffhales


text:
Talk:Sheriffhales

Untitled
Text taken from: History, Gazetteer and Directory of Staffordshire, William White, Sheffield, 1851.

Dating
The de Veres were medieval sheriffs. The manor belonged to the Leveson family in the 16th century. Sjwells53 (talk) 18:58, 12 January 2016 (UTC)

 * There are certainly no de Vere's occurring in wikipedia's list of High Sheriff of Shropshire in the 1500s, and I am altogether sceptical that the following uncited statement in this article is genuine or merely made up to account for the village's present name: The Hope Vere's trace their ancestry to Roger De Vere who was Lord of the Manor of Hales and when he became Sheriff of Shropshire in the 16th century he changed the name of his Manor from that of Hales to Sheriffhales to reflect his importance in being appointed to this additional role.Cloptonson (talk) 18:34, 29 December 2020 (UTC)

Meaning of `Anglican'
The explanation of the word `halh' is that it is Anglican. But Anglican means `descriptive of, or concerning the Church of England'. Clarification is needed. Barney Bruchstein (talk) 19:58, 23 July 2020 (UTC)

title: Talk:Sheriffhales


text:
1966 Defence White Paper

The 1966 Defence White Paper (Command Papers 2592 and 2901) was a major review of the United Kingdom's defence policy initiated by the Labour government under Prime Minister Harold Wilson. The review was led by the Secretary of State for Defence, Denis Healey. The document was centred on the need to support NATO in Europe and made the commitment that the UK, "would not undertake major operations of war except in co-operation with allies." The 1966 announcements undertook to retain the UK presence in Singapore and Malaysia.

However, the mid-late sixties brought an economic crisis and the devaluation of pound sterling. In 1967 and 1968, the government published two further supplements to the review, announcing the strategic withdrawal of British forces deployed East of Suez. This marked a watershed in British foreign policy and the end of a major, enduring world-wide military role.

Contents
The Wilson Government decided on significant reductions in the defence budget, with defence being the primary target of the government's efforts to reduce public spending due to wider economic problems. The outcome of the Review resulted in cutting a number of significant new capital projects, including the CVA-01 aircraft carrier and all but one of the Type 82 destroyers. This was to be part of a phased removal of aircraft carrier capability. Instead, investment would be made in aircraft including the Harrier, the Anglo-French AFVG (which later came to fruition as the Panavia Tornado) and the American F-111 bomber (the latter following the cancellation of the TSR-2 program).

In order to concentrate forces in Europe in support of NATO, the review also recommended withdrawal of the British presence in Aden. The 1967 supplement added accelerated withdrawals from Singapore, Malaysia, Malta, Libya and the Persian Gulf, reversing the election commitment to retaining an East of Suez military role. The 1968 supplement additionally cancelled the order for the F-111.

Inter-Service Rivalry and the Defence Budget
In the early 1960s, the Royal Navy began to plan for new aircraft carriers to replace its aging fleet. The Royal Air Force saw the renewal as a chance to win the budget share which would have been necessary for new carriers. The RAF compiled a history of Royal Navy aircraft carriers and a history of Royal Air Force tactical bombers, comparing the two and finding in favour of bombers. They then submitted this to the Treasury, proposing the TSR-2 tactical strike aircraft in place of the RN's new generation aircraft carriers. Professor Andrew Lambert has described the 1966 Defence White Paper as the 'perfect example of what happens if your enemy knows your history better than you do', with the RAF's projects doing better in the 1966 review than the Royal Navy's.

Dr. Jeffrey Bradford, Research Director of the United Kingdom Defence Forum wrote a paper as part of a doctoral research program covering in detail the inter-service rivalry surrounding the procurement effort for the CVA-01 against the backdrop of the defence reviews of the mid 1960s

Implementation
All British forces were withdrawn from Aden by the end of November 1967, despite the ongoing Aden Emergency. Along with the withdrawal from the Persian Gulf, this left bases in Oman as the only UK installations in the Middle East by the mid-seventies. The final installations, the RAF bases at Salalah and on Masirah Island, closed in 1976 following the end of the Dhufar rebellion.

In the Far East, the bulk of British forces left Singapore following a ceremony involving 20 ships including aircraft carrier HMS Hermes in October 1971. Security for Singapore and Malaysia was partially handed to Australian and New Zealand forces as part of the Five Power Defence Arrangements, which are still in place today. The British Far East Command was terminated on 31 October 1971, although a smaller British presence remained in the area until 1976. British forces also remained based in Hong Kong and Brunei.

Both the F-111 order and the AFVG bombers were later cancelled, although the latter evolved into the Panavia Tornado, which was delivered in 1979 and was still in service with the RAF in 2018. One Type 82 Destroyer was built, HMS Bristol, as a test-bed for new technologies. No new large aircraft carriers were built, although naval aviation continued with the construction of smaller Invincible-class aircraft carriers during the 1970s.

title: 1966 Defence White Paper


text:
Numerical Recipes

Numerical Recipes is the generic title of a series of books on algorithms and numerical analysis by William H. Press, Saul A. Teukolsky, William T. Vetterling and Brian P. Flannery. In various editions, the books have been in print since 1986. The most recent edition was published in 2007.

Overview
The Numerical Recipes books cover a range of topics that include both classical numerical analysis (interpolation, integration, linear algebra, differential equations, and so on), signal processing (Fourier methods, filtering), statistical treatment of data, and a few topics in machine learning (hidden Markov model, support vector machines). The writing style is accessible and has an informal tone. The emphasis is on understanding the underlying basics of techniques, not on the refinements that may, in practice, be needed to achieve optimal performance and reliability. Few results are proved with any degree of rigor, although the ideas behind proofs are often sketched, and references are given. Importantly, virtually all methods that are discussed are also implemented in a programming language, with the code printed in the book. Each version is keyed to a specific language.

According to the publisher, Cambridge University Press, the Numerical Recipes books are historically the all-time best-selling books on scientific programming methods. In recent years, Numerical Recipes books have been cited in the scientific literature more than 3000 times per year according to ISI Web of Knowledge (e.g., 3962 times in the year 2008). And as of the end of 2017, the book had over 44000 citations on Google Scholar.

History
The first publication was in 1986 with the title,”Numerical Recipes, The Art of Scientific Computing”, containing code in both Fortran and Pascal; an accompanying book, “Numerical Recipes Example Book (Pascal)” was first published in 1985. (A preface note in “Examples" mentions that the main book was also published in 1985, but the official note in that book says 1986.) Supplemental editions followed with code in Pascal, BASIC, and C. Numerical Recipes took, from the start, an opinionated editorial position at odds with the conventional wisdom of the numerical analysis community:

If there is a single dominant theme in this book, it is that practical methods of numerical computation can be simultaneously efficient, clever, and — important — clear. The alternative viewpoint, that efficient computational methods must necessarily be so arcane and complex as to be useful only in "black box" form, we firmly reject.

However, as it turned out, the 1980s were fertile years for the "black box" side, yielding important libraries such as BLAS and LAPACK, and integrated environments like MATLAB and Mathematica. By the early 1990s, when Second Edition versions of Numerical Recipes (with code in C, Fortran-77, and Fortran-90) were published, it was clear that the constituency for Numerical Recipes was by no means the majority of scientists doing computation, but only that slice that lived between the more mathematical numerical analysts and the larger community using integrated environments. The Second Edition versions occupied a stable role in this niche environment.

By the mid-2000s, the practice of scientific computing had been radically altered by the mature Internet and Web. Recognizing that their Numerical Recipes books were increasingly valued more for their explanatory text than for their code examples, the authors significantly expanded the scope of the book, and significantly rewrote a large part of the text. They continued to include code, still printed in the book, now in C++, for every method discussed. The Third Edition was also released as an electronic book, eventually made available on the Web for free (with nags) or by paid or institutional subscription (with faster, full access and no nags).

In 2015 Numerical Recipes sold its historic two-letter domain name nr.com and became  instead.

Content
Numerical Recipes is a single volume that covers very broad range of algorithms. Unfortunately that format skewed the choice of algorithms towards simpler and shorter early algorithms which were not as accurate, efficient or stable as later more complex algorithms. The first edition had also some minor bugs, which were fixed in later editions; however according to the authors for years they were encountering on the internet rumors that Numerical Recipes is "full of bugs". They attributed this to people using outdated versions of the code, bugs in other parts of the code and misuse of routines which require some understanding to use correctly.

The rebuttal does not, however, cover criticisms regarding lack of mentions to code limitations, boundary conditions, and more modern algorithms, another theme in Snyder's comment compilation. A precision issue in Bessel functions has persisted to the third edition according to Pavel Holoborodko.

Despite criticism by numerical analysts, engineers and scientists generally find the book conveniently broad in scope. Norman Gray concurs in the following quote: "Numerical Recipes [nr] does not claim to be a numerical analysis textbook, and it makes a point of noting that its authors are (astro-)physicists and engineers rather than analysts, and so share the motivations and impatience of the book's intended audience. The declared premise of the NR authors is that you will come to grief one way or the other if you use numerical routines you do not understand. They attempt to give you enough mathematical detail that you understand the routines they present, in enough depth that you can diagnose problems when they occur, and make more sophisticated choices about replacements when the NR routines run out of steam. Problems will occur because [...]"

License
The code listings are copyrighted and commercially licensed by the Numerical Recipes authors. A license to use the code is given with the purchase of a book, but the terms of use are highly restrictive. For example, programmers need to make sure NR code cannot be extracted from their finished programs and used – a difficult requirement with dubious enforceability.

However, Numerical Recipes does include the following statement regarding copyrights on computer programs:"Copyright does not protect ideas, but only the expression of those ideas in a particular form. In the case of a computer program, the ideas consist of the program's methodology and algorithm, including the necessary sequence of steps adopted by the programmer. The expression of those ideas is the program source code... If you analyze the ideas contained in a program, and then express those ideas in your own completely different implementation, then that new program implementation belongs to you."

One early motivation for the GNU Scientific Library was that a free library was needed as a substitute for Numerical Recipes.

Style
Another line of criticism centers on the coding style of the books, which strike some modern readers as "Fortran-ish", though written in contemporary, object-oriented C++. The authors have defended their very terse coding style as necessary to the format of the book because of space limitations and for readability.

Titles in the series (partial list)
The books differ by edition (1st, 2nd, and 3rd) and by the computer language in which the code is given.

 * Numerical Recipes. The Art of Scientific Computing, 1st Edition, 1986, ISBN 0-521-30811-9. (Fortran and Pascal)
 * Numerical Recipes in C. The Art of Scientific Computing, 1st Edition, 1988, ISBN 0-521-35465-X.
 * Numerical Recipes in Pascal. The Art of Scientific Computing, 1st Edition, 1989, ISBN 0-521-37516-9.
 * Numerical Recipes in Fortran. The Art of Scientific Computing, 1st Edition, 1989, ISBN 0-521-38330-7.
 * Numerical Recipes in BASIC. The Art of Scientific Computing, 1st Edition, 1991, ISBN 0-521-40689-7. (supplemental edition)
 * Numerical Recipes in Fortran 77. The Art of Scientific Computing, 2nd Edition, 1992, ISBN 0-521-43064-X.
 * Numerical Recipes in C. The Art of Scientific Computing, 2nd Edition, 1992, ISBN 0-521-43108-5.
 * Numerical Recipes in Fortran 90. The Art of Parallel Scientific Computing, 2nd Edition, 1996, ISBN 0-521-57439-0.
 * Numerical Recipes in C++. The Art of Scientific Computing, 2nd Edition, 2002, ISBN 0-521-75033-4.
 * Numerical Recipes. The Art of Scientific Computing, 3rd Edition, 2007, ISBN 0-521-88068-8. (C++ code)

The books are published by Cambridge University Press.

title: Numerical Recipes


text:
Titanic Brewery

The Titanic Brewery is an independent producer of bottle conditioned and cask ales in Burslem, Stoke-on-Trent, England.

Titanic's beers are generally notable for their light colour, low malt, and high hop content, giving a very dry bitter taste, although Captain Smith's and some of their seasonal beers are dark and malty, though still extremely hoppy. Their seasonal ranges also include lighter and fruity ales such as 2019 seasonal beer, Kiwi Fleet, which is made with New Zealand hops.

History
The brewery was founded in Burslem, Stoke-on-Trent, in 1985 by John Pazio, and is now run by brothers Keith and Dave Bott, and takes its name from the ill-fated steam liner Titanic. It is in honour of its captain Edward Smith (who came from Stoke-on-Trent) that the brewery is named.

One of the owners, Keith Bott, was formerly the chairman of SIBA, the Society of Independent Brewers.

Products
Its 'Fleet' range of beers include:

 * Plum Porter (4.9% abv)
 * Titanic Mild (3.5% abv)
 * Steerage (formerly Titanic Best Bitter) (3.8% abv)
 * Anchor ABV (4.1% abv)
 * Iceberg (4.1% abv)
 * Titanic Stout (4.5% abv)
 * White Star (4.5% abv)
 * Captain Smith's Strong Ale (5.2% abv)

All of these, bar the Mild are available in bottles from the brewery, the brewery tap, and supermarkets. They produce over 4 million pints every year.

Titanic have also branched out into distilling their own gin.

Pubs
Titanic Brewery presently runs eight pubs in North Staffordshire, Derbyshire and Oxfordshire: The Bull's Head in Burslem, The White Star in Stoke, The Greyhound in Newcastle-under-Lyme, The Royal Exchange in Stone, The Sun Inn in Stafford, The Roebuck in Leek, The Cheshire Cheese in Buxton, The Royal Blenheim in Oxford and the Old Poets Corner in Ashover.

Café bars
Titanic Brewery also runs eight 'Bod' café bars in the Staffordshire area: in Alsager, Lichfield, Matlock, Newport, Stafford, Stoke-on-Trent railway station, Stone and Trentham.

Awards
The Titanic Brewery has won many awards, often awarded by CAMRA (the Campaign for Real Ale), from the 1990s to the present day.

The Titanic Brewery's bottled Stout beer's first award was Gold in the 1994 Guardian Bottled Beer of Britain, and more recently it won first place in the CAMRA West Midlands Beer of the Year 2009 (Stout Category). Titanic's Iceberg Beer won its first award in 2002, achieving Gold in the CAMRA Champion Beer of the West Midlands category, and again more recently achieved first place in the CAMRA West Midlands Beer of the Year (Speciality Category).

title: Titanic Brewery


text:
Thunk

In computer programming, a thunk is a subroutine used to inject a calculation into another subroutine. Thunks are primarily used to delay a calculation until its result is needed, or to insert operations at the beginning or end of the other subroutine. They have many other applications in compiler code generation and modular programming.

The term originated as a whimsical irregular form of the verb think. It refers to the original use of thunks in ALGOL 60 compilers, which required special analysis (thought) to determine what type of routine to generate.

Background
The early years of compiler research saw broad experimentation with different evaluation strategies. A key question was how to compile a subroutine call if the arguments can be arbitrary mathematical expressions rather than constants. One approach, known as "call by value", calculates all of the arguments before the call and then passes the resulting values to the subroutine. In the rival "call by name" approach, the subroutine receives the unevaluated argument expression and must evaluate it.

A simple implementation of "call by name" might substitute the code of an argument expression for each appearance of the corresponding parameter in the subroutine, but this can produce multiple versions of the subroutine and multiple copies of the expression code. As an improvement, the compiler can generate a helper subroutine, called a thunk, that calculates the value of the argument. The address and environment of this helper subroutine are then passed to the original subroutine in place of the original argument, where it can be called as many times as needed. Peter Ingerman first described thunks in reference to the ALGOL 60 programming language, which supports call-by-name evaluation.

Functional programming
Although the software industry largely standardized on call-by-value and call-by-reference evaluation, active study of call-by-name continued in the functional programming community. This research produced a series of lazy evaluation programming languages in which some variant of call-by-name is the standard evaluation strategy. Compilers for these languages, such as the Glasgow Haskell Compiler, have relied heavily on thunks, with the added feature that the thunks save their initial result so that they can avoid recalculating it; this is known as memoization or call-by-need.

Functional programming languages have also allowed programmers to explicitly generate thunks. This is done in source code by wrapping an argument expression in an anonymous function that has no parameters of its own. This prevents the expression from being evaluated until a receiving function calls the anonymous function, thereby achieving the same effect as call-by-name. The adoption of anonymous functions into other programming languages has made this capability widely available.

The following is a simple demonstration in JavaScript (ES6):

Object-oriented programming
Thunks are useful in object-oriented programming platforms that allow a class to inherit multiple interfaces, leading to situations where the same method might be called via any of several interfaces. The following code illustrates such a situation in C++.

In this example, the code generated for each of the classes A, B and C will include a dispatch table that can be used to call Access on an object of that type, via a reference that has the same type. Class C will have an additional dispatch table, used to call Access on an object of type C via a reference of type B. The expression b->Access will use B's own dispatch table or the additional C table, depending on the type of object b refers to. If it refers to an object of type C, the compiler must ensure that C's Access implementation receives an instance address for the entire C object, rather than the inherited B part of that object.

As a direct approach to this pointer adjustment problem, the compiler can include an integer offset in each dispatch table entry. This offset is the difference between the reference's address and the address required by the method implementation. The code generated for each call through these dispatch tables must then retrieve the offset and use it to adjust the instance address before calling the method.

The solution just described has problems similar to the naïve implementation of call-by-name described earlier: the compiler generates several copies of code to calculate an argument (the instance address), while also increasing the dispatch table sizes to hold the offsets. As an alternative, the compiler can generate an adjustor thunk along with C's implementation of Access that adjusts the instance address by the required amount and then calls the method. The thunk can appear in C's dispatch table for B, thereby eliminating the need for callers to adjust the address themselves.

Numerical calculations requiring evaluations at multiple points
Routines for computations such as integration need to calculate an expression at multiple points. Call by name was used for this purpose in languages that didn't support closures or procedure parameters.

Interoperability
Thunks have been widely used to provide interoperability between software modules whose routines cannot call each other directly. This may occur because the routines have different calling conventions, run in different CPU modes or address spaces, or at least one runs in a virtual machine. A compiler (or other tool) can solve this problem by generating a thunk that automates the additional steps needed to call the target routine, whether that is transforming arguments, copying them to another location, or switching the CPU mode. A successful thunk minimizes the extra work the caller must do compared to a normal call.

Much of the literature on interoperability thunks relates to various Wintel platforms, including MS-DOS, OS/2, Windows   and .NET, and to the transition from 16-bit to 32-bit memory addressing. As customers have migrated from one platform to another, thunks have been essential to support legacy software written for the older platforms.

The transition from 32-bit to 64-bit code on x86 also uses a form of thunking (WoW64). However, because the x86-64 address space is larger than the one available to 32-bit code, the old "generic thunk" mechanism could not be used to call 64-bit code from 32-bit code. The only case of 32-bit code calling 64-bit code is in the WoW64's thunking of Windows APIs to 32-bit.

Overlays and dynamic linking
On systems that lack automatic virtual memory hardware, thunks can implement a limited form of virtual memory known as overlays. With overlays, a developer divides a program's code into segments that can be loaded and unloaded independently, and identifies the entry points into each segment. A segment that calls into another segment must do so indirectly via a branch table. When a segment is in memory, its branch table entries jump into the segment. When a segment is unloaded, its entries are replaced with "reload thunks" that can reload it on demand.

Similarly, systems that dynamically link modules of a program together at run-time can use thunks to connect the modules. Each module can call the others through a table of thunks that the linker fills in when it loads the module. This way the modules can interact without prior knowledge of where they are located in memory.

Thunk technologies

 * DOS Protected Mode Interface (DPMI)
 * DOS Protected Mode Services (DPMS)
 * J/Direct
 * Microsoft Layer for Unicode
 * Platform Invocation Services
 * Win32s
 * Windows on Windows
 * WoW64
 * libffi

Related concepts

 * Anonymous function
 * Futures and promises
 * Remote procedure call
 * Shim (computing)
 * Trampoline (computing)
 * Reducible expression

title: Thunk


text:
Talk:Thunk

Untitled
On the topic of LISP..

''Not so, a thunk stored in a SASL list allows delayed evaluation of the thunk until the value is absolutely needed, a common example is a list of all prime numbers where the list of elements are represented with a thunk that is used to derive the prime numbers, filling in the contents with the primes as they are provided by the thunk, thus allowing repeated accesses of the same list elements takes constant time because they are already evaluated. The thunk requires access to the list indices (thunk implemented as a lambda function). ''.

Actually, a lambda function can be used to create a list of thunks, but the thunks are determined by the lambda function, so.. It's been a while since I've coded LISP, ever since I learned the language, great for learning but I wouldn't code in it.. Ask Suzanne Sluizer she knows..

--Rofthorax 09:56, 24 August 2005 (UTC)

-

No No No! Thunking is more general than that! Probably needs a reference to Algol implementations which used thunking... -- 81.79.64.46 11:14, 3 May 2004 (UTC)

For a good discussion, see:

http://compilers.iecc.com/comparch/article/98-03-043

The legend that I heard was that, generically, a "thunk" is a function (or procedure) which takes no arguments, and returns no values, and that it was coined by Donald Knuth in The Art of Computer Programming, who came up with thunk as an anagram of his surname, and as a way to describe a minimal function. I don't have my copy handy to verify. But this seems like a general definition which would apply to invoking the continuation of closures, which usually take much longer than a little thunk should.

According to the Internet's famous jargon file:

File: jargon.info

 * thunk: /thuhnk/ n. 1. "A piece of coding which provides an

address", according to P. Z. Ingerman, who invented thunks  in 1961 as a way of binding actual parameters to their formal   definitions in Algol-60 procedure calls.  If a procedure is called   with an expression in the place of a formal parameter, the compiler   generates a {thunk} to compute the expression and leave the   address of the result in some standard location.  2. Later   generalized into: an expression, frozen together with its   environment, for later evaluation if and when needed (similar to   what in techspeak is called a `closure').  The process of   unfreezing these thunks is called `forcing'.  3. A   {stubroutine}, in an overlay programming environment, that loads   and jumps to the correct overlay.  Compare {trampoline}.   4. People and activities scheduled in a thunklike manner.  "It occurred to me the other day that I am rather accurately modeled by  a thunk --- I frequently need to be forced to completion." ---   paraphrased from a {plan file}.

Historical note: There are a couple of onomatopoeic myths circulating about the origin of this term. The most common is that it is the sound made by data hitting the stack; another holds that the sound is that of the data hitting an accumulator. Yet another holds that it is the sound of the expression being unfrozen at  argument-evaluation time. In fact, according to the inventors, it  was coined after they realized (in the wee hours after hours of   discussion) that the type of an argument in Algol-60 could be   figured out in advance with a little compile-time thought, simplifying the evaluation machinery. In other words, it had `already been thought of'; thus it was christened a `thunk', which is "the past tense of `think' at two in the morning".

 * I'd read this before too, which is why the "no known root" at the top of the article surprised me. Could someone paraphrase the "past tense of think" explanation in the article? I'm too tired to do it well right now. PeteVerdon 21:34, 2 January 2006 (UTC)

 * Is the Jargon File really reliable enough to be included in encyclopedic content? If there's an actual non-speculative source for the "past tense of think" explanation, that ought to be cited -- otherwise I don't think that the possible etymology of the word is really important enough to be included, since there are at least three distinct, unverified etymologies floating around.  --bmills 20:25, 5 January 2006 (UTC)

 * who would have thunk it? --ZhuLien 2:14, 26 March 2007 (UTC)

 *  The link to the Ingerman article is 404, but a friend wrote to me: “As an ACM member, I have easy access to the "thunk" article. It is attached. Ingerman does not give etymology, but he mentions the charming term "FUSBUDGET mechanism".” I've corrected the volume number (Vol. 4, not Vol. 1); see January 1961 Table of Contents. -- Thnidu (talk) 00:45, 20 May 2010 (UTC)

Splittify me!
As far as my mind can tell (which is quite far, I believe), two meanings of the word "thunk" are used on this page. I feel that each should have a separate page... I dunno why, though :-) --Ihope127 03:42, 22 August 2005 (UTC)

 * I reckon all 3 meanings should be split. The non-computer term is the most commonly used one I'd guess as the computer terms would only be used by programmers. --ZhuLien 13:08, 23 July 2006 (GMT+10)

 * Definitely. The senses i can identify are:
 * Delayed evaluation, explicitly or as part of call by name/need. (Thunk (functional programming)?)
 * OS/2 / Windows address space conversion.
 * Dynamic linking. (Sounds very much like trampolining.)
 * I'm not sure i get the "to describe a specific type of adapter" section; it sounds very non-canonical.  --Piet Delport 14:51, 13 April 2007 (UTC)

 * I agree, as well. These seem like different things, each significant enough to merit an individual article. Thunk 04:03, 29 May 2007 (UTC)

 * Don't split. These are not unrelated concepts; they are born of similar needs in loader design. For someone who is trying to design/change/improve a loader, its nice to have one article that discusses all the various manifestations of the general idea of thunking. Its not like this article is too long, or anything.  linas (talk) 20:42, 27 December 2007 (UTC)
 * To be clear, the thunk in object-oriented programming has flavors of both a run-time reference resolution (which is, in fact, the one place where OO programmers do get explicitly bitten by thunking mistakes), and it has a flavour of dynamic linking resolution. So, at some superficial level, the different implementations of thunks discussed in this article seem distinct, they are in fact different manifestations of the same core design requirement. linas (talk) 20:54, 27 December 2007 (UTC)

I say split. Thunks are a mechanism for delayed computation of values. The OOP-related thing and the Microsoft-specific "hack" stuff definitely have nothing to do with that---those sound more like "stubs", which is the term I would use for bits of code that stand in for calling other code. Of course I'm not saying we should get rid of that info, but it could be split into separate articles or perhaps merged into something more relevant. --cos —Preceding unsigned comment added by 129.67.53.183 (talk) 23:40, 22 October 2009 (UTC)

 * I say split thunk(computing) from thunk(dialectics). The multiple algorithmic senses of Thunk should be grouped on one page. The sense of Thunk, that is more like a dialectical koan, should be on its own page. U664003803 (talk) 23:44, 25 February 2010 (UTC)

I agree, there is a need to split. The third point is definitely specific to Windows and should be in another page than the two first generic notions. Should we first agree on that ? (and on dialectics also, of course !) —Preceding unsigned comment added by 134.157.168.24 (talk) 16:47, 26 February 2010 (UTC)

 * Where is thunk(dialectics). Why the first section has been completely removed ?  —Preceding unsigned comment added by 83.202.168.142 (talk) 13:32, 7 March 2010 (UTC)

Flat thunk
I removed the following and replaced it with a shorter summary based on the first half:

A flat thunk consists of a pair of dlls (one 32bit and one 16bit) that are used to translate calls from 32bit code to 16bit code. To allow the two dlls to communicate, some intermediate code must be used to translate memory addresses (pointers) between platforms. If you have any past experience with 16bit process memory calls, you may recall that they consist of a pointer to a memory segment and the offset into that memory segment. This is different than a 32bit process memory pointer which consists of an absolute address to the memory being accessed. So, the problem, in a nutshell, is translating segment + offset pointers into absolute addresses. VB programmers don't usually need to worry about things like memory pointers, but the problem is that ALL software is ultimately based on memory pointers. It is the IDE and the programming language that hide these ugly details from us but when you get right down to it, every variable, function, sub and etc... that you write (in any language) consists of an address in memory. Now, imagine a 16bit dll being loaded into a 32bit process where none of the memory addresses match up on either side of the function calls. It just plain can't be done without proper translation. By Gaurav Bhaskar Microsft Support v-2gabha@mssupport.microsoft.com

Cammy 19:25, 29 December 2006 (UTC)

Jensen's device

 * The first example I had given of thunking was in terms of the use of Jensen's device (call by name) to implement read/write or get/put macros (where a separate IO routine was called by reference) in IBM OS360.

I deleted this fragment. I'm putting in here in case anybody wants to expand and properly cite it into an encyclopedic paragraph. --shadytrees 17:50, 16 July 2007 (UTC)

Common Lisp's
It does not belong under a heading of "delayed computation", as  is a function and hence its argument is evaluated when the "thunk" is created, not when used. 70.111.106.99 (talk) 21:00, 3 January 2008 (UTC)

Untitled
The code examples in this article are too obscure to be informative. They don't so much demonstrate the use of thunks as they show bits of Algol or some such. It would perhaps be more useful to say that thunks are in fact a data structure that contains a reference to code as well as an environment to execute that code in (the env might be a stack frame or dictionary pointer -- it's a place that somehow holds mappings between variables and values).

For instance:

variable a = 7;

def foo(a); // NB: two vars called a    print a + 2; enddef;

foo(a + 10);

When foo is called in an eager language, the expression (a + 10) is evaluated before the function is called, and the value passed in is 17. foo will print the value of (17 + 2) = 19 (not 7 + 2), as it uses the latest definition of a, which is the one local to the function.

In a lazy language, instead of evaluating (a + 10) before passing it into foo, the code of the expression just gets wrapped up in a thunk along with current variable mappings as [(a + 10), {a -> 7}] and that gets passed in. When foo tries to print the value of (a + 2), the thunk that is now in the local variable a is executed using the environment it carries in it, not the one of foo, so we get (17 + 2), which is printed as 19. The point to note is that in principle you shouldn't have the same bit of code executing in environments it doesn't belong to (this relates to lambda calculus and how you can't subst RHS expressions that use the same variables as the LHS expressions).

Thunks can help with some infinite loops. Consider the following Haskell code (a lazy language):

-- takes two args and returns the first first x y = x

-- infinite recursion infinity = let loop k = loop (k+1) in loop 0

first 5 infinity => PRINTS 5

The infinite recursion is never evaluated, as it's never used by the program. It only ever uses the first arg of the function, and the second just stays a thunk and is not expanded. An eager language would try to get a value for infinity before calling first. At this point it may be worth looking into innermost vs outermost reduction.

While thunks can be useful in this way, they have their disadvantages: creating and destroying thunks all the time can make programs slow. Thunks that contain side-effects (e.g. print a value to the screen) may not execute in the order the programmer intended as their contents are only evaluated whenever the function called tries to use their value (if at all).

There are some interesting exceptions in common langs like C and Java where this sort of lazy thing is used (but not using thunks). For instance, if statements only execute one of their branches, which is a bit of forced lazy evaluation.

Just some points that could be used to spruce this article up, or that people can read up on if they're interested in this sort of thing.

--cos

- —Preceding unsigned comment added by 129.67.53.183 (talk) 19:05, 22 October 2009 (UTC)

The Algol 60 thunk is not the same thing as lazy evaluation because the semantics are that it is re-evaluated for each use, not only on first use (the article "lazy evaluation" makes this distinction very early). That is why Jensen's device "works".

Nor is it a "delayed computation" because its value is the value at the point of use not at some earlier time. It is not in general possible to evaluate it any earlier, so it is not delayed. Of course, in a given use, one or both of these things might be true but that is a property of the program, not of the thunk itself.

BTW, if I remember correctly, and to nit pick, addresses (aka "names") are not part of the value domain in Algol 60, in which case, these thunks do not return values.

The C thing that cos mentions I would not describe as lazy evaluation but consecutional evaluation. The difference being that in the consecutional case, the expression is never referenced (i.e. bound), as against the value never being needed but the expression having been referenced. The difference may appear subtle but it is conceivable that in a (imagined) language with precise exception semantics the lazy case might throw an exception at the point of being bound while the consecutional case might not.

There should, perhaps, be an article for consecutional semantics.

Noticing the similarities between these concepts is useful, but we should also be careful to notice their differences. -- dlm —Preceding unsigned comment added by 192.55.54.38 (talk) 13:50, 17 May 2011 (UTC)

32-bit software in 64-bit Windows
Please can someone write a section explaining why running 32-bit programs on 64-bit Windows is not considered thunking. —Preceding unsigned comment added by 198.54.202.114 (talk) 15:43, 18 September 2010 (UTC)

Addition of example assembly compilation for example code (thunk_for_C_access_in_B)
Do people think (no semi-pun intended) that it would be useful to put an example of the assembly code a compiler would generate for the wrapper function in the example? It talks about how the function saves time on average (one expensive operation and one cheap operation in one case, and an addition of only a heap branch in another case), but it's kind of hard to see that without knowing what exact instructions are generated. I don't quite understand it well enough to write such :) - but I've seen this kind of code (Newton ROM - ArM Norcraft-compiled C++ [0.43/C4.68 (rel195/Newton Release 9); 1996]). I can sat that it looks like a mess of jumps, and I think seeing a "simple" assembly compilation of this pattern would help understanding (to the extent that Wikipedia CS articles are a psudo-textbook..)

Also, why doesn't the Talk page for  automatically redirect here to  ? — Preceding unsigned comment added by 98.223.232.121 (talk) 16:42, 21 December 2011 (UTC)

SQL and Ajax examples
The Thunk (compatibility mapping) page (which I'm merging back here) has these two examples.

 * For example, when reading a foreign key from a database table an obvious requirement is to make the join to the related table. Thunk can be used as the term for making this explicit join within the constraints of a hand-created SQL stored procedure generator. Another example is in generic message interceptors (such as generic mouse-click interceptors within auto-enabling Ajax JavaScript libraries). The overall process of intercepting the generic mouse-click message, determining registered handlers, dispatching to those handlers, retrieving results, and applying results to the current page can be described as "thunking" the mouse-click event. In this sense, "to thunk" describes the overall process of detecting a condition that requires re-translation and/or re-packaging of the initial data along with the dispatching and/or handling computer code to support the required action.

I don't know what this paragraph is talking about, nor are there sources that might help me understand. The second one is maybe trying to say that "thunking" = "event-driven programming", but then it's wrong and by all appearances original research. Nonetheless I'm leaving the examples here in case I'm mistaken. 50.136.204.132 (talk) 10:10, 7 March 2014 (UTC)

Article re-merged
This article was split in Feb. 2011. This was its state at the time: disjointed, poorly formatted, jargon-heavy, filled with examples but very little explanation. So little explanation that editors were convinced that the article was talking about several unrelated concepts. It was not. All the meanings of "thunk" here (except the ones I pasted above) are practical evolutions of Ingerman's "computations as parameters" concept. They differ with regard to the reason that a computation is needed, and how it is generated (by the compiler, another compile-time tool, or a run-time service). There should be one article, and now there is. 50.136.204.132 (talk) 07:36, 9 March 2014 (UTC)

What about simplifying "Object-oriented programming" section ?
IMHO, example in this section is uselessly complicated, since it uses a class A which merely appears in the example while being irrelevant to the issue discussed.

To achieve the improvement goal requested in the header of "Thunk" page, class A could be suppressed and class B and class C could be renamed into class A and class B respectively, thus making clearer the intrisic issue of the case shown.

This would yield something like:

Object-oriented programming
Thunks are useful in object-oriented programming platforms that allow a class to inherit multiple interfaces, leading to situations where the same method might be called via any of several interfaces. The following code illustrates such a situation in C++.

In this example, the code generated for each of the classes A and B will include a dispatch table that can be used to call access on an object of that type, via a reference that has the same type. Class B will have an additional dispatch table, used to call access on an object of type B via a reference of type A. The expression a->access will use A's own dispatch table or the additional B table, depending on the type of object a refers to. If it refers to an object of type B, the compiler must ensure that B's access implementation receives an instance address for the entire B object, rather than just the inherited A part of that object.

As a direct approach to this pointer adjustment problem, the compiler can include an integer offset in each dispatch table entry. This offset is the difference between the reference's address and the address required by the method implementation. The code generated for each call through these dispatch tables must then retrieve the offset and use it to adjust the instance address before calling the method.

The solution just described has problems similar to the naïve implementation of call-by-name described earlier: the compiler generates several copies of code to calculate an argument (the instance address), while also increasing the dispatch table sizes to hold the offsets. As an alternative, the compiler can generate an adjustor thunk along with B's implementation of access that adjusts the instance address by the required amount and then calls the method. The thunk can appear in B's dispatch table for A, thereby eliminating the need for callers to adjust the address themselves.

Examples
One of the uses for thunks is a numeric computation which repeatedly invokes a subcomputation with different inputs, e.g., an integration routine. In ALGOL 60 such a routine would normally be written as a procedure with a call-by-name parameter for the subcomputation. In some other languages it would probably be coded with a procedure parameter, avoiding the need for a thunk. I believe that Thunk should have a subsection with examples of such uses, but am not sure what it should be called. Shmuel (Seymour J.) Metz Username:Chatul (talk) 17:45, 3 May 2016 (UTC)

Environment of thunk
To the text "The address and environment of this helper subroutine," Chatul added the annotation that the environment of the helper routine (the thunk) is not the environment in question, but that it is some other environment which is unclear from the wording of the note.

Possibly incorrect text should be corrected, not annotated with a "clarification" that contradicts it. In this case, the text previously said "the address of the helper subroutine." This ought to be enough. Whether the environment of a function travels with it is an implementation question. An environment should be included to deal with the funarg problem, but thunks have seen limited use in languages such as C++ that do not include one. When the funarg problem is solved, the environment passed for the thunk routine is — almost by definition — the thunk routine's environment. What other routine's environment could it be? 73.71.251.64 (talk) 19:02, 24 May 2020 (UTC)

 * When you comment on what someone else wrote, please quote rather than paraphrasing. What you attributed to me is not what I wrote, which was "The environment passed is that of the call with the by-name parameter, not that of the called routine." That in no way contradicted the text that it was attached to.

 * What I had in the footnote was not an implementation question, it affects the results of the call. How the environment is passes, and whether it is the responsibility of the called routine or the calling routines, are the implementation details. If the first parameter of foo is call by reference, the third parameter is call by name, foo has a local variable called baz and you call foo(bar,baz,bar + baz), you would get the wrong results if you didn't use the stack frame of the caller to evaluate bar+baz. Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:46, 24 May 2020 (UTC)

 * Thunks were invented for a language with call by name. Why would they see extensive use for a language without call by name? Shmuel (Seymour J.) Metz Username:Chatul (talk) 19:46, 24 May 2020 (UTC)

 * I specifically said that they have seen limited use, but use nonetheless. C++ compilers use thunks. Programs written in C use thunks. Attaching an environment to a thunk parameter is a best practice because it can, as you say, affect the result. I'm well aware of that, as I brought up the funarg problem. Some languages automate this best practice. Others (including at least historical Lisp implementations) do not. 73.71.251.64 (talk) 20:22, 24 May 2020 (UTC)

 * Thunks were invented half a decade after LISP, specifically as a means of implementing call by name in ALGOL 60. That required that the thunk be what in modern nomenclature is called a closure, and that it encapsulate both a body of code and a stack frame or equivalent. That association can be handled by code in the called routine, but it still has to be there. Shmuel (Seymour J.) Metz Username:Chatul (talk) 22:35, 24 May 2020 (UTC)

 * If you accept my rewording of the note, then there is no purpose in debating the rest. I did not intentionally misrepresent you, and I can assume that you did not intentionally misread me. 73.71.251.64 (talk) 00:59, 26 May 2020 (UTC)

title: Talk:Thunk


text:
Talk:Scroll

How long were traditional scrolls?
When I'm thinking about a "scroll", in the traditional sense, what length of text should I be thinking about? Could they be made arbitrarily long, and rolled-up? When I hear that the Library of Alexandria had 400,000-700,000 scrolls, is that more like 500,000 pages, or 500,000 books? -- Creidieki 17:53, 10 October 2005 (UTC)

 * not really sure, but more like a book than a page. Torah is all on 1 (unusually large) scroll & some Chinese painted ones (exceptionally) are about ? 200 feet long. At a guess each book of the Old Testament would have been on 1 scroll in Hebrew. Also I think each "book" of the Aenead was 1 scroll.  Certainly they were rolled up, but if they got too long it would take ages to go straight to a particular place. Anyone got better info?

Johnbod 20:07, 9 December 2006 (UTC)

 * From Bernard Knox, "Introduction", in The Iliad translated by Robert Fagles (but I am re-translating from a french translation and am not english-fluent):
 * "In the ancient world the Iliad was composed of a number of scrolls of papyrus with text written in columns in the internal side. This scrolls shouldn't be too tight (else they will break on opening); for a long poem like the Iliad, maybe up to twenty-four scrolls were needed - and possibly the "songs" of present text reflect the original divison in scrolls."

Ersalo 14:24, 5 August 2007 (UTC)

Name of the article?
The name "Scroll (parchment)" in not quite right name for this article, as this deals with scrolls, and they were not predominantely parchment but papyrus. I suggest this article to be the main article and others (see Scroll) for other uses? If nobody objects it, I will make the change in two weeks. --Aethralis 09:42, 27 September 2006 (UTC)
 * While I agree that it shouldn't be located at Scroll (parchment), I don't think it should be the main article either, because there is way too many disambiguations. And one can argue that for the information age, scroll is more often heard when used to talk about mouse or webpages. I propose that it be moved to Scroll (roll) or Scroll (writing) or Scroll (medium) (my personal favorite) or some other broader description of scrolls. --Wirbelwind 06:44, 12 October 2006 (UTC)
 * Ok. I almost agree but when you look at the disambiguation page, the only other meaning of "scroll" is from music (Scroll (music)). All others come from the verb "to scroll", and so scrolling and scrollwork actually do not need this disambiguation page at all. And more to the point, scroll is the orginal meaning and the basis of all the derivative meanings.--Aethralis 08:48, 12 October 2006 (UTC)

I removed the entry from WP:RM. If you want the article moved, please reopen the case at WP:RM but I urge you to follow all the steps described there, especially creating the place for discussion on this talk page. I have no particular opinion on the subject. Duja 08:43, 18 October 2006 (UTC)
 * Scratch that, changed my mind. Having investigated "What links here" for Scroll, all the incoming links refer to the parchment. It seems you're right, and this should be the primary meaning. I'll fix the situation. Duja 08:46, 18 October 2006 (UTC)

 * Parchment is also a problem from the worldwide view angle, as the Chinese & other East Asians used paper from very early on - invented c100-200. Johnbod 03:22, 7 December 2006 (UTC)

Asia
There is next to nothing on Asian scrolls, and the Chinese (Torah scrolls apart) used the scroll the longest. I may add a bit, but I don't know much. Johnbod 03:20, 7 December 2006 (UTC)

PS the external link seems deadJohnbod 03:37, 7 December 2006 (UTC)

History
Can we move the information on how the Torah is copied away from the history section? This deserves its own page. This information has little to do with the history and description of what a scroll is.

Re: Christian Era
The discussion on the Christian era is not 100% helpful, since it implies that the scribal practises at the time were sloppy, and that the introduction of changes into the text mean that the NT is impossible to reconstruct.

There are not many scholars who would claim this.

It would be more helpful to say what the scribal practises were (eg people changing Jesus to Lord, or being more flexible with word order) and what the majority of those 30-200,000 errors were (single letter changes, word order issues etc.) and the nature of the 30 "serious" changes.

I do not dispute the factual accuracy of the figures used, nor the superiority of the scribal practises of the Masoretes, simply the skew that the current wording gives that makes is sound like we have no idea what any of the authors said. A copy of NA27 and the editor's notes puts paid to that theory.

Rev Dr J Ward —Preceding unsigned comment added by 78.144.38.97 (talk) 07:12, 19 July 2009 (UTC)

Conflicting Definitions
The image on the top right of the page is called the Joshua Roll but on the same page it says that a scroll is different from a roll. " It is distinguished from a roll by virtue of being intended for repeated use rather than continuous, but once-only use of the roll." this is already marked as dubious and I think one of these things have to go —Preceding unsigned comment added by Rockyroadster555 (talk • contribs) 14:25, 1 May 2011 (UTC)
 * The concern about the definition in the lead has been resolved, but there are other issues. Papyrologists and classicists call ancient manuscripts that are not codices "rolls" not "scrolls".  Does anyone from other disciplines have an idea how to address this?  Because this page seems to be influencing a lot of classics articles into an uncommon usage. Thank you, The Cardiff Chestnut (talk) 18:51, 20 July 2011 (UTC)

The oldest complete Torah scroll was recently discovered on May 2013 by Professor Mauro Perani. It was stored in an academic library in Bolonia, Italy. It had been mislabeled in 1889 as dating from the 17th century. Carbon testing dates the prayer book to the year 840, which is 300 to 400 years before the oldest known Torah scroll from the 12th and 13th centuries.

Recent Discovery
The oldest complete Torah scroll was recently discovered on May 2013 by Professor Mauro Perani. It was stored in an academic library in Bolonia, Italy. It had been mislabeled in 1889 as dating from the 17th century. Carbon testing dates the prayer book to the year 840, which is 300 to 400 years before the oldest known Torah scroll from the 12th and 13th centuries.

The scroll is made up of 58 sections of soft sheep leather. It is 36 meters long and 64 centimeters wide. It was written in an archaic form of Hebrew, on pages of aged parchment. The text includes 100 Jewish blessings and discusses topics such as the apocalyptic tale of the End Times and the Passover Seder. This Torah scroll is worth around 1.3 million dollars. — Preceding unsigned comment added by Gonzalev1 (talk • contribs) 18:36, 2 April 2014 (UTC)

title: Talk:Scroll


text:
Wikipedia:Articles for deletion/MichaelWong

From Speedy deletions
 * Michael Wong: Personal attack against a website owner: (Sample) He is well-known for his unforgiving attitude toward those foolish enough to eschew logic when debating him. 400 google links for "Michael Wong" www.stardestroyer.net. Delete outright or move to VfD ? -- Chris 73 | Talk 02:43, 3 May 2004 (UTC)
 * Just a comment, but...if someone said that about me ("unforgiving attitude" etc.), I would take it as a compliment. Meelar 20:22, 3 May 2004 (UTC)
 * Move to Vfd -- Chris 73 | Talk 11:13, 3 May 2004 (UTC)
 * Delete -- Cyrius|&#9998 13:06, May 3, 2004 (UTC)
 * Keep. The personal attacks can be removed. anthony (see warning)
 * Delete. Anthony is back in radical retention mode.  RickK 14:56, 3 May 2004 (UTC)
 * That personal attack can be removed too. anthony (see warning)
 * Delete - delete personal attack. If a real article is out there waiting it will someday replace this one. Tεx τ urε 14:59, 3 May 2004 (UTC)
 * Delete if not replaced by something useful. -Fennec 15:37, May 3, 2004 (UTC)
 * Delete. Borderline vandalism. Alcarillo 16:35, 3 May 2004 (UTC)
 * Delete. Reads as one pathetic vanity page. - Lucky 6.9 18:43, 3 May 2004 (UTC)
 * (Comment) It's not vanity - it was created by a critic, but the criticism has been removed.  I know who this guy is, but I don't know that I'd call him encyclopedic, isince AFAIK the only thing he's known for is his website. Isomorphic 19:34, 3 May 2004 (UTC)
 * Delete. Doesn't seem notable.--Samuel J. Howard 20:08, 3 May 2004 (UTC)
 * Delete. Cribcage 03:19, 8 May 2004 (UTC)
 * I used to eschew logic, but the doctor told me I'd get tongue cancer if I didn't quit. Delete. Denni 04:43, 2004 May 8 (UTC)