Copperbox revision 2795.
Initial work on a new AFM parser.
This time round it doesn't seem necessary to define my own parser combinators - I did this for Wumpus-Basic as the platform shipped with Parsec 2 at the time. Now it ships with Parsec 3, I don't mind the dependency.
Saturday, June 30, 2012
Friday, June 29, 2012
Thursday, June 28, 2012
Wednesday, June 27, 2012
Tuesday, June 26, 2012
Monday, June 25, 2012
Sunday, June 24, 2012
lirio
Copperbox revision 2789.
I've reworked the note lists to use more overloading and changed their internals so they wrap one of two primitive note lists - one for relative duration and the other for absolute duration. By wrapping one of these, note lists can get most of their type class instances from lifting the appropriate operations on the primitive note list, usually only NoteM and ChordM need implementing "longhand".
Quite a bit of code still needs tidying up...
I've reworked the note lists to use more overloading and changed their internals so they wrap one of two primitive note lists - one for relative duration and the other for absolute duration. By wrapping one of these, note lists can get most of their type class instances from lifting the appropriate operations on the primitive note list, usually only NoteM and ChordM need implementing "longhand".
Quite a bit of code still needs tidying up...
Saturday, June 23, 2012
Friday, June 22, 2012
Thursday, June 21, 2012
lirio
Copperbox revision 2786.
Initial work on lyrics in the lyricmode style - i.e. syllables with duration annotations.
When I have more time, I'll have to look at overloading for the note list representations - I need quite a few different note list types and qualified imports aren't adequate.
Initial work on lyrics in the lyricmode style - i.e. syllables with duration annotations.
When I have more time, I'll have to look at overloading for the note list representations - I need quite a few different note list types and qualified imports aren't adequate.
Wednesday, June 20, 2012
lirio
Copperbox revision 2785.
I've simplified the internal Glyph / Doc type so everything supports suffixing (suffixing is necessary for beams and slurs). Whilst this means Lirio performs less checking - there is more opportunity to make bad syntax, the implementation is now more obvious. There is no longer a mystery about what is a note and what is a glyph.
I've simplified the internal Glyph / Doc type so everything supports suffixing (suffixing is necessary for beams and slurs). Whilst this means Lirio performs less checking - there is more opportunity to make bad syntax, the implementation is now more obvious. There is no longer a mystery about what is a note and what is a glyph.
Tuesday, June 19, 2012
Monday, June 18, 2012
ochre
Copperbox revision 2783.
Work on signal IO opcodes. I've also done a small amount of work on making the phantom layer more polymorphic - though I'll have to postpone this until I can work on it at a weekend when I have more time. I've managed a commit a day over the last week, for the first time in ages; if I tackle something that needs "design" this will lose my momentum.
Work on signal IO opcodes. I've also done a small amount of work on making the phantom layer more polymorphic - though I'll have to postpone this until I can work on it at a weekend when I have more time. I've managed a commit a day over the last week, for the first time in ages; if I tackle something that needs "design" this will lose my momentum.
Sunday, June 17, 2012
Saturday, June 16, 2012
ochre
Copperbox revision 2780.
I've added List to the type representation and made tuples heterogeneous so I can model Csound's C-style arg lists - the calling convention for Csound opcodes is like C but Ochre can now encodes variadic functions as lists. As nothing really uses source language types within Ochre (save temporary variable generation), having polymorphic lists and tuples doesn't add complexity.
Also I've made a start on signal modifiers.
I've added List to the type representation and made tuples heterogeneous so I can model Csound's C-style arg lists - the calling convention for Csound opcodes is like C but Ochre can now encodes variadic functions as lists. As nothing really uses source language types within Ochre (save temporary variable generation), having polymorphic lists and tuples doesn't add complexity.
Also I've made a start on signal modifiers.
Friday, June 15, 2012
Thursday, June 14, 2012
Wednesday, June 13, 2012
ochre
Copperbox revision 2777.
First round of work coding the signal modifier built-ins.
Another nit with the type system - I don't properly handle that Ints could be actually ints or variables / pfields representing ints. This is another bit where embedding in Haskell has allowed me to shirk some duty I have to developing a sound type system. If I had designed a closed DSL, I would have been forced to address this short-coming much sooner.
First round of work coding the signal modifier built-ins.
Another nit with the type system - I don't properly handle that Ints could be actually ints or variables / pfields representing ints. This is another bit where embedding in Haskell has allowed me to shirk some duty I have to developing a sound type system. If I had designed a closed DSL, I would have been forced to address this short-coming much sooner.
Tuesday, June 12, 2012
ochre
Copperbox revision 2776.
I've implemented the base opcodes - base is an arbitrary grouping that I happened to use for Ochre's predecessor Orchsyn, basically they are the Math opertations on pages 704 and 705 of the Csound book.
Implementing these opcodes has flagged up some problems in Ochre's type system. Ochre should really be monomorphic, though it is a bit tricksy as it doesn't have a type dictionary - opcodes can cheat and have different typings according to how they are used in the host language Haskell (as the embedding of Ochre borrows some of Haskell's polymorphism).
Ideally I should give opcodes concrete monomorphic types and probably recover Csound's limited polymorphism by duplicating opcodes for different types.
I've implemented the base opcodes - base is an arbitrary grouping that I happened to use for Ochre's predecessor Orchsyn, basically they are the Math opertations on pages 704 and 705 of the Csound book.
Implementing these opcodes has flagged up some problems in Ochre's type system. Ochre should really be monomorphic, though it is a bit tricksy as it doesn't have a type dictionary - opcodes can cheat and have different typings according to how they are used in the host language Haskell (as the embedding of Ochre borrows some of Haskell's polymorphism).
Ideally I should give opcodes concrete monomorphic types and probably recover Csound's limited polymorphism by duplicating opcodes for different types.
Monday, June 11, 2012
Sunday, June 10, 2012
ochre
Copperbox revision 2774.
I've re-implemented the tagless phantom typed layer with a state monad instead. The types are much simpler, so I've included the all important Num and Fractional instances for signals.
The new monadic layer is in a style I've never used before - previously I've had code generators that could collect statements using a monoid so the user code would use the do-notation with a Writer as the underlying monad. Here the monad builds a single expression (usually nested) - the expression has no mempty or mappend so it is built with a library of combinators that model the syntax faithfully, user code does not use the do-notation.
I've re-implemented the tagless phantom typed layer with a state monad instead. The types are much simpler, so I've included the all important Num and Fractional instances for signals.
The new monadic layer is in a style I've never used before - previously I've had code generators that could collect statements using a monoid so the user code would use the do-notation with a Writer as the underlying monad. Here the monad builds a single expression (usually nested) - the expression has no mempty or mappend so it is built with a library of combinators that model the syntax faithfully, user code does not use the do-notation.
Friday, June 8, 2012
Thursday, June 7, 2012
ochre
Copperbox revision 2771.
I think I've designed a type system for Ochre. I struggled with this before ("my first type system") but really it is the same as designing a typed library, plus cribbing some type signatures from SML as I have effects (ref cells and output) within the language rather than stratified as monadic effects.
Revision 2770 forgot to add the new file Typing.hs which is the mock-up of type system in use.
I think I've designed a type system for Ochre. I struggled with this before ("my first type system") but really it is the same as designing a typed library, plus cribbing some type signatures from SML as I have effects (ref cells and output) within the language rather than stratified as monadic effects.
Revision 2770 forgot to add the new file Typing.hs which is the mock-up of type system in use.
Wednesday, June 6, 2012
Tuesday, June 5, 2012
swidgets
Copperbox revision 2768.
Surprising development - first Java commit to Copperbox... (swidgets = Stephen's widgets)
I've started developing the Processing GUI widgets a bit more seriously. It turns out that advanced "Processing" is actually Java - Processing (the environment / compiler, whatever...) has no concept of shared libraries written in Processing (the language) so you have to write libraries in Java. This isn't a huge difference - Processing (the language) seems to be Java less some bits and with other bits implicit to save typing.
Surprising development - first Java commit to Copperbox... (swidgets = Stephen's widgets)
I've started developing the Processing GUI widgets a bit more seriously. It turns out that advanced "Processing" is actually Java - Processing (the environment / compiler, whatever...) has no concept of shared libraries written in Processing (the language) so you have to write libraries in Java. This isn't a huge difference - Processing (the language) seems to be Java less some bits and with other bits implicit to save typing.
Sunday, June 3, 2012
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.