On the internet I've read the general meaning of the adjective lexical: the meaning of a word in relation to the physical world or to abstract concepts, without reference to any sentence in which the word may occur.
I've seen this word been used in many different contexts: lexical scope, lexical analysis, lexical constants, lexical operators etc.
Why do people choose to use the word lexical in front of something like a scope? I don't see any relation between the definition of lexical and a lexical scope. Same goes for lexical analysis, lexical constants etc.
I understand that you want to give something a name so you can reference to it more easily, but why would you name it something that doesn't make sense? If it does make sense, then could you clarify how it does?
I've seen a different thread in which someone asks what lexical means in C++: What does the term "lexical" means in C++?
The top answer on that question explains that lexical means that it is related to the source code. Then my question would be: How is anything in programming not related to the source code? Isn't every kind of scope, constant, form of code analysis related to the source code? Also, how is the definition of lexical related to that of the relation to the source code?
The word "lexically" has several different meanings depending on context.
In the context of a compiler, "lexical" typically refers to individual tokens in a source file or the process of obtaining those tokens without any regard to the overall structure formed by those tokens. For example, in C, the input
int main() {
printf("Hi!\n");
return 0;
}
would be broken apart into
int
main
(
)
{
printf
(
"Hi!\n"
)
;
return
0
;
}
These would then be tagged with their token type, such as "identifier" or "open parenthesis."
During lexical analysis, there is (usually) no attempt to determine the overall meaning of those tokens at a broader scale. That's the job of parsing (syntax analysis) or further semantic analysis. This is similar to the definition you've given - lexical analysis is the determination of what the tokens are, but not what they mean in context.
Sometimes, "lexically" simply means "as it appears in the source code." For example, lexically scoped variables are variables that are scoped to the block in which they appear in a source file, rather than scoped based on the dynamic execution of that program. This is a bit of a misnomer.
Hope this helps!
Related
While finalizing my upcoming Raku Advent Calendar post on sigils, I decided to double-check my understanding of the type constraints that sigils create. The docs describe sigil type constraints with the table
below:
Based on this table (and my general understanding of how sigils and containers work), I strongly expected this code
my %percent-sigil is List = 1,2;
my #at-sigil is Map = :k<v>;
to throw an error.
Specifically, I expected that is List would attempt to bind the %-sigiled variable to a List, and that this would throw an X::TypeCheck::Binding error – the same error that my %h := 1,2 throws.
But it didn't error. The first line created a List that seemed perfectly ordinary in every way, other than the sigil on its variable. And the second created a seemingly normal Map. Neither of them secretly had Scalar intermediaries, at least as far as I could tell with VAR and similar introspection.
I took a very quick look at the World.nqp source code, and it seems at least plausible that discarding the % type constraint with is List is intended behavior.
So, is this behavior correct/intended? If so, why? And how does that fit in with the type constraints and other guarantees that sigils typically provide?
(I have to admit, seeing an %-sigiled variable that doesn't support Associative indexing kind of shocked me…)
I think this is a grey area, somewhere between DIHWIDT (Docter, It Hurts When I Do This) and an oversight in implementation.
Thing is, you can create your own class and use that in the is trait. Basically, that overrides the type with which the object will be created from the default Hash (for %) and Array (for # sigils). As long as you provide the interface methods, it (currently) works. For example:
class Foo {
method AT-KEY($) { 42 }
}
my %h is Foo;
say %h<a>; # 42
However, if you want to pass such an object as an argument to a sub with a % sigil in the signature, it will fail because the class did not consume the Associatve role:
sub bar(%) { 666 }
say bar(%h);
===SORRY!=== Error while compiling -e
Calling bar(A) will never work with declared signature (%)
I'm not sure why the test for Associative (for the % sigil) and Positional (for #) is not enforced at compile time with the is trait. I would assume it was an oversight, maybe something to be fixed in 6.e.
Quoting the Parameters and arguments section of the S06 specification/speculation document about the related issue of binding arguments to routine parameters:
Array and hash parameters are simply bound "as is". (Conjectural: future versions ... may do static analysis and forbid assignments to array and hash parameters that can be caught by it. This will, however, only happen with the appropriate use declaration to opt in to that language version.)
Sure enough the Rakudo compiler implemented some rudimentary static analysis (in its AOT compilation optimization pass) that normally (but see footnote 3 in this SO answer) insists on binding # routine parameters to values that do the Positional role and % ones to Associatives.
I think this was the case from the first official Raku supporting release of Rakudo, in 2016, but regardless, I'm pretty sure the "appropriate use declaration" is any language version declaration, including none. If your/our druthers are static typing for the win for # and % sigils, and I think they are, then that's presumably very appropriate!
Another source is the IRC logs. A quick search quickly got me nothing.
Hmm. Let's check the blame for the above verbiage so I can find when it was last updated and maybe spot contemporaneous IRC discussion. Oooh.
That is an extraordinary read.
"oversight" isn't the right word.
I don't have time tonight to search the IRC logs to see what led up to that commit, but I daresay it's interesting. The previous text was talking about a PL design I really liked the sound of in terms of immutability, such that code could become increasingly immutable by simply swapping out one kind of scalar container for another. Very nice! But reality is important, and Jonathan switched the verbiage to the implementation reality. The switch toward static typing certainty is welcome, but has it seriously harmed the performance and immutability options? I don't know. Time for me to go to sleep and head off for seasonal family visits. Happy holidays...
Consider the following interface:
public interface AISPI
{
public Path getPath(Entity entity, Entity target, World world) throws NoPathException;
}
Granted that entity, target, and world are all valid input. But the algorithm used to find a path (it is Astar in this case) fails to find a path, due to eg. the position of target being surrounded by concrete walls.
Is it valid to state that the postcondition is either a Path from entity to target (start to goal) or a NoPathException (given that a path was not found)?
- Or should the precondition state that there must be a valid path from start to goal?
This is not homework, but a question for improving our semester project report. I am not looking to learn about any frameworks, this is purely a question of standards and formalities in regards to design by contract. Thanks for any clarification on the matter.
It depends on the definition of the term postcondition. In general, a precondition is a relation on input state and input values at routine entry, and a postcondition is a relation on input state, input values and output state and output values at routine exit.
Because a routine can exit either normally or exceptionally, it is possible to define a postcondition for normal termination and a postcondition for abnormal termination. Clearly both involve input values, input state and output state. The key difference is in output values. In the first case this is a value specified in the routine signature, in the second - it depends on the language. In your example it might be NoPathException, but what if there is a memory allocation error, stack overflow or other exception or signal that is not specified in the signature? It may indeed seem to be possible to have a precondition that guarantees that there is always a valid result that does not involve exceptions. But this is not the case, e.g. when there is communication to external world, concurrency, etc. Also if a precondition is too costly to compute, it does not look nice to do the same work twice - on the client side to make sure a call is applicable and on the supplier's side to do essentially the same computation to get the result.
According to the Design by Contract philosophy a postcondition is what the client can safely rely on after calling a routine. Coming back to the exceptional case, from the practical point of view it makes sense to make the abnormal postcondition strong enough so that a program can continue execution, but weak enough so that the cases that are not or cannot be specified in the signature, but are possible in practice, are allowed.
So, unless the language does really guarantee all possible exceptional cases and nothing else, the most important part is output state that should not make the associated objects unusable. And this could either be expressed in an explicit or implicit postcondition or as a class invariant.
As to the specific example with getPath, the situation when a path does not exist is normal, i.e. it may happen, is expected. Some guidelines recommend to use normal values to indicate normal termination cases. Here it would be value null. Using null may lead to other issues on the caller's side, such as NullPointerException if result is not checked for null-ness, but in some languages that guarantee absence of such exceptions (e.g., void-safety in Eiffel) this would be the preferred way to indicate absence of a path (the return type would be detachable PATH in that case).
Is the quality of a language where it's not required to declare a variables type (such as PHP and Perl) known as weak typing or dynamic typing? I'm having trouble getting my head around the two terms.
Am I right that dynamic/static typing pertains to type conversion whereas weak/strong typing pertains to the deceleration of a variable?
According to: http://en.wikipedia.org/wiki/Type_system#Static_and_dynamic_type_checking_in_practice
Weak typing means that a language implicitly converts (or casts) types when used.
whereas:
A programming language is said to use static typing when type checking is performed during compile-time as opposed to run-time.
So, strong/weak and static/dynamic are two different dimensions. A language will be one of strong/weak, and also one of static dynamic. For instance, Ruby and Javascript are both dynamically typed, but Ruby is strongly typed while Javascript is weakly typed. That is, in Ruby the following code with give an error:
1.9.2p290 :001 > 'a'+1
TypeError: can't convert Fixnum into String
whereas in JavaScript, you get:
> 'a'+1
>> 'a1'
So, a strongly typed language requires you to convert two variables to the same type in order to combine them (eg. using 1.to_s), while a weakly typed language will attempt to coerce the two variables into the same type using some extra built-in language logic - in JavaScript's case, combining anything with a String will convert it into a String value.
See: http://www.artima.com/weblogs/viewpost.jsp?thread=7590 for a further explanation.
In simple terms, strong typing has more to do with how objects are bound (essentially early binding vs. late binding) than they have to do with how they are declared.
Let's say in C# I have this class:
public class Foo
{
public int Bar;
public double Baz;
}
And I declare a variable of type foo:
var myFoo = new Foo();
When I reference Foo, like this:
foo.
Visual Studio will display a list containing Bar and Baz when I type the ., because it already knows that myFoo contains those members; it is of type Foo. This is strong typing; it means that if I misspell Bar or Baz, my program won't even compile.
However, let's say I declare a variable of type dynamic This causes object binding to be deferred until the program is executed:
dynamic myFoo = new Foo();
myFoo.Grapes = 6;
This will compile. I won't get an error until the program is run; a runtime exception will be thrown because Grapes doesn't exist on Foo.
This is an old question, but for future readers this great article may clear things up: http://blogs.perl.org/users/ovid/2010/08/what-to-know-before-debating-type-systems.html
It's kind of long but it definitively worth it.
Strong and Weak Typing:
Probably the most common way type systems are classified is "strong"
or "weak." This is unfortunate, since these words have nearly no
meaning at all. It is, to a limited extent, possible to compare two
languages with very similar type systems, and designate one as having
the stronger of those two systems. Beyond that, the words mean nothing
at all.
Static and Dynamic Types
This is very nearly the only common classification of type systems
that has real meaning. As a matter of fact, it's significance is
frequently under-estimated [...] Dynamic and static type systems are
two completely different things, whose goals happen to partially
overlap.
A static type system is a mechanism by which a compiler examines
source code and assigns labels (called "types") to pieces of the
syntax, and then uses them to infer something about the program's
behavior. A dynamic type system is a mechanism by which a compiler
generates code to keep track of the sort of data (coincidentally, also
called its "type") used by the program. The use of the same word
"type" in each of these two systems is, of course, not really entirely
coincidental; yet it is best understood as having a sort of weak
historical significance. Great confusion results from trying to find a
world view in which "type" really means the same thing in both
systems. It doesn't.
Explicit/Implicit Types:
When these terms are used, they refer to the extent to which a
compiler will reason about the static types of parts of a program. All
programming languages have some form of reasoning about types. Some
have more than others. ML and Haskell have implicit types, in that no
(or very few, depending on the language and extensions in use) type
declarations are needed. Java and Ada have very explicit types, and
one is constantly declaring the types of things. All of the above have
(relatively, compared to C and C++, for example) strong static type
systems.
I see the terms "declaration," "prototype" and "symbol" thrown around interchangeably a lot when it comes to code like the following:
void MyUndefinedFunction();
The same goes for "definition" and "implementation" for things like this:
void MyClass::MyMethod()
{
// Actual code here.
}
Are there any distinctions between the terms, as with "argument" and "parameter?" Or are they truly synonymous?
Note: I'm not sure if this belongs here or on Programmers, so I posted it on both sites. If anyone has any objections, let me know and I'll delete one.
Unless you run into a purist, they are generally interchangable, except for symbol and prototype (difficult to give absolutes on language-agnostic)
symbol generally refers to a hook point for linking 2 bits of code together, such as a library entry point, or a target for resolving static linking
prototype generally refers to a definition of what a function/method looks like (arguments, return type, name, various types of visibility), but doesn't include an implementation.
You missed function vs. method, but my definition is:
function a callable bit of code that isn't bound to an object
method a callable bit of code in an object's namespace. Generally implemented by the compiler as a function that takes the object instance as it's first argument.
Possibly parameter hints at limiting scope, and therefore read-only.
Note If you ask a purist, you're more likely to have an argument than a parameter.
The difference between declaration and prototype is mainly in C, where the following is a non-prototype declaration:
int foo();
Note that this is different from:
int foo(void);
The latter is a prototype for a function taking no arguments, while the former is a declaration for a function whose argument types are not specified in the declaration. This can actually be useful to avoid function-pointer-type casts with certain uses of function pointers, but it's very easy to mess up, and messing it up invokes undefined behavior. Many C programmers consider non-prototype declarations harmful, and gcc has a warning option to flag them.
I have this question in a homework assignment for my Computer Languages class. I'm trying to figure out what each one means, but I'm getting stuck.
Errors in a computer program can be
classified according to when they are
detected and, if they are detected at
compile time, what part of the
compiler detects them. Using your
favorite programming language, give an
example of:
(a) A lexical error, detected by the
scanner.
(b) A syntax error, detected by the
parser.
(c) A static semantic error, detected
(at compile-time) by semantic
analysis.
(d) A dynamic semantic error, detected
(at run-time) by code generated by the
compiler.
For (a), I think this is would be correct: int char foo;
For (b), int foo (no semicolon)
For (c) and (d), I'm not sure what is being asked.
Thanks for the help.
I think it's important to understand what a scanner is, what a parser is and how they are involved in the compilation process.
(I'll try my best at a high-level explanation)
The scanner takes a sequence of characters (a source file) and converts it to a sequence of tokens. e.g., sees the text if 234 ) and converts to the tokens, IF INTEGER RPAREN (there's more to it but should be enough for the example).
Another way you can think of how the scanner works is that it takes the text and makes sure you use the correct keywords and not makes them up. It has to be able to convert the entire source file to the associated language's recognized tokens and this varies from language to language. In other words, "Does every piece of text correspond to a construct a language understands". Or better put with an example, "Do all these words found in a book, belong to the English language?"
The parser takes a sequence of tokens (usually from the scanner) and (among other things) sees if it is well formed. e.g., a C variable declaration is in the form Type Identifier SEMICOLON.
The parser checks "Does this sequence of tokens in this order make sense to me?" And similarly the analogy, "Does this sequence of English words (with punctuation) form complete sentences?"
C asks for errors that can be found when compiling the program. D asks for errors that you see when running the program after it compiled successfully. You should be able to distinguish these two by now hopefully.
I hope this helps you get a better understanding and make answering these easier.
I'll give it a shot. Here's what I think:
a. int foo+; (foo+ is an invalid identifier because + is not a valid char in identifiers)
b. foo int; (Syntax error is any error where the syntax is invalid - either due to misplacement of words, bad spelling, missing semicolons etc.)
c. Static semantic error are logical errors. for e.g passing float as index of an array - arr[1.5] should be a SSE.
d. I think exceptions like NullReferenceException might be an example of DME. Not completely sure but in covariant returns that raise an exception at compile time (in some languages) might also come in this category. Also, passing the wrong type of object in another object (like passing a Cat in a Person object at runtime might qualify for DME.) Simplest example would be trying to access an index that is out of bounds of the array.
Hope this helps.