pacc logo

To Do

The todo list is divided into blockers, items which are expected to be done before the next release, and laters, which are not expected to be in the next release. The next release will be pacc-0.4.

Blockers

  • (none at present)

Laters

  • complete support for void types: void start rule?
  • tidy up preamble
  • fix nested seq in guards and/or make nested seq work
  • fix check_redef() to not be O(n²)
  • investigate allocating evlis statically (we can calculate its maximum size, but this may be much larger than is typically used, so static allocation won't necessarily save space, but i suspect in practice it's a win almost all the time)
  • see if there's anything we can do about making * return a vector
  • report errors in terms of sugared syntax
  • implement s_free(). (We could use a flag in struct s_node to say if the text member came from malloc() or not.)
  • consider implementing rep-rules
  • autoconfiscation (later because I really want to make at least one more public release with my beautiful pristine makefile)
  • Debian packaging
  • parser optimization
  • XXX cleanups
  • review
  • more research
  • permission to distribute Java parser? (if I ever finish it)
  • worry a lot about memory management
  • don't run the evaluation code till pacc_result() is called
  • when -d is not specified, include fn prototypes so self-contained grammars don't need to

Ongoing

  • pore over the output of the compiler for improvements

Completed

Were in the pacc-0.3 (bugyō) release:

  • RPM packaging, see copr
  • fix miscellaneous bugs in the test suite
  • fix warnings in emitted code on 32-bit architectures

Were in the pacc-0.2 (ashigaru) release:

  • fix realloc bug in _pacc_coords()
  • quotation mark (") in character classes no longer causes indigestion
  • intermediate result cells no longer move, so ref_t values in guards work reliably
  • fix a bug in the code that creates feeding grammars
  • value inheritance, so a rule like S ← t:That { t } / ... can instead be written S ← That / ...
  • pacc_destroy() now frees all memory
  • fixed a bug where malloc size argument was not scaled (thanks glibc / valgrind!)
  • rule not reached is now a warning, not a fatal error
  • whitespace in types is no longer significant

Were in the pacc-0.1 (wōkòu) release:

  • support all C99 character escapes
  • UTF-8 support in coordinates
  • memoize _pacc_coords()
  • bring pacc0.c up to date (character classes, right anchoring)
  • UTF-8 support in character classes
  • refactor Unicode reading code in any and cclass matchers
  • make → 5 work
  • warn about bad character classes
  • pacc_error() now returns an error string, instead of outputting it
  • there is a new pacc_pos() function
  • check that all rules are reached
  • YY_input() no longer takes a name parameter (but YY_wrap() does)
  • YY_error() returns a string that doesn't include the name
  • detect rules being redefined
  • expose ability to alter prefix
  • macro and variable to enable tracing
  • move all names into the pacc_ / _pacc_ namespaces
  • feed points are now marked with $; the -r option is gone
  • pacc0.c is now built from pacc.pacc
  • detect erroneous rebinding of names
  • Put ] first in a character class to match it; disallow empty class
  • basic documentation

Were in the pacc-0.0 (ronin) release:

  • minimal documentation
  • UTF-8 support in any matchers
  • anchor all grammars left and right
  • complete command line interface
  • implement --feed / partialization (this is my unique selling point)
  • scoping -- names in pacc grammars are supposed to scope statically over sequences, but that clearly isn't the case at the moment, otherwise test/pacc/scope1.pacc would compile!
  • add #line directives
  • detect left recursion
  • one instance of each type per union
  • dynamically allocate everything

Never forget

todo is Spanish for everything

Last updated: 2016-07-30 21:37:05 UTC

News

Porting and packaging

One thing pacc needs is more users. And, perhaps, one way to get more users is to reduce the friction in getting started with pacc. An obvious lubricant is packaging. Read More...

Release relief

Looking at _pacc_coords(), I noticed that it seemed to have the same realloc() bug that I'd just fixed in _pacc_result(). However, the "list of arrays" trick really wasn't going to work here. Read More...

See more news articles

feed