Copperbox revision 3172.
I've implemented a simplistic form of inheritance - super-class methods get inherited, but a local redefinition in the class overrides the super-class method completely . There is no super at the moment to invoke the method in the parent class.
Monday, June 30, 2014
ochre-lang
Copperbox revision 3171.
I've added super-class inheritance to the top-level syntax and the parser. Implementing inheritance is todo...
I've added super-class inheritance to the top-level syntax and the parser. Implementing inheritance is todo...
ochre-lang
Copperbox revision 3170.
I've implemented a preliminary version of tuple elimination. Currently nested tuples will break the compiler, but otherwise I'm pleased with the implementation. Temporary variables introduced to deconstruct a tuple are removed later by the ElimLet optimization.
I've implemented a preliminary version of tuple elimination. Currently nested tuples will break the compiler, but otherwise I'm pleased with the implementation. Temporary variables introduced to deconstruct a tuple are removed later by the ElimLet optimization.
Sunday, June 29, 2014
ochre-lang
Copperbox revision 3169.
I've added LetTuple to the Expr type in the intermediate syntax.
If I have a LetTuple form in the syntax, I should be able to eliminate Tuples with an Expr -> Expr compiler pass. Before doing the actual work, this seems easier than trying to eliminate tuples as part of the translation from top-level syntax.
I've added LetTuple to the Expr type in the intermediate syntax.
If I have a LetTuple form in the syntax, I should be able to eliminate Tuples with an Expr -> Expr compiler pass. Before doing the actual work, this seems easier than trying to eliminate tuples as part of the translation from top-level syntax.
ochre-lang
Copperbox revision 3168.
Work on generalizing the "run compiler" code so I can just run particular steps and dump their output for checking.
Note - the pretty printer for the intermediate representation needs changing as it uses a syntax from the original Ochre; instead it should look like Ochre-lang's top-level syntax as much as possible.
Work on generalizing the "run compiler" code so I can just run particular steps and dump their output for checking.
Note - the pretty printer for the intermediate representation needs changing as it uses a syntax from the original Ochre; instead it should look like Ochre-lang's top-level syntax as much as possible.
Saturday, June 28, 2014
ochre-lang
Copperbox revision 3167.
I've removed Signal from the Value type in the intermediate syntax and added Tuple. Signal was a left over from when Ochre was embedded in Haskell. I've added Tuple even though tuples will need eliminating before the final translation to Csound. I believe I've devised an elimination scheme that will work if tuples are in the tail position - this will be easiest to do as a rewrite pass on the intermediate syntax (hence it needs tuples).
I've removed Signal from the Value type in the intermediate syntax and added Tuple. Signal was a left over from when Ochre was embedded in Haskell. I've added Tuple even though tuples will need eliminating before the final translation to Csound. I believe I've devised an elimination scheme that will work if tuples are in the tail position - this will be easiest to do as a rewrite pass on the intermediate syntax (hence it needs tuples).
Friday, June 27, 2014
ochre-lang
Copperbox revision 3166.
More work on supporting tuples, binding multiple return opcodes (e.g. ins, pan) is now possible.
However, my thinking has moved on since yesterday - I now think tuples should be first class, whereas yesterday I thought they would only be needed for destructuring at opcode binding sites (ins, pan again). If tuples aren't first class we can't write methods that return tuples, this is a too severe restriction as it limits modularity.
Because Csound doesn't have tuples, I will need to think carefully about how to implement them - they must be eliminated in translation.
More work on supporting tuples, binding multiple return opcodes (e.g. ins, pan) is now possible.
However, my thinking has moved on since yesterday - I now think tuples should be first class, whereas yesterday I thought they would only be needed for destructuring at opcode binding sites (ins, pan again). If tuples aren't first class we can't write methods that return tuples, this is a too severe restriction as it limits modularity.
Because Csound doesn't have tuples, I will need to think carefully about how to implement them - they must be eliminated in translation.
Thursday, June 26, 2014
ochre-lang
Copperbox revision 3165.
I've added lists to the type syntax - this allows opcodes with variable length argument lists to be encoded as builtins. I haven't yet encoded lists in the expression syntax.
Note - both lists and tuples will not be first class in Ochre-lang. Tuples will only support deconstruction (pattern matching) and lists will only support construction in opcode application.
I've added lists to the type syntax - this allows opcodes with variable length argument lists to be encoded as builtins. I haven't yet encoded lists in the expression syntax.
Note - both lists and tuples will not be first class in Ochre-lang. Tuples will only support deconstruction (pattern matching) and lists will only support construction in opcode application.
Wednesday, June 25, 2014
ochre-lang
Copperbox revision 3164.
I've changed the concrete syntax of opcode and function calls to be more like Csound and less like Haskell - params in opcode calls are comma separated, params in function calls are in parens and comma separated. This resolves a bug in the parser.
I've changed the concrete syntax of opcode and function calls to be more like Csound and less like Haskell - params in opcode calls are comma separated, params in function calls are in parens and comma separated. This resolves a bug in the parser.
Tuesday, June 24, 2014
ochre-lang
Copperbox revision 3163.
I've hooked up the optimization passes[*] and the final Csound code generator and the simple example now compiles to a working Csound orchestra. This is a success...
[*] As Ochre-lang has changed from being a (sort of) functional language to an OO one I'm not sure the optimization passes are relevant anymore - mostly they optimize forms which are no longer present in the intermediate code.
I've hooked up the optimization passes[*] and the final Csound code generator and the simple example now compiles to a working Csound orchestra. This is a success...
[*] As Ochre-lang has changed from being a (sort of) functional language to an OO one I'm not sure the optimization passes are relevant anymore - mostly they optimize forms which are no longer present in the intermediate code.
Monday, June 23, 2014
ochre-lang
Copperbox revision 3162.
I've now implemented the translation from top-level syntax to the intermediate syntax.
Although I've done some tidying up, there is still quite a lot of cruft in the intermediate syntax code brought over from the original Ochre. Thus, the intermediate syntax will need more cleaning up as I connect the optimization passes back in.
I've now implemented the translation from top-level syntax to the intermediate syntax.
Although I've done some tidying up, there is still quite a lot of cruft in the intermediate syntax code brought over from the original Ochre. Thus, the intermediate syntax will need more cleaning up as I connect the optimization passes back in.
ochre-lang
Copperbox revision 3161.
I've done most of the work on the translation from top-level syntax to the intermediate syntax. Unfortunately the intermediate syntax has quite a bit of cruft (inherited from the original Ochre) so I'll have to deal with that before I can finish the translation.
I've made a commit now because I don't want the changes to the intermediate syntax to form an overwhelming changeset.
I've done most of the work on the translation from top-level syntax to the intermediate syntax. Unfortunately the intermediate syntax has quite a bit of cruft (inherited from the original Ochre) so I'll have to deal with that before I can finish the translation.
I've made a commit now because I don't want the changes to the intermediate syntax to form an overwhelming changeset.
Sunday, June 22, 2014
ochre-lang
Copperbox revision 3160.
I've removed some redundant parts of the top-level syntax - let, lambda and embedded do in the Expr datatype. These forms were inherited from the original Ochre and aren't needed.
Simplifying this syntax is a diversion from inline expansion - it looks like inline expansion will be easier to perform on the intermediate syntax (where alpha renaming is available) so I'll have to translate from the top-level syntax before I complete the implementation of inline expansion.
I've removed some redundant parts of the top-level syntax - let, lambda and embedded do in the Expr datatype. These forms were inherited from the original Ochre and aren't needed.
Simplifying this syntax is a diversion from inline expansion - it looks like inline expansion will be easier to perform on the intermediate syntax (where alpha renaming is available) so I'll have to translate from the top-level syntax before I complete the implementation of inline expansion.
ochre-lang
Copperbox revision 3159.
Initial work inline expanding main so that Instrs have a single method. There is no procedural abstraction in Csound orchestras so we have to eliminate methods in Ochre by inlining them into a single main function.
Initial work inline expanding main so that Instrs have a single method. There is no procedural abstraction in Csound orchestras so we have to eliminate methods in Ochre by inlining them into a single main function.
Saturday, June 21, 2014
ochre-lang
Copperbox revision 3157.
I've added syntax for types so that I can define a list of Csound builtins.
I'm not sure otherwise if Ochre will get a type system - I may just implement arity checking of functions. A type system would be nice of course, but there are a lot of other things to implement first.
I've added syntax for types so that I can define a list of Csound builtins.
I'm not sure otherwise if Ochre will get a type system - I may just implement arity checking of functions. A type system would be nice of course, but there are a lot of other things to implement first.
ochre-lang
Copperbox revision 3156.
I've implemented a simple version of trait flattening (essentially cribbed from the Flattening Traits paper - Nierstrasz, Ducasse and Scharli).
I'll need to put it in the Compiler monad so it can log conflicts etc. and I'll have to add cycle detection for trait definitions, but at the moment it seems to work for my small example.
I've implemented a simple version of trait flattening (essentially cribbed from the Flattening Traits paper - Nierstrasz, Ducasse and Scharli).
I'll need to put it in the Compiler monad so it can log conflicts etc. and I'll have to add cycle detection for trait definitions, but at the moment it seems to work for my small example.
Friday, June 20, 2014
ochre-lang
Copperbox revision 3155.
Work towards flattening and inlining traits. I've changed the syntax so method declarations have a list of arguments (methods must always be fully specified - there is no currying) and added logging warnings to the Compiler monad. I've done some work on the flattening traits but even though I've read the trait papers from SCG Bern I'm not sure of a good way to do it for Ochre.
Work towards flattening and inlining traits. I've changed the syntax so method declarations have a list of arguments (methods must always be fully specified - there is no currying) and added logging warnings to the Compiler monad. I've done some work on the flattening traits but even though I've read the trait papers from SCG Bern I'm not sure of a good way to do it for Ochre.
Tuesday, June 17, 2014
ochre-lang
Copperbox revision 3154.
I've added traits (c.f Pharo Smalltalk) to the top-level syntax. My expectation is that traits will allow instruments to be defined from modular parts.
At the moment there is no flattening of traits - all the processing after parsing needs implementing...
I've added traits (c.f Pharo Smalltalk) to the top-level syntax. My expectation is that traits will allow instruments to be defined from modular parts.
At the moment there is no flattening of traits - all the processing after parsing needs implementing...
Monday, June 16, 2014
ochre-lang / majalan3
Copperbox revision 3153.
Ochre-lang - some work extending the top level syntax to allow modular definitions.
Majalan - changed TEMP_DIR environment variable name. I've just switched to a new development machine which highlighted this error (the previous env var name pertained to the now obsolete OM-shell).
Ochre-lang - some work extending the top level syntax to allow modular definitions.
Majalan - changed TEMP_DIR environment variable name. I've just switched to a new development machine which highlighted this error (the previous env var name pertained to the now obsolete OM-shell).
Wednesday, June 11, 2014
ochre-lang
Copperbox revision 3152.
I've added some extra syntax for instrument definitions before I start work on the translation from top-level syntax to the intermediate representation.
Instrument definitions should be thought of as (named) classes that are instantiated by an orchestra definition that supplies their instrument number (orchestra definitions are still to add to the syntax). Once I have class-like objects I hope implement something like traits to compose class fragments, modularizing the definition of instruments.
I've added some extra syntax for instrument definitions before I start work on the translation from top-level syntax to the intermediate representation.
Instrument definitions should be thought of as (named) classes that are instantiated by an orchestra definition that supplies their instrument number (orchestra definitions are still to add to the syntax). Once I have class-like objects I hope implement something like traits to compose class fragments, modularizing the definition of instruments.
Tuesday, June 10, 2014
ochre-lang
Copperbox revision 3151.
I've added a pretty printer to a s-expression format (with a bit of GHC core slipped in). This is to help me better identify what syntax forms I'm dealing with after parsing, before I start the translation from the top level syntax to the intermediate representation.
I've added a pretty printer to a s-expression format (with a bit of GHC core slipped in). This is to help me better identify what syntax forms I'm dealing with after parsing, before I start the translation from the top level syntax to the intermediate representation.
Monday, June 9, 2014
ochre-lang
Copperbox revision 3150.
I've added the K-Normal Form like intermediate syntax and the optimizations passes from the original (Haskell embedded) Ochre.
I've added the K-Normal Form like intermediate syntax and the optimizations passes from the original (Haskell embedded) Ochre.
Sunday, June 8, 2014
ochre-lang
Copperbox revision 3149.
Initial work adding syntax data types for the Csound backend. It looks like it will be better to have the K-Normal Form style immediate syntax that the original Ochre had, rather than translate to Csound from the current monadic syntax. This is good news as I can reuse much of the original Ochre.
Initial work adding syntax data types for the Csound backend. It looks like it will be better to have the K-Normal Form style immediate syntax that the original Ochre had, rather than translate to Csound from the current monadic syntax. This is good news as I can reuse much of the original Ochre.
Thursday, June 5, 2014
ochre-lang
Copperbox revision 3148.
Updated ochre-lang correcting the do-notation which didn't work previously. Because I want to implement a module system for Ochre I'm seriously thinking of developing it as a closed (i.e. not embedded) DSL, hence I've rebooted work on ochre-lang.
Updated ochre-lang correcting the do-notation which didn't work previously. Because I want to implement a module system for Ochre I'm seriously thinking of developing it as a closed (i.e. not embedded) DSL, hence I've rebooted work on ochre-lang.
Subscribe to:
Posts (Atom)
Blog Archive
About Me
- Stephen Tetley
- Disambiguating biog as there are a few Stephen Tetley's in the world. I'm neither a cage fighter or yachtsman. I studied Fine Art in the nineties (foundation Bradford 1992, degree Cheltenham 1992 - 95) then Computing part-time at Leeds Met graduating in 2003. I'm the Stephen Tetley on Haskell Cafe and Stackoverflow.