Abuse filter log

Abuse Filter navigation (Home | Recent filter changes | Examine past edits | Abuse log)
Jump to navigation Jump to search
Details for log entry 7,065

16:03, 31 March 2018: Hq9++fan (talk | contribs) triggered filter 12, performing the action "edit" on . Actions taken: Disallow; Filter description: pattern vandalism/revert-warring: Unicode subscripts/superscripts (examine)

Changes made in edit

'''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ<sub>(''L'',''P'')</sub> is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ<sub>(''L'',''P'')</sub> is a highly-restricted subset of ''L'' in which ''P'' is the only valid program.
+
'''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ₍''ʟ'', '''' is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ₍''ʟ'', '''' is a highly-restricted subset of ''L'' in which ''P'' is the only valid program.
   
 
A less mathematical and more programmer-oriented way of describing ℒ is to think of it as the set that contains:
 
A less mathematical and more programmer-oriented way of describing ℒ is to think of it as the set that contains:
   
 
==Computational class of ℒ==
 
==Computational class of ℒ==
The question, then, is whether any given ℒ<sub>(''L'',''P'')</sub> (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete.
+
The question, then, is whether any given ℒ₍''ʟ'', '''' (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete.
   
 
This is ultimately a philosophical (or at least terminological) question about the status of input when describing Turing-completeness. The language which ''P'' takes as input is Turing-complete, and as such, there exists a program in ℒ which is capable of, by some reasonable definition, implementing a universal Turing machine.
 
This is ultimately a philosophical (or at least terminological) question about the status of input when describing Turing-completeness. The language which ''P'' takes as input is Turing-complete, and as such, there exists a program in ℒ which is capable of, by some reasonable definition, implementing a universal Turing machine.

Action parameters

VariableValue
Whether or not the edit is marked as minor (no longer in use) (minor_edit)
false
Edit count of the user (user_editcount)
107
Name of the user account (user_name)
'Hq9++fan'
Age of the user account (user_age)
38875679
Page ID (page_id)
3788
Page namespace (page_namespace)
0
Page title (without namespace) (page_title)
'ℒ'
Full page title (page_prefixedtitle)
'ℒ'
Action (action)
'edit'
Edit summary/reason (summary)
'Undo revision 54628 by [[Special:Contributions/B jonas|B jonas]] ([[User talk:B jonas|talk]])'
Old content model (old_content_model)
'wikitext'
New content model (new_content_model)
'wikitext'
Old page wikitext, before the edit (old_wikitext)
''''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ<sub>(''L'',''P'')</sub> is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ<sub>(''L'',''P'')</sub> is a highly-restricted subset of ''L'' in which ''P'' is the only valid program. A less mathematical and more programmer-oriented way of describing ℒ is to think of it as the set that contains: * A dialect of Pascal that is ''so'' restricted that you can only write ''one'' program, <code>utm.pas</code>, in it; * A dialect of Pascal that is ''so'' restricted that you can only write ''one'' program, <code>[[Underload|underload]].pas</code>, in it; * A dialect of Scheme that is ''so'' restricted that you can only write ''one'' program, <code>[[BCT]].scm</code>, in it; * A dialect of [[brainfuck]] that is ''so'' restricted that you can only write ''one'' program, <code>utm.b</code>, in it; * and so forth. ℒ is frequently written as "fancy L", in situations where 'ℒ' is difficult to type. ==Computational class of ℒ== The question, then, is whether any given ℒ<sub>(''L'',''P'')</sub> (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete. This is ultimately a philosophical (or at least terminological) question about the status of input when describing Turing-completeness. The language which ''P'' takes as input is Turing-complete, and as such, there exists a program in ℒ which is capable of, by some reasonable definition, implementing a universal Turing machine. However, there is not a mapping from arbitrary Turing machines to ℒ programs, as there exists only one ℒ program. There is only a mapping of arbitrary Turing machines to ''inputs'' for ℒ programs (or, equivalently, (program, input) pairs). The two most common conclusions of this quandry are: * We consider (program, input) to be coupled for describing Turing-completeness, and as such, ℒ is clearly Turing-complete. * We consider input to be separate from the language, and as such, a new term is needed to describe ℒ's computational class. ===Aside=== Chris Pressey explains this in terms of making a distinction between ''functions'' and ''computations''. A Turing machine, or any language without input, may be universal in the sense of being able to be programmed to perform any computation any other machine can, but it cannot be programmed to compute any function at all -- because functions map a given (i.e. not known ''a priori'') value to another value. The term "Turing-complete" seems to have its roots in recursive function theory, where functions are an important concept for distinguishing computability problems; for instance, the Uniform Halting Problem is strictly "harder" than the Halting Problem, but defining the Uniform version of the problem requires a definition of "input". (It's "harder" because the input is universally quantified; in essence, a function represents an infinite number of possible computations.) At the same time, it seems rather ungenerous to say that only functions, and not computations, can be Turing-complete, as that would mean that we (rather ironically) cannot call a universal Turing machine Turing-complete. The languages in ℒ are intended to be on the "opposite" side of this spectrum from Turing machines. Graphically, Turing machines: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC `------------- any computation you like --------------' Conventional Turing-complete programming languages with I/O: IIIIIIIIIIIIIIIIIIIIIIIIIIFFFFFFFFFFFFFFFFFFFFFFFFFFFFF `-- any input you like --'`-- any function you like --' (combine these and you get any computation you like) ℒ: IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIF `---------------- any input you like ----------------'^-- one function only: the universal function (combine these and you get any computation you like) One difference between a conventional TC language with I/O and a language in ℒ is that in the conventional language, you are allowed to write any function you like -- including one that ignores its input, and acts as an inputless computation. It is not possible to write such a program in a language in ℒ. ==ℒ-equivalence== Given that the computational class of ℒ is unclear, but there are languages which are plainly within its computational class, we can create a new (and intentionally ambiguous) computational class to describe it. ℒ-equivalent machines are those abstract machines for which the ability to describe all universal Turing machines is predicated upon the status of input or some other state which may be considered external to the machine proper. The set of ℒ-equivalent machines is clearly a subset of [[Turing machines]], but whether it is a proper subset is a matter of philosophy. A language is said to be ℒ-hard if there exists a program in that language which is in ℒ, and ℒ-complete if it is ℒ-hard and not otherwise [[Turing-complete]]. Examples of languages which are ℒ-complete include [[ALPACA]], [[Befunge/index.php]] and [[HQ9+B]], as well as the language subsets implied by many [[Golf]] competitions. [[Category:Concepts]] [[Category:2010]]'
New page wikitext, after the edit (new_wikitext)
''''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ₍''ʟ'', ''ᴘ''₎ is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ₍''ʟ'', ''ᴘ''₎ is a highly-restricted subset of ''L'' in which ''P'' is the only valid program. A less mathematical and more programmer-oriented way of describing ℒ is to think of it as the set that contains: * A dialect of Pascal that is ''so'' restricted that you can only write ''one'' program, <code>utm.pas</code>, in it; * A dialect of Pascal that is ''so'' restricted that you can only write ''one'' program, <code>[[Underload|underload]].pas</code>, in it; * A dialect of Scheme that is ''so'' restricted that you can only write ''one'' program, <code>[[BCT]].scm</code>, in it; * A dialect of [[brainfuck]] that is ''so'' restricted that you can only write ''one'' program, <code>utm.b</code>, in it; * and so forth. ℒ is frequently written as "fancy L", in situations where 'ℒ' is difficult to type. ==Computational class of ℒ== The question, then, is whether any given ℒ₍''ʟ'', ''ᴘ''₎ (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete. This is ultimately a philosophical (or at least terminological) question about the status of input when describing Turing-completeness. The language which ''P'' takes as input is Turing-complete, and as such, there exists a program in ℒ which is capable of, by some reasonable definition, implementing a universal Turing machine. However, there is not a mapping from arbitrary Turing machines to ℒ programs, as there exists only one ℒ program. There is only a mapping of arbitrary Turing machines to ''inputs'' for ℒ programs (or, equivalently, (program, input) pairs). The two most common conclusions of this quandry are: * We consider (program, input) to be coupled for describing Turing-completeness, and as such, ℒ is clearly Turing-complete. * We consider input to be separate from the language, and as such, a new term is needed to describe ℒ's computational class. ===Aside=== Chris Pressey explains this in terms of making a distinction between ''functions'' and ''computations''. A Turing machine, or any language without input, may be universal in the sense of being able to be programmed to perform any computation any other machine can, but it cannot be programmed to compute any function at all -- because functions map a given (i.e. not known ''a priori'') value to another value. The term "Turing-complete" seems to have its roots in recursive function theory, where functions are an important concept for distinguishing computability problems; for instance, the Uniform Halting Problem is strictly "harder" than the Halting Problem, but defining the Uniform version of the problem requires a definition of "input". (It's "harder" because the input is universally quantified; in essence, a function represents an infinite number of possible computations.) At the same time, it seems rather ungenerous to say that only functions, and not computations, can be Turing-complete, as that would mean that we (rather ironically) cannot call a universal Turing machine Turing-complete. The languages in ℒ are intended to be on the "opposite" side of this spectrum from Turing machines. Graphically, Turing machines: CCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCCC `------------- any computation you like --------------' Conventional Turing-complete programming languages with I/O: IIIIIIIIIIIIIIIIIIIIIIIIIIFFFFFFFFFFFFFFFFFFFFFFFFFFFFF `-- any input you like --'`-- any function you like --' (combine these and you get any computation you like) ℒ: IIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIIF `---------------- any input you like ----------------'^-- one function only: the universal function (combine these and you get any computation you like) One difference between a conventional TC language with I/O and a language in ℒ is that in the conventional language, you are allowed to write any function you like -- including one that ignores its input, and acts as an inputless computation. It is not possible to write such a program in a language in ℒ. ==ℒ-equivalence== Given that the computational class of ℒ is unclear, but there are languages which are plainly within its computational class, we can create a new (and intentionally ambiguous) computational class to describe it. ℒ-equivalent machines are those abstract machines for which the ability to describe all universal Turing machines is predicated upon the status of input or some other state which may be considered external to the machine proper. The set of ℒ-equivalent machines is clearly a subset of [[Turing machines]], but whether it is a proper subset is a matter of philosophy. A language is said to be ℒ-hard if there exists a program in that language which is in ℒ, and ℒ-complete if it is ℒ-hard and not otherwise [[Turing-complete]]. Examples of languages which are ℒ-complete include [[ALPACA]], [[Befunge/index.php]] and [[HQ9+B]], as well as the language subsets implied by many [[Golf]] competitions. [[Category:Concepts]] [[Category:2010]]'
Unified diff of changes made by edit (edit_diff)
'@@ -1,3 +1,3 @@ -'''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ<sub>(''L'',''P'')</sub> is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ<sub>(''L'',''P'')</sub> is a highly-restricted subset of ''L'' in which ''P'' is the only valid program. +'''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ₍''ʟ'', ''ᴘ''₎ is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ₍''ʟ'', ''ᴘ''₎ is a highly-restricted subset of ''L'' in which ''P'' is the only valid program. A less mathematical and more programmer-oriented way of describing ℒ is to think of it as the set that contains: @@ -11,5 +11,5 @@ ==Computational class of ℒ== -The question, then, is whether any given ℒ<sub>(''L'',''P'')</sub> (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete. +The question, then, is whether any given ℒ₍''ʟ'', ''ᴘ''₎ (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete. This is ultimately a philosophical (or at least terminological) question about the status of input when describing Turing-completeness. The language which ''P'' takes as input is Turing-complete, and as such, there exists a program in ℒ which is capable of, by some reasonable definition, implementing a universal Turing machine. '
New page size (new_size)
5582
Old page size (old_size)
5591
Lines added in edit (added_lines)
[ 0 => ''''ℒ''' is a family of languages proposed by [[Chris Pressey]] in 2010 to explore questions of Turing-completeness, particularly in terms of which parts of a system constitute code, state and input. For every pair of a Turing-complete language ''L'' and a program ''P'' written in ''L'' that simulates a [[universal Turing machine]] (for example, by being an interpreter for a [[Turing-complete]] language), ℒ₍''ʟ'', ''ᴘ''₎ is a member of ℒ in which ''P'' is the only valid program, having the semantics described by ''L''. That is, ℒ₍''ʟ'', ''ᴘ''₎ is a highly-restricted subset of ''L'' in which ''P'' is the only valid program.', 1 => 'The question, then, is whether any given ℒ₍''ʟ'', ''ᴘ''₎ (henceforth ℒ, as the particular ''L'' and ''P'' are not relevant) is itself Turing-complete.' ]
Unix timestamp of change (timestamp)
1522512189