14b729be13528c66d5c07e02469ab4c61bce1a97 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/d667caa432aae56867da71636a6bc83828795fd5 d667caa432aae56867da71636a6bc83828795fd5 2009-09-11T06:07:18-07:00 2009-09-11T06:04:38-07:00 Use std:: namespace prefix in header files In an earlier patch, I removed all “using namespace” statements from the HST header files, since it seemed like a bad idea to force them onto any file that includes them. I didn't have debugging messages turned on when I tested that, though, and so I didn't pick up some compiler errors in the debug statements. By removing the “using namespace” statements, I have to explicitly qualify the occurrences of “cerr” and “endl” in the headers. a27fe014149e3ce9697f459366e201e14ba67164 Douglas Creager dcreager@alum.mit.edu 43b5d5b17fb6bcfc3d983d3fee99b099c0d088cd Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/14b729be13528c66d5c07e02469ab4c61bce1a97 14b729be13528c66d5c07e02469ab4c61bce1a97 2009-04-20T19:39:57-07:00 2009-04-20T19:39:57-07:00 Eliminating CMake warnings This patch fixes the CMake build scripts to eliminate two CMake warnings. Specifically, the names of each target must be unique; before, there were several test cases in the different subdirectories that had identical names. They now have names that match the corresponding test names. The target names are used as-is as Makefile targets, so we must be sure to only use characters that are valid in a path. The second warning is that we did not state a minimum CMake version, which we now do. ce3dcfae58959f4c5921a54dc24663d70dc3565f Douglas Creager dcreager@alum.mit.edu efa9cd5893cf6fded4995ce7354c323c11e41672 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/43b5d5b17fb6bcfc3d983d3fee99b099c0d088cd 43b5d5b17fb6bcfc3d983d3fee99b099c0d088cd 2009-03-23T15:43:49-07:00 2009-03-23T15:43:49-07:00 Complex channels This patch introduces support for complex channels — those which carry data values. The “channel” statement now allows you to specify a data type for a channel: channel a: {0..2} This includes infrastructure for creating event names from these compound channels. Lighthouse: [#22 state:resolved] e1c6940d649f38a150193459113d441a4c7afb11 Douglas Creager dcreager@alum.mit.edu 89f4f7bd2000767025f65ac4aa62769d871a7e8f Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/efa9cd5893cf6fded4995ce7354c323c11e41672 efa9cd5893cf6fded4995ce7354c323c11e41672 2009-03-03T21:01:31-08:00 2009-03-03T21:01:31-08:00 Complex datatypes This patch introduces support for “complex” datatype statements — i.e., those with data values. This includes test cases for most of the examples in section A.3.3 of the FDR manual. Lighthouse: [#21 state:resolved] 2c54cd58f1c3ad34cc1c6c65255d28a1a1036f2d Douglas Creager dcreager@alum.mit.edu 0dcc09f518d1117c73122ed5b0466a3d4fc159bb Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/89f4f7bd2000767025f65ac4aa62769d871a7e8f 89f4f7bd2000767025f65ac4aa62769d871a7e8f 2009-03-03T20:43:12-08:00 2009-03-03T20:00:17-08:00 Simple datatypes This patch introduces support for “simple” datatype statements — i.e., those whose constructors do not take any data values. So, in the following: datatype SimpleColour = Red | Green | Blue datatype T = A.{0..3} | B.{4..7} SimpleColour is a simple datatype, whereas T is not. The SimpleColour definition creates four bindings: Red, Green, and Blue all resolve to a new “constructor value”, which just records which of the data constructors was used to create a particular value. SimpleColour resolves to a set containing all three constructor values. Lighthouse: [#21] 3c5cc0c0a82e2ef068ae9bce128b645a839dadd4 Douglas Creager dcreager@alum.mit.edu 624f65caa7bc15a6281e6df7ece2d90bca9ed279 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/0dcc09f518d1117c73122ed5b0466a3d4fc159bb 0dcc09f518d1117c73122ed5b0466a3d4fc159bb 2009-03-02T16:33:10-08:00 2009-03-02T16:33:10-08:00 Dotted values in patterns Dotted values can occur in a pattern, such as in the parameters to a named function: f(a.b) = a + b Based on some experimentation, it turns out that the left-hand side of a dotted pattern must match the first element of a dotted value. The right-hand side must match the “rest” of the dotted value. If the dotted value only contains two elements, then that means it must match the second element. If it contains more than two elements, then that means it must match a slightly smaller dotted value: a.b matches 1.2 (a == 1, b == 2) a.b matches 1.2.3 (a == 1, b == 2.3) a.b.c matches 1.2.3 (a == 1, b == 2, c = 3) 1.b matches 1.2.3 (b == 2.3) a.3 DOES NOT MATCH 1.2.3 (a == 1, but 3 doesn't match 2.3) Lighthouse: [#15 state:resolved] 0a8dd2d8c387e7c7c358abfefee22bdfaaa352f0 Douglas Creager dcreager@alum.mit.edu a086a735566dd10bebe7f0d85ccb209242c06317 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/624f65caa7bc15a6281e6df7ece2d90bca9ed279 624f65caa7bc15a6281e6df7ece2d90bca9ed279 2009-03-02T15:45:45-08:00 2009-03-02T15:45:45-08:00 Dotted values in “nametype” statements Dotted values in a type expression create product types, just like tuple values: nametype A = {0,1}.{2,3} A == {0.2, 0.3, 1.2, 1.3} Lighthouse: [#15] 500384337e90679e0bcbefcc1a4112905d9b1553 Douglas Creager dcreager@alum.mit.edu cfbf8e98479f1270f396db888adb9a01c8bc60dc Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/a086a735566dd10bebe7f0d85ccb209242c06317 a086a735566dd10bebe7f0d85ccb209242c06317 2009-03-02T15:19:10-08:00 2009-03-02T15:18:53-08:00 Dotted values This patch introduces basic support for dotted values. A dotted value is similar to a tuple: 1.2 (1,2) However, dots support _concatenation_: x = 1.2 y = 3.4 x.y == 1.2.3.4 The CSPM parser now allows you to construct dotted values using the “.” operator. We still need to add support for dotted values in patterns and type expressions. Lighthouse: [#15] ec0483d8f476da9182896be189dc10b8cd48a557 Douglas Creager dcreager@alum.mit.edu f9591022a48f40452d33739778ac658f1330e1ee Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/cfbf8e98479f1270f396db888adb9a01c8bc60dc cfbf8e98479f1270f396db888adb9a01c8bc60dc 2009-03-02T13:14:27-08:00 2009-03-02T13:14:27-08:00 Fixed column numbers when using Bison 2.3 Bison 2.3 numbers the columns in an input file from 0, whereas 2.4 numbers them from 1. We want to consistently use 1-based column numbers. This was causing a problem with test cases that would generate (expected) parse errors — if the correct test result was generated using Bison 2.4, then that test would fail when using 2.3, and vice versa. I could not find an easy way to override the “column” field's default value, so instead, we add code in our Bison grammars to manually reset the column to 1 at the start of each file, and every time a new line is encountered. Lighthouse: [#20 state:resolved] 46043855552dec3a5596d0409bfed4b8a6e9dd61 Douglas Creager dcreager@alum.mit.edu 8da06dd715d084d42f086b1df9e6730417a30d17 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/f9591022a48f40452d33739778ac658f1330e1ee f9591022a48f40452d33739778ac658f1330e1ee 2009-02-28T09:46:52-08:00 2009-02-28T09:46:52-08:00 Multiple channels This patch allows you to define multiple channels in a single channel statement: channel a, b Of course, right now we only support simple channels; you can't define a datatype that the channel carries. Lighthouse: [#19 state:resolved] 9ff3c81d3810e25ff1c6cf906b76dc8f5c1d6155 Douglas Creager dcreager@alum.mit.edu 1d240247d57548c7162181ab816f4dceb9f5253b Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/8da06dd715d084d42f086b1df9e6730417a30d17 8da06dd715d084d42f086b1df9e6730417a30d17 2009-02-28T09:32:00-08:00 2009-02-28T09:32:00-08:00 Product types In a type expression, a tuple creates a product type. In other words, with a type expression, you get nametype A = ({0,1}, {2,3}) A == {(0,2), (0,3), (1,2), (1,3)} whereas in a regular expression, you get A == ({0,1}, {2,3}) Currently type expressions only occur in nametype statements. Lighthouse: [#17] fcb459d23a2ab05847abf2c28acd0c32b3abfb60 Douglas Creager dcreager@alum.mit.edu 44b7758612fa95b1b7cd5f9900977473eb7a6cc4 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/1d240247d57548c7162181ab816f4dceb9f5253b 1d240247d57548c7162181ab816f4dceb9f5253b 2009-02-13T19:13:54-08:00 2009-02-13T19:13:54-08:00 “nametype” statements The CSPM parser now supports “nametype” statements at the top level of a CSPM script. A nametype statement is a simple binding of a variable to a type expression. There is not yet support for the tuple operator in type expressions; a later patch will introduce its product type semantics. Lighthouse: [#17] 9c9fee66aa0e5b76e0dfd93b07b1d145a09da885 Douglas Creager dcreager@alum.mit.edu 81b1e221f6c39660782d9d2d785e477829371297 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/44b7758612fa95b1b7cd5f9900977473eb7a6cc4 44b7758612fa95b1b7cd5f9900977473eb7a6cc4 2009-02-13T19:13:19-08:00 2009-02-13T19:13:19-08:00 Int and Bool built-in types This patch introduces initial support for named types in CSPM. Types treated the same as sets; the only difference is in that certain contexts, the tuple constructor and dot operator have different semantics, which make it easier to define the kinds of sets that types usually consist of. The first two named types are the built-in Int and Bool types. They are defined as keywords, and have built-in evaluation rules that result in the appropriate {True, False} and {..., -1, 0, 1, ...} sets. Lighthouse: [#17] 0374f6bc54618a61f11106382fdcf5c1fe3503c0 Douglas Creager dcreager@alum.mit.edu 5f662d02701695ac8a293670463347eceefaa886 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/81b1e221f6c39660782d9d2d785e477829371297 81b1e221f6c39660782d9d2d785e477829371297 2009-02-10T16:31:54-08:00 2009-02-10T16:31:54-08:00 Replicated internal choice This patch introduces the “replicated internal choice” operator. This has the same semantics as the standard internal choice, but it works on a set containing any number of processes. (The standard internal choice operator takes exactly two operands.) The replicated version is well-defined since the binary version is associative. Unlike replicated external choice, the replicated internal choice of the empty set is not well-defined. Thus, the following is treated as a syntax error in CSP₀: rintchoice P = |~| {}; Lighthouse: [#8] 3720e703d6614b6af2bd2577c58cc9a2da8840eb Douglas Creager dcreager@alum.mit.edu 3cdeaa17b28a30df5243e196b8ae0d7a3c4e4aab Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/5f662d02701695ac8a293670463347eceefaa886 5f662d02701695ac8a293670463347eceefaa886 2009-02-10T16:23:14-08:00 2009-02-10T16:09:35-08:00 Include error messages in expected CSP₀ test outputs We now include error messages in the output of all of the tests under tests/csp0. This doesn't affect the output of any existing tests, but will allow us to include test cases for invalid CSP₀ scripts. 1851a2be72e1decb535c7f274fb66cc44ebb621a Douglas Creager dcreager@alum.mit.edu a73d42deb6d0f2112324af333dacd42faa33e11a Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/3cdeaa17b28a30df5243e196b8ae0d7a3c4e4aab 3cdeaa17b28a30df5243e196b8ae0d7a3c4e4aab 2009-02-10T15:34:00-08:00 2009-02-10T10:52:38-08:00 Using Markdown for documentation This patch modifies all of the documentation to use Markdown syntax instead of asciidoc. This also requires adding a build dependency on pandoc (instead of asciidoc and xmlto). In theory, this should allow Github to automatically render the source .md files into HTML output. 6cf185830df138a1fbfac788220a34b2db5eae01 Douglas Creager dcreager@alum.mit.edu 3a314e60cf2d537f35e84525795c09725d667ede Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/a73d42deb6d0f2112324af333dacd42faa33e11a a73d42deb6d0f2112324af333dacd42faa33e11a 2009-02-09T19:39:05-08:00 2009-02-09T19:39:05-08:00 Remove tabs from source files 58546b34580e031dba581b90dcfb8f7eea070cf5 Douglas Creager dcreager@alum.mit.edu fd0feadbfe694d7c0359eb9cf3a159c260b0545b Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/3a314e60cf2d537f35e84525795c09725d667ede 3a314e60cf2d537f35e84525795c09725d667ede 2009-02-06T21:22:46-08:00 2009-02-06T21:08:45-08:00 Removing “doc” target from “make all” This patch changes the build rules so that the documentation is not automatically generated for you. (This allows you to compile the source without having the asciidoc tool installed, for instance.) f2f5c5650ace2ef1616ee87af217644dde7e7b43 Douglas Creager dcreager@alum.mit.edu 80bcfc675379f024f3f4c37770bb755c07e2ce8e Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/fd0feadbfe694d7c0359eb9cf3a159c260b0545b fd0feadbfe694d7c0359eb9cf3a159c260b0545b 2009-02-06T21:22:20-08:00 2009-02-06T21:04:26-08:00 Use shared_ptr from Boost instead of from the TR1 standard When we first used shared_ptr in the HST code, we weren't using Boost yet. shared_ptr is in TR1, which seems to be implemented by most modern C++ compilers, so it made sense to use that implementation, rather than introduce a dependency on Boost. Now, though, we're using Boost for other things, so it makes sense to just use the shared_ptr implementation from it. This also fixes a bug reported by Moritz Kleine, where we'd get an error when trying to compile src/assertions/refine.cc, since the compiler could somehow see both implementations of shared_ptr, and would get confused which one to use. As part of this patch, I've also removed all “using namespace” statements from the header files, since I've discovered that this is rude behavior in the C++ world. (We don't want to require the users of the header files to use the namespace, too, after all...) 34fabc4171e557e8369b1868feb386fce14cd1e7 Douglas Creager dcreager@alum.mit.edu fd9cdd7357a88d95e8b3400bf730bd3ed2675653 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/80bcfc675379f024f3f4c37770bb755c07e2ce8e 80bcfc675379f024f3f4c37770bb755c07e2ce8e 2009-01-12T21:03:05-08:00 2009-01-12T21:03:05-08:00 Block comments The CSPM compiler now supports block comments: {- This is a comment. {- Block comments should nest. -} -- Technically line comments are good inside block comments, too, -- but this has no real meaning since "--" has no special meaning -- in a block comment. -} Lighthouse: [#16 status:resolved] 764d9ef5ad7193c58fe276481213ce7a756dccda Douglas Creager dcreager@alum.mit.edu f07c54e44204674721d73d15dcea6e33b6896f8b Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/fd9cdd7357a88d95e8b3400bf730bd3ed2675653 fd9cdd7357a88d95e8b3400bf730bd3ed2675653 2009-01-12T20:59:08-08:00 2009-01-12T20:49:02-08:00 Single-line comments The CSPM compiler now supports single comments: -- This is a comment a = 5 -- this is a number b = 6 -- so is this c = a + -- add them together b As shown in this example (which is in the test suite), a single-line comment counts as a newline. (If it didn't, the “a” and “b” variables wouldn't be properly defined, since a definition must end with a newline.) Lighthouse: [#16] 8633873d8ff327ee6934306349d3aad96acedbb7 Douglas Creager dcreager@alum.mit.edu 5508ed2701e92efd96e633ed7443a920d4d8ab3c Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/f07c54e44204674721d73d15dcea6e33b6896f8b f07c54e44204674721d73d15dcea6e33b6896f8b 2009-01-12T20:45:13-08:00 2009-01-12T20:45:13-08:00 Updating CSPM libraries to work with GHC 6.10 and Cabal 1.6 The HST libraries do not use any of the new features or libraries provided by GHC 6.10. This patch ensures that we use the 6.8-era base-3 libraries. We also require the latest Cabal, which requires a slight tweak to the Setup.lhs script to use the new name of the default UserHooks instance. d32ef46578e7d91f8d8cd7e55fa213284abb2e30 Douglas Creager dcreager@alum.mit.edu e86a1dc8440d75a6075607e0f053f42fac9bf0a2 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/5508ed2701e92efd96e633ed7443a920d4d8ab3c 5508ed2701e92efd96e633ed7443a920d4d8ab3c 2008-11-27T20:03:22-08:00 2008-11-27T20:03:22-08:00 Mac OS X packaging script creates disk image The packaging script now creates a disk image to hold the installation package. That gives us a single, non-resource-forked file that people will be able to download. 13a04df3209451349f0dd996717fce88997bcddb Douglas Creager dcreager@alum.mit.edu c09f657965b26f7050f82e9e3e2780c48139272e Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/e86a1dc8440d75a6075607e0f053f42fac9bf0a2 e86a1dc8440d75a6075607e0f053f42fac9bf0a2 2008-11-27T19:24:52-08:00 2008-11-27T19:24:52-08:00 Including “cspm” in Mac OS X installation package We now include the “cspm” Haskell program in the Mac OS X installation package. We still don't include the Haskell library itself in the package, though. Mostly this is because any library we include in the package will (I believe) be tied to a specific compiler and version. I'm thinking that anyone who needs the library can just grab it from Hackage. The “cspm” tool is statically linked, so we don't need the library installed for it to work. We shall see. 3d9adcbcd5afdc83858935ad943989f3daca2d9f Douglas Creager dcreager@alum.mit.edu 48599d503f16233ef3b8ce0655f19ba2241fbbbe Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/c09f657965b26f7050f82e9e3e2780c48139272e c09f657965b26f7050f82e9e3e2780c48139272e 2008-11-27T15:44:02-08:00 2008-11-27T15:44:02-08:00 Adding scripts for creating Mac OS X installation package This patch introduces a script and some ancillary files for creating a Mac OS X installation package. We create an framework to hold the CSP₀ library and command-line tool. The installation package installs this framework into /Libraries/Frameworks, and creates a symbolic link in /usr/bin to point at the csp0 executable. The package doesn't include the Haskell CSPM code yet; I still need to figure out the best way to package it and its GHC dependency. d137b98c39496c050410137401cf2611951deb3d Douglas Creager dcreager@alum.mit.edu dedd0a41c52d715a92ce2d61f940e6a9e199f20a Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/48599d503f16233ef3b8ce0655f19ba2241fbbbe 48599d503f16233ef3b8ce0655f19ba2241fbbbe 2008-11-20T18:44:21-08:00 2008-11-20T18:44:21-08:00 “create-source-package” script now works with any version The “create-source-package” script now takes the HST version as a parameter, so it can be used to reproduce the tar archive for any prior release. It has also been updated to work with the latest Git version, which no longer stores the (majority of the) git-* binaries in /usr/bin. 4ae7e26855c839b3cad4c13b93f42c9f539ba439 Douglas Creager dcreager@alum.mit.edu 712ada84eb96967ccda4008b9f7a089f158e4edc Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/dedd0a41c52d715a92ce2d61f940e6a9e199f20a dedd0a41c52d715a92ce2d61f940e6a9e199f20a 2008-11-20T18:27:34-08:00 2008-11-20T18:27:34-08:00 Updating README and INSTALL to mention CSPM library This patch adds some information about the Haskell CSPM library to the README and INSTALL files. 37e2220be3fd96bc36d1427144da93737a0abd31 Douglas Creager dcreager@alum.mit.edu dc52e1d16eebfbca200add57115bf33d95f9962d Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/712ada84eb96967ccda4008b9f7a089f158e4edc 712ada84eb96967ccda4008b9f7a089f158e4edc 2008-11-20T17:51:47-08:00 2008-11-20T17:51:15-08:00 “let”s now allow pattern definitions and multiple-branch functions This patch extends the parser and AST evaluator to allow the same kinds of definitions in a “let” statement as can appear at the top level of a script. Specifically, the left-hand side of a let binding can now be an arbitrary pattern, or a function defined using multiple branches. 8cfea5323d285c3b93ab970eecd95453025578bf Douglas Creager dcreager@alum.mit.edu 3f306f37f3a138f587eca1ef93dbee325c929a76 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/dc52e1d16eebfbca200add57115bf33d95f9962d dc52e1d16eebfbca200add57115bf33d95f9962d 2008-11-19T20:32:34-08:00 2008-11-19T20:32:34-08:00 Functions defined in multiple branches The CSPM parser now supports defining functions using multiple branches, such as: length(<>) = 0 length(<_>^xs) = 1 + length(xs) reverse(<>) = <> reverse(<x>^xs) = reverse(xs) ^ <x> (These two examples are included as test cases.) Since lambdas were already implemented using multiple pattern-based clauses, this patch only required syntax manipulations to create the right AST. No new evaluation logic was needed. 4a16fff0a961a8502b9f935eda7151bbda03e5fb Douglas Creager dcreager@alum.mit.edu 72a21eb5cb201615ffc64a7d5ef7dadf511544e0 Douglas Creager dcreager@alum.mit.edu http://github.com/dcreager/hst/commit/3f306f37f3a138f587eca1ef93dbee325c929a76 3f306f37f3a138f587eca1ef93dbee325c929a76 2008-11-19T20:10:01-08:00 2008-11-19T20:10:01-08:00 Lambda expressions now implemented using patterns, too The previous “lambdas using patterns” patch only applied to lambda *values*. This patch changes lambda expressions and bound expressions to be implemented using patterns, too. 8fcf39340410eb57d6a195bdd2930436d71920fb Douglas Creager dcreager@alum.mit.edu