<?xml version="1.0" encoding="utf-8" standalone="yes"?>
<rss version="2.0" xmlns:atom="http://www.w3.org/2005/Atom">
  <channel>
    <title>csci4105 on Jonathan Cook</title>
    <link>http://www.cs.nmsu.edu/~jcook/tags/csci4105/</link>
    <description>Recent content in csci4105 on Jonathan Cook</description>
    <generator>Hugo -- gohugo.io</generator>
    <lastBuildDate>Fri, 30 May 2008 00:00:00 +0000</lastBuildDate><atom:link href="http://www.cs.nmsu.edu/~jcook/tags/csci4105/index.xml" rel="self" type="application/rss+xml" />
    <item>
      <title>PL: Intro to Programming Languages</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-intro-to-pl/</link>
      <pubDate>Fri, 30 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-intro-to-pl/</guid>
      <description>From old CS 471 notes&amp;hellip;
An intro to a PL course
First day: The compiling, linking, and running of C programs C programs go through quite a bit from source to execution.
Preprocessing, compiling, (possibly assembling), static linking, dynamic linking during runtime
Java programs, from source to execution Compile to Java Bytecode, possibly referring to other classes&#39; bytecode.
Java .class files are self-describing, so there is no need for a header file as there is in C.</description>
    </item>
    
    <item>
      <title>PL: Brief History of Programming Languages</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-history-of-pl/</link>
      <pubDate>Wed, 28 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-history-of-pl/</guid>
      <description>From old CS 471 notes&amp;hellip;
A Brief History of Programming Languages
Resources A sparse and full graph of the ancestral chain of programming languages can be found at http://merd.sourceforge.net/pixel/language-study/diagram.html
The graphs are cached here: sparse and full [citation: the link above].
The site http://www.levenez.com/lang/ also has a history diagram and lots of links for various programming languages.
My own take on PL history Electronic computers first replaced human computers.
Manhattan project (Los Alamos, NM), had rooms of human &amp;ldquo;computers&amp;rdquo; working out the physics calculations.</description>
    </item>
    
    <item>
      <title>PL: Syntax of PLs</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-syntax-of-pl/</link>
      <pubDate>Mon, 26 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-syntax-of-pl/</guid>
      <description>From old CS 471 notes&amp;hellip;
Syntax of Programming Languages
Syntax matters No web references, you can find a lot but it&amp;rsquo;s up to you as to which you believe. Certainly some NASA space code somewhere had the problem below.
Fortran DO loop DO 20 I = 1,5
Probably true: Mecury mission&amp;rsquo;s orbit affected by a Fortran bug where the comma was mistyped as a period.
Probably false: It was long claimed that Mariner I was lost because of above typo, but this is doubtful (but potentially a mistyped hyphen did it in)</description>
    </item>
    
    <item>
      <title>PL: Parsing of PLs</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-parsing/</link>
      <pubDate>Sat, 24 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-parsing/</guid>
      <description>From old CS 471 notes&amp;hellip;
Parsing the Syntax of Programming Languages
The Problem We know that context free grammars are nice abstractions for specifying the syntax of programming languages.
But parsing of arbitrary CFG&amp;rsquo;s can be up to O(N^3) time!
So, compilers are typically built around a parsing algorithm that will only allow some subset of CFG to be defined.
Two main approaches: top-down or bottom-up parsing algorithms.
Two main sub-CFG grammar classes: LL and LR.</description>
    </item>
    
    <item>
      <title>PL: Attribute Grammars</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-attribute-grammars/</link>
      <pubDate>Thu, 22 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-attribute-grammars/</guid>
      <description>From old CS 471 notes&amp;hellip;
Attribute Grammars
Basic context-free grammars give us nice &amp;ldquo;simple&amp;rdquo; methods for specifying the first-level syntax of a programming language.
But they cannot encode context-sensitive rules, such as &amp;ldquo;an integer expression must be used for an array index&amp;rdquo;
Such rules are on the boundary between syntax and semantics. Syntax determines what a valid program is written as, and semantics determines what the program does.
The textbook calls such rules as the array index example above static semantics.</description>
    </item>
    
    <item>
      <title>PL: Semantics of PLs</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-semantics-of-pl/</link>
      <pubDate>Tue, 20 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-semantics-of-pl/</guid>
      <description>From old CS 471 notes&amp;hellip;
Semantics of Programming Languages
Already have seen static semantics, which are constraints on the behavior of the program that can be evaluated by the compiler.
Now we address the &amp;ldquo;pure&amp;rdquo; dynamic semantics of a programming language, which determine what our program will actually compute as it runs.
Semantics are important! Knowing what will happen when you use some construct in your programming language is of utmost and critical importance for actually creating a program that will do what you expect!</description>
    </item>
    
    <item>
      <title>PL: Statements and Control Structures</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-statements-control/</link>
      <pubDate>Sun, 18 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-statements-control/</guid>
      <description>From old CS 471 notes&amp;hellip;
Statements, Expressions, and Control Structures (Chs. 7 &amp;amp; 8)
Arithmetic Expressions I&amp;rsquo;m skipping all the basics (much has already come up in previous lectures):
 operator precedence operator associativity order of operand evaluation side effects automatic type conversion  Important or &amp;ldquo;odd&amp;rdquo; points are discussed below.
The Modulus Operator Most languages use &amp;ldquo;%&amp;rdquo; to indicate a modulus operation.
Modulus is consistent when both operands are positive, but can vary between languages when both or either operand is negative.</description>
    </item>
    
    <item>
      <title>PL: Subprograms, Functions, Procedures</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-subprograms/</link>
      <pubDate>Fri, 16 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-subprograms/</guid>
      <description>From old CS 471 notes&amp;hellip;
Subprograms
Fundamentals Subprogram is the generic term for a subroutine, procedure, function, method, etc.
A subprogram has a single entry point. Not necessarily a single exit point.
Control is transferred to a subprogram by a call.
The caller suspends execution until the subprogram finishes, and control is always transferred back to the caller when the subprogram finishes. (anyone know of any exceptions?)
Typical definitions of procedure and function are: a function returns a value, a procedure does not (it simply executes the body).</description>
    </item>
    
    <item>
      <title>PL: Type Checking, Binding, and Scopes</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-types-binding/</link>
      <pubDate>Wed, 14 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-types-binding/</guid>
      <description>From old CS 471 notes&amp;hellip;
Names, Type Checking, Binding, and Scopes
Names in a Program (Identifiers) Language designer must consider several design decisions:
 Case sensitivity? (usually yes these days) Allowed characters Initial allowed character Length of allowed identifiers Internal vs. external names Keywords excluded?  Popular naming syntax: first character is underscore or letter, rest are underscore, letter, or digit; all case sensitive.
What things can be named?
 Variables Procedures User defined types Classes Constants Macros Namespaces  Q: What sorts of naming standards are there for each?</description>
    </item>
    
    <item>
      <title>PL: Data Types</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-datatypes/</link>
      <pubDate>Mon, 12 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-datatypes/</guid>
      <description>From old CS 471 notes&amp;hellip;
Data Types
Data Type Basics A data type defines both the set of representable values and also the allowed operations on the values.
Information about typed variables needs to be maintained statically during compile time and possibly dynamically at runtime.
Primitive Data Types Are often closely tied with the data types that CPU&amp;rsquo;s can inherently process: signed and unsigned integers of various sizes, and floating point values.</description>
    </item>
    
    <item>
      <title>PL: Expressions and Assignments</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-expressions/</link>
      <pubDate>Sat, 10 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-expressions/</guid>
      <description>From old CS 471 notes&amp;hellip;
Expressions and Assignments
Arithmetic Expressions Operator Overloading Type Conversions Relational and Boolean Expressions Short Circuit Evaluation Assignment Statements Mixed Mode Assignment </description>
    </item>
    
    <item>
      <title>PL: Object Orientation</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-object-oriented/</link>
      <pubDate>Thu, 08 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-object-oriented/</guid>
      <description>From old CS 471 notes&amp;hellip;
Object Orientation (Chs 11 &amp;amp; 12)
Abstraction Abstraction is one of the fundamental concepts in Computer Science.
Perhaps even in all of human endeavors.
It lets us deal with more complex things than we can individually understand.
Traditional imperative (and other) programming languages have offered separate data abstraction and control (process) abstraction.
Object Oriented ideas unify the two.
Abstract Data Types Main idea #1: A data type is not just the data representation but also the operations that are allowed on the data.</description>
    </item>
    
    <item>
      <title>PL: Functional Programming</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-functional-prog/</link>
      <pubDate>Tue, 06 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-functional-prog/</guid>
      <description>From old CS 471 notes&amp;hellip;
Functional Programming Languages
Programming Paradigms Several (many?) large-scale organizing philosophies for how to specify computations have been devised: we call these programming paradigms.
Depending on who you talk to, the list can be very different.
See Wikipedia:Programming_paradigms for an &amp;ldquo;exhaustive&amp;rdquo; list.
Imperative: Computations are specified as a series of commands or actions that operate over the state of the program.
Declarative: Computations are specified as declarations of relations that must hold; lots of sub-paradigms in declarative, but we will focus on functional and logic.</description>
    </item>
    
    <item>
      <title>PL: Logic Programming</title>
      <link>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-logic-prog/</link>
      <pubDate>Sun, 04 May 2008 00:00:00 +0000</pubDate>
      
      <guid>http://www.cs.nmsu.edu/~jcook/posts/csci4105pl/pl-logic-prog/</guid>
      <description>From old CS 471 notes&amp;hellip;
Logic Programming Languages
Mathematical logic has been used in mathematics and philosophy for hundreds of years to &amp;ldquo;prove&amp;rdquo; statements of believed truth.
Usual process:
 Assert some &amp;ldquo;ground facts&amp;rdquo; as accepted truth. Hopefully everyone agrees with these; Assert some &amp;ldquo;propositions&amp;rdquo; that connect the facts. Hopefully everyone agrees with these too; Assert some desired property (&amp;ldquo;theorem&amp;rdquo;); Use rules of logical inference to prove that the theorem is true &amp;ndash; i.</description>
    </item>
    
  </channel>
</rss>
