lua-users home
lua-l archive

[Date Prev][Date Next][Thread Prev][Thread Next] [Date Index] [Thread Index]


Well this thread could go on forever, so let's try this:

(1) Computer language syntax is defined by a formal grammar G that defines the (possibly infinite) set of symbol sequences S that are valid for that language. Each such sequence can be deemed a "program" in the target language defined by the grammar. For example, "a + b" might be valid while "a b +" is not.

(2) The formal semantics of a computer language (as defined above) define the behavior of any program in that language when it is executed (I won't discuss formalizing concepts such as execution). For example, the language semantics describes the behavior of the expression "a + b" when executed.

At present, many languages (Lua included) rely on natural language (e.g. English) to define many or all aspects of the computer language semantics ("a + b means that a and b are added together"). This is of course highly imprecise, however much one tries to be clear. This ambiguity can often lead to discussions about the intended behavior of a given program.

It should also be noted that most "bugs" are in fact NOT semantic in the sense that they are deviations by the language from its formal semantics; they represent the difference between the actual semantics as presented to and executed by the computer (via a program) and what the programmer had in his mind as the "intent" of the program.

This is what I meant originally: Most bugs are not "semantic" in the sense of the computer doing the wrong thing. It did the RIGHT thing, but the programmer told it to do something unintentionally ("pop, I meant a-b not a+b").

With regard to formal semantic, which was my second point. As noted above, semantics expressed in natural language is of course very imprecise. There has been much research on creating formal semantic systems (some of it very good), but almost all that work, when it comes down to it, is really a migration of semantics from the "semantic" realm into a form that is much closer to syntax; a formal symbolic system. Addition itself has been analyzed this way, and of course it took Whitehead and Russell over 200 pages to famously prove that 1+1=2. Ultimately, they concerted the concept of addition to one of symbolic logic, where it ceased being "semantic" in general terms and became much more like a (albeit complete) syntactical grammar.

--Tim




On Mar 27, 2013, at 3:16 PM, Sean Conner <sean@conman.org> wrote:

> It was thus said that the Great Javier Guerra Giraldez once stated:
>> On Wed, Mar 27, 2013 at 1:45 AM, Ross Bencina
>> <rossb-lists@audiomulch.com> wrote:
>>> 
>>>>> Attempts to go
>>>>> beyond that fail in the same way silly ideas like the "semantic
>>>>> web" nonsense of a few years back.
>>> 
>>> I'm not sure where you're going here, but I think there is a need to
>>> differentiate between the general field of semantics in human knowledge and
>>> what is meant by "semantic" in programming languages theory (ie "semantic
>>> analysis" etc) -- which just means how to the language symbols map to
>>> machine operations or to the lambda calculus. This has nothing to do with
>>> "human meaning"
>> 
>> syntax and semantics come from linguistics.  in human languages,
>> there's syntax (this is a verb, this a noun, this a noun predicate,
>> etc) and semantics ("running" and "jumping" are both physical
>> activities, "to care" is an intransitive verb, "man", "woman" and
>> "child" are all humans, etc)
> 
>  A good example is this sentence:
> 
> 	Fruit flies like a banana, but time flies like an arrow.
> 
>  Syntactically, there are four possible parsings for this sentence:
> 
> 	(1) Adj  Noun Verb Art Noun , Conj Adj  Noun Verb Art Noun
> 	(2) Adj  Noun Verb Art Noun , Conj Noun Verb Prep Art Noun
> 	(3) Noun Verb Prep Art Noun , Conj Adj  Noun Verb Art Noun
> 	(4) Noun Verb Prep Art Noun , Conj Noun Verb Prep Art Noun
> 
>  Semantically, only (2) is correct, unless you know of fruit that does,
> indeed, fly, or a group of insects known as "time flies."  
> 
>  In Lua, you can have:
> 
> 	P(5) / function(c) return tonumber(c) end
> 
>  Is syntactically correct, assuming P is defined and can be used in a
> function call context.  Semantically, it can mean different things depending
> on how P and c are defined.  Here, it means one thing:
> 
> 	function P(x) return 2 * x + 1 end
> 	c = "0.5"
> 
> but it has a different meaning this way:
> 
> 	P = require "lpeg".P
> 
>  -spc (Darn!  My time flies got out again!)
> 
> 
> 
>