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.
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.
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.