OysterKit Versions Save

OysterKit is a framework that provides a native Swift scanning, lexical analysis, and parsing capabilities. In addition it provides a language that can be used to rapidly define the rules used by OysterKit called STLR

0.6.2

4 years ago

Fixed a minor error in the README.

0.6.1

4 years ago

Updated to build and run on Swift 5.0.

0.6.0

5 years ago

The New API Release

OysterKit

There has been a significant amount of refactoring in this release, and a lot of old code disposed of. Only the fully automatically generated (by `stlrc`) `STLR` compiler is now in use (and in the code base). I recommend if you are moving from pre 0.5 you move through 0.5.1, fix depreciation warnings, then move to this release and again fix depreciation warnings as I'll be removing the code from them as I push towards API stability which this release should largely achieve. I've updated the API documentation and added some examples of the new API to the readme. I hope you like it, it was certainly easier to write about than the old one!

0.5.1

5 years ago

Swift 4.2 and new API transition release

In this release I have added significant new capabilities to not only auto-generate the rules for parsing but also the Abstract Syntax Tree implemented as Swift types, and using the Decoding framework of standard Swift to automatically populate that based on the results of parsing with the rules.

In addition I have begun the work of refactoring the rule/token API to make significant optimisation available in the future and to dramatically simplify developing rules directly in Swift.

In this release old API is marked as deprecated, and the next release (0.6) will remove them completely to free me to start to benefit from the new architecture from now on.

This release requires at least Swift 4.2. Please use the swift/4.1 branch if you wish to continue with Swift 4.1 for now, but note only bug-fix pull requests from others will be applied from now on.

0.5.0

5 years ago

Some fairly major changes as we progress towards version 1.0. No changes required by any consumers but Swift IntermediateRepresentation autogeneration has been added. There are some issues at this stage, but for the first time you can parse STLR itself and generate the parsing rules and the IR automatically which can then be used to parse STLR.

The new flatter rule system is also included in this release and is thoroughly tested but is not yet consumed by anything. Existing rule implementers don't need to change anything (and may never need to), but internally ParserRules and ScannerRules will be replaced by this new architecture.

Furthermore creating custom (and therefore potentially highly optimised) rules in Swift is now very easy (see ClosureRule).

If any future changes are required they will be minimal.

0.4.0

5 years ago

Adds support for regular expressions as terminals. This release works with both Swift 4.1 and 4.2.

0.3.2

5 years ago

This version will build and run correctly in both Swift 4.1 and 4.2

0.3.1

6 years ago

Adds support for Swift 4.1, increases the unit test coverage to over 70%.

0.3.0

6 years ago

This is a significant release. The API and underlying implementation have been replaced significantly simplifying both.

The remainder of the releases up to v1.0 will now focus on stabilising the STLR language itself (not bugs, but ensuring there is a solid base to build on in future releases, and that any grammar breaking changes are minimised (I am not aware of any that are required at this point, but I will leave the door open)

0.2.0

6 years ago

The overly complex API for streams, homogenous, and heterogenous abstract syntax trees are replaced by a much simpler & smaller yet equally configurable set of classes.

You should refer to TokenStream and AbstractSyntaxTreeConstructor for more information.

Deprecation warnings will be issued for use of the previous classes, and support for these will be removed most likely by 0.3 when internal dependencies on the legacy types has been resolved.

In addition there are numerous fixes, although all of these are available only in the new APIs and have not been applied to the legacy ones.