Hi Tom,
On 29-03-2015 20:32, <email obscured> wrote:
> Hi Miguel -- calculation rates can always be specified with "?" --
> e.g.
>
> sinOsc (Freq 1) ? KR
>
> Everything defaults to its most-common use-case (usually .ar -- the
> docs should say when it's not .ar), but you can always resolve
> ambiguity with "?"
Ah nice !
Tried to build vivid with nix, but it's quite hard because it depends
on hashable 1.1-* which is quite old (2012) and depends on other older
packages so it's not compatible with a current package set. Any plans to
upgrade to hashable 1.2 ? Current version on stackage and nix is 1.2.3.2.
Hey Miguel -- thanks, I've updated this. It should work for you now.
Tom
El Mar 29, 2015, a las 18:32, Miguel Negrão
<email obscured>> escribió:
Rest of post
> Hi Tom,
>
> On 29-03-2015 20:32, <email obscured> wrote:
>> Hi Miguel -- calculation rates can always be specified with "?" --
>> e.g.
>>
>> sinOsc (Freq 1) ? KR
>>
>> Everything defaults to its most-common use-case (usually .ar -- the
>> docs should say when it's not .ar), but you can always resolve
>> ambiguity with "?"
>
> Ah nice !
>
> Tried to build vivid with nix, but it's quite hard because it depends
> on hashable 1.1-* which is quite old (2012) and depends on other older
> packages so it's not compatible with a current package set. Any plans to
> upgrade to hashable 1.2 ? Current version on stackage and nix is 1.2.3.2.
>
> best,
> Miguel
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/55E5ZEaeWIoCmqo1iDEhyU
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe
El Mar 30, 2015, a las 7:13, Miguel Negrão
<email obscured>> escribió:
> On 30-03-2015 00:29, <email obscured> wrote:
>> Hey Miguel -- thanks, I've updated this. It should work for you now.
>>
>> Tom
>
> Great, thanks, now it builds easilly with nix. For future reference here
> is a config.nix for vivid with IHaskel:
>
> place in ~/.nixpkgs/config.nix
>
> https://gist.github.com/miguel-negrao/8234ad179274e7657e2a
>
> place in ~/.nixpkds/haskell/vivid-0.1.0.3.nix :
>
> https://gist.github.com/miguel-negrao/ce2564ccbf32b9ad81c5
>
> then
>
>> nix-env -iA nixpkgs.ihaskell-with-packages --option extra-binary-caches
http://hydra.nixos.org --option extra-binary-caches http://hydra.cryp.to
Rest of post
--cores 4
>
> Currently this is will build quite a few haskell packages from source.
> To download almost all the packages as binaries you have to use the more
> recent nixpkgs from github. Clone the nixpkgs from github to somewhere
> local and then :
>
>> nix-env -I nixpkgs=/path/to/the/clone/of/nixpkgs -iA ihaskell-with-packages
--option extra-binary-caches http://hydra.nixos.org --option
extra-binary-caches http://hydra.cryp.to -f '<nixpkgs>' --cores 4
>
> Works nicelly in IHaskell, check how it looks here:
>
> http://www.friendlyvirus.org/files/vivid.html
>
This looks really nice! I could see IHaskell becoming the default "Vivid IDE"
in the future.
> to run it you do:
>
> IHaskell notebook
>
> best,
> Miguel
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/7cSY1qmcVtY6Xvve2pjsIZ
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe
A few weeks ago I was thinking the problem with Haskell (for SC use) was
the lack of named parameters with default values + naming problems with
record syntax. So I googled around and found this:
http://nikita-volkov.github.io/record/
I cannot get it to work, but as I said, I'm a complete noob in haskell. I
think it could solve many headaches though.
On 30 March 2015 at 13:13, Miguel Negrão <
Rest of post
<email obscured>> wrote:
> On 30-03-2015 00:29, <email obscured> wrote:
> > Hey Miguel -- thanks, I've updated this. It should work for you now.
> >
> > Tom
>
> Great, thanks, now it builds easilly with nix. For future reference here
> is a config.nix for vivid with IHaskel:
>
> place in ~/.nixpkgs/config.nix
>
> https://gist.github.com/miguel-negrao/8234ad179274e7657e2a
>
> place in ~/.nixpkds/haskell/vivid-0.1.0.3.nix :
>
> https://gist.github.com/miguel-negrao/ce2564ccbf32b9ad81c5
>
> then
>
> > nix-env -iA nixpkgs.ihaskell-with-packages --option extra-binary-caches
> http://hydra.nixos.org --option extra-binary-caches http://hydra.cryp.to
> --cores 4
>
> Currently this is will build quite a few haskell packages from source.
> To download almost all the packages as binaries you have to use the more
> recent nixpkgs from github. Clone the nixpkgs from github to somewhere
> local and then :
>
> > nix-env -I nixpkgs=/path/to/the/clone/of/nixpkgs -iA
> ihaskell-with-packages --option extra-binary-caches http://hydra.nixos.org
> --option extra-binary-caches http://hydra.cryp.to -f '<nixpkgs>' --cores 4
>
> Works nicelly in IHaskell, check how it looks here:
>
> http://www.friendlyvirus.org/files/vivid.html
>
> to run it you do:
>
> IHaskell notebook
>
> best,
> Miguel
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/7cSY1qmcVtY6Xvve2pjsIZ
>
> To leave Haskell Art, email <email obscured> with the following
> email subject: unsubscribe
>
On Sat, 4 Apr 2015, Jose Barragán Sabio wrote:
> A few weeks ago I was thinking the problem with Haskell (for SC use) was
> the lack of named parameters with default values + naming problems with
> record syntax. So I googled around and found this:
> http://nikita-volkov.github.io/record/
I don't think you need advanced syntax hacks to achieve this. Even in
plain Haskell 98 you could define operators in a way that allow you to
write e.g.
rlpf & freq 100 & reso 10
rlpf :: UGen ResonantFilter
freq :: (Frequency typ) => Float -> UGen typ -> UGen typ
reso :: (Resonance typ) => Float -> UGen typ -> UGen typ
(&) = flip ($)
instance Frequency ResonantFilter
instance Resonance ResonantFilter
Hi Rohan,
I'm not able to reproduce that behavior -- here's a simple example:
Rest of post
-- file: SinOsc.hs:
{-# LANGUAGE DisambiguateRecordFields #-}
module SinOsc where
data SinOsc = SinOsc { freq :: Int, phase :: Int }
deriving (Show)
sinOsc = SinOsc { phase = 0 }
-- file: LFTri.hs:
{-# LANGUAGE DisambiguateRecordFields #-}
module LFTri where
data LFTri = LFTri { freq :: Int, phase :: Int }
deriving (Show)
lfTri = LFTri { phase = 0 }
-- file: foo.hs:
import LFTri
import SinOsc
main = do
print $ sinOsc { freq = 440 }
print $ lfTri { freq = 440 }
I get complaints about:
Ambiguous occurrence ‘freq’
It could refer to either ‘LFTri.freq’ or ‘SinOsc.freq’
This seems consistent with the docs (
https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/syntax-extns.html#disambiguate-fields
), and (a little bit annoyingly) still doesn't work even with an explicit
e.g. ":: SinOsc".
Were you able to work around this somehow?
Tom
On Thu, Apr 9, 2015 at 11:01 PM, Rohan Drape <email obscured>> wrote:
> hello tom,
>
> > But to have default record fields (which is the thing i'm trying to
> > solve), we'd need default values, e.g.
> >
> > sinOsc = SinOsc { rate = AR, freq = 440, phase = 0 }
> >
> > Which would require users to write e.g.
> >
> > sinOsc { SO.rate = KR, SO.freq = 220 }
>
> actually we can write the field names unqualified. we don't even need
> DisambiguateRecordFields at the "caller" if we write it into the
> library. i added a "DRF" module at hsc3-rec to illustrate this, the
> examples below are from the help file.
>
> best,
> rohan
>
> ps. i put an R (for record) suffix on the names so they don't collide
> with hsc3. this form is kind of nice, it gives the standard hsc3
> conventions if you write the constructor directly (ie. upper case, see
> "track" below).
>
> import Sound.SC3 {- hsc3 -}
> import Sound.SC3.UGen.Record.DRF {- hsc3-rec -}
>
> -- > drawR analog_bubbles
> -- > auditionR analog_bubbles
> analog_bubbles :: UGenR
> analog_bubbles =
> let o = lfSawR {rate = KR,freq = mceR [8,7.23]} * 3 + 80
> f = lfSawR {rate = KR,freq = 0.4} * 24 + o
> s = sinOscR {freq = midiCPSR f} * 0.04
> c = combNR {input = s,decaytime = 4}
> in outR {input = c}
>
> -- > drawR sprinkler
> -- > auditionR sprinkler
> sprinkler :: UGenR
> sprinkler =
> let f = lfPulseR {rate = KR,freq = 0.09,width = 0.16} * 10 + 7
> t = lfPulseR {rate = KR,freq = f,width = 0.25} * 0.1
> in outR {input = bpz2R {input = whiteNoiseR * t}}
>
> -- > drawR track
> -- > auditionR track
> track :: UGenR
> track =
> let x = MouseX 220 660 Linear 0.1
> y = MouseY 0.05 0.25 Linear 0.1
> s = Saw AR x * y
> a = Amplitude KR s 0.05 0.05
> [f,_] = mceChannelsR (pitchR {input = s})
> in Out 0 (mceR [s * 0.25,SinOsc AR (f / 2) 0 * a])
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
>
http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>
hello tom,
> I'm not able to reproduce that behavior -- here's a simple example:
the variant that works is at:
http://rd.slavepianos.org/sw/hsc3-rec/Sound/SC3/UGen/Record/DRF/Type.hs
the 'UGen' type has a constructor for each unit generator.
i deleted the 'R' suffix, so there's now a module Sound.SC3.UGen.Record.DRF
that re-exports the parts of hsc3 required for simple graphs.
the 'autogen' codes are at:
http://rd.slavepianos.org/sw/hsc3-rec/mk/build-drf.hs
i've only added a few ugens to the "whitelist" so far, enough to test
the graphs at:
http://rd.slavepianos.org/sw/hsc3-graphs/gr/analog-bubbles-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/analogue-daze-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/berlin-1977-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/bouncing-objects-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/drummer-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/lfo-modulation-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/sample-and-hold-liquidities-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/sprinkler-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/strummable-guitar-r.hs
http://rd.slavepianos.org/sw/hsc3-graphs/gr/synthetic-piano-r.hs
there are other more "expressive" record systems for haskell, it
depends on what you're wanting to do, but the standard records do
allow default values and named parameters that overlap...
best,
rohan
ps. i've only got ghc 7.10.1 here...
pps. a simplified example to test this is:
{-# LANGUAGE DisambiguateRecordFields #-}
data U = A {freq :: Double,phase :: Double}
| B {freq :: Double,phase :: Double}
a,b :: U
a = A 440 0
b = B 440 0
c :: (U,U)
c = (a {phase = pi},b {freq = 441})
Hi Rohan,
I'd missed that all ugens are of type UGen -- that explains it (and in
fact you don't need -XDisambiguateRecordFields then). A thing that sucks
about that, though (although I see the advantages) is that code like this
typechecks without errors or warnings:
data UGen
= SinOsc { freq :: Float }
| OtherThing { freq :: Float, someCrazyArg :: String }
deriving (Show)
sinOsc = SinOsc { freq = 440 }
main = print $ sinOsc { someCrazyArg = "aw crap" }
Rest of post
Tom
On Mon, Apr 20, 2015 at 10:31 PM, Rohan Drape <email obscured>> wrote:
> hello tom,
>
> > I'm not able to reproduce that behavior -- here's a simple example:
>
> the variant that works is at:
>
> http://rd.slavepianos.org/sw/hsc3-rec/Sound/SC3/UGen/Record/DRF/Type.hs
>
> the 'UGen' type has a constructor for each unit generator.
>
> i deleted the 'R' suffix, so there's now a module Sound.SC3.UGen.Record.DRF
> that re-exports the parts of hsc3 required for simple graphs.
>
> the 'autogen' codes are at:
>
> http://rd.slavepianos.org/sw/hsc3-rec/mk/build-drf.hs
>
> i've only added a few ugens to the "whitelist" so far, enough to test
> the graphs at:
>
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/analog-bubbles-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/analogue-daze-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/berlin-1977-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/bouncing-objects-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/drummer-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/lfo-modulation-r.hs
>
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/sample-and-hold-liquidities-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/sprinkler-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/strummable-guitar-r.hs
> http://rd.slavepianos.org/sw/hsc3-graphs/gr/synthetic-piano-r.hs
>
> there are other more "expressive" record systems for haskell, it
> depends on what you're wanting to do, but the standard records do
> allow default values and named parameters that overlap...
>
> best,
> rohan
>
> ps. i've only got ghc 7.10.1 here...
>
> pps. a simplified example to test this is:
>
> {-# LANGUAGE DisambiguateRecordFields #-}
>
> data U = A {freq :: Double,phase :: Double}
> | B {freq :: Double,phase :: Double}
>
> a,b :: U
> a = A 440 0
> b = B 440 0
>
> c :: (U,U)
> c = (a {phase = pi},b {freq = 441})
>
>
> _______________________________________________
> sc-users mailing list
>
> info (subscription, etc.):
>
http://www.birmingham.ac.uk/facilities/ea-studios/research/supercollider/mailinglist.aspx
> archive: http://www.listarc.bham.ac.uk/marchives/sc-users/
> search: http://www.listarc.bham.ac.uk/lists/sc-users/search/
>
hello tom,
> and in fact you don't need -XDisambiguateRecordFields then
well spotted! that makes DRF a very poor name for this... i'll
change it to CRU, which is also bad but less obviously so...
> main = print $ sinOsc { someCrazyArg = "aw crap" }
yes, that's unfortunate isn't it.
perhaps one day there will be an excellent record system with conscise
syntax and coherent rules and "al manner of thyng shal be wele"...
Resurrecting a pretty old thread here, but I think I've found a nice way
to crack this problem, which I use in Vivid 0.2 -- thought I'd give a run-down:
If you'll recall, when we last saw our heros they were struggling with the
inability to have 3 things in our UGens simultaneously:
- Default argument values: if we don't use records we need to require all
arguments, and so we'd need to e.g. provide a "phase" to every SinOsc
- Type-checked arguments: if we use records to represent our values, we can't
use "freq" only on the ugens it makes sense on: someone could accidentally give
WhiteNoise a freq. We could make them unambiguous, but we also want...
- Short argument names: nobody wants to write "sinOscFreq" - they want to
write "freq"!
Here's what I've come up with. It uses some type cleverness but it should
be just as easy for the user:
Ugens have a type like:
sinOsc :: Args '["freq"] '["phase"] a => a -> Signal
("Signal" is simplified here)
So sinOsc takes one argument. The way we read the "Args" part is that "a"
must contain a value tagged as "freq", and may optionally contain a value
tagged as "phase" (the first list is for required; the second for optional). It
also requires that "a" can't contain things tagged as anything else.
We can pass any values in, tagged as "freq" -- SynthDef arguments,
numbers, and ugen outputs. How do we tag something as "freq"? There's a
function called "freq_", which tags it. There are "_" functions for every ugen
argument you need.
So now we can pass a tuple of these tagged values, and voila!:
sinOsc (freq_ 440, phase_ 1)
or
sinOsc (freq_ 440)
I've been using this for about 6 months and it's worked beautifully. I'd
be very interested in yalls thoughts about it!
The library's here:
hackage.haskell.org/package/vivid
Rest of post
Tom
> El 20 abr 2015, a las 23:58, Rohan Drape <email obscured>> escribió:
>
> hello tom,
>
>> and in fact you don't need -XDisambiguateRecordFields then
>
> well spotted! that makes DRF a very poor name for this... i'll
> change it to CRU, which is also bad but less obviously so...
>
>> main = print $ sinOsc { someCrazyArg = "aw crap" }
>
> yes, that's unfortunate isn't it.
>
> perhaps one day there will be an excellent record system with conscise
> syntax and coherent rules and "al manner of thyng shal be wele"...
>
> best,
> rohan
>
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/7pdQD7jQ1E48o46qFF1ypI
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe
On Mon, 21 Mar 2016, <email obscured> wrote:
> Resurrecting a pretty old thread here, but I think I've found a nice way
to crack this problem, which I use in Vivid 0.2 -- thought I'd give a run-down:
>
> If you'll recall, when we last saw our heros they were struggling with
the inability to have 3 things in our UGens simultaneously:
>
> - Default argument values: if we don't use records we need to require all
arguments, and so we'd need to e.g. provide a "phase" to every SinOsc
> - Type-checked arguments: if we use records to represent our values, we
can't use "freq" only on the ugens it makes sense on: someone could
accidentally give WhiteNoise a freq. We could make them unambiguous, but we
also want...
> - Short argument names: nobody wants to write "sinOscFreq" - they want to
write "freq"!
I just watched the interface of vivid and wondered about the scary types.
I think it would be possible even in Haskell 98 to have something like
this:
sinOsc :: UGen SinOsc
freq :: (Freq typ) => Float -> UGen typ -> UGen typ
phase :: (Phase typ) => Float -> UGen typ -> UGen typ
class Freq typ where setFreq :: typ -> typ
instance Freq SinOsc where setFreq f args = args {sinOscFreq = f}
instance Phase SinOsc where ...
SinOsc is the record holding the arguments for a sine oscillator.
Then you could write:
phase (pi/2) $ freq 800 sinOsc
Hi Henning! The types are advanced but the user doesn't need to know any type
fanciness -- they just need to know how to read e.g.
Args '["freq"] '["phase"] a =>
As far as your alternative, I had considered something very similar, but
the biggest obstacles were:
- No required arguments: some UGens don't/can't have a "default" value, but
there's nothing preventing the user from calling it without modifying any args
- It's more work to create a new UGen: you need to create the type of the
record with "foo" prefixes on its args, then an instance of that record, and
also the Freq, etc instances for each arg. You'll also need a function to
convert that particular ugen to something SC understands. My hope is that users
can make UGens themselves fairly quickly. Most ugens in vivid are defined in a
couple of lines, with a standard "makeUGen" function.
Thanks,
Tom
> El 22 mar 2016, a las 03:56, Henning Thielemann
<email obscured>> escribió:
>
>
>> On Mon, 21 Mar 2016, <email obscured> wrote:
>>
>> Resurrecting a pretty old thread here, but I think I've found a nice way
to crack this problem, which I use in Vivid 0.2 -- thought I'd give a run-down:
>>
>> If you'll recall, when we last saw our heros they were struggling with
the inability to have 3 things in our UGens simultaneously:
>>
>> - Default argument values: if we don't use records we need to require all
arguments, and so we'd need to e.g. provide a "phase" to every SinOsc
>> - Type-checked arguments: if we use records to represent our values, we
can't use "freq" only on the ugens it makes sense on: someone could
accidentally give WhiteNoise a freq. We could make them unambiguous, but we
also want...
>> - Short argument names: nobody wants to write "sinOscFreq" - they want to
write "freq"!
Rest of post
>
> I just watched the interface of vivid and wondered about the scary types.
> I think it would be possible even in Haskell 98 to have something like
> this:
>
> sinOsc :: UGen SinOsc
>
> freq :: (Freq typ) => Float -> UGen typ -> UGen typ
> phase :: (Phase typ) => Float -> UGen typ -> UGen typ
>
> class Freq typ where setFreq :: typ -> typ
> instance Freq SinOsc where setFreq f args = args {sinOscFreq = f}
> instance Phase SinOsc where ...
>
> SinOsc is the record holding the arguments for a sine oscillator.
>
>
> Then you could write:
> phase (pi/2) $ freq 800 sinOsc
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/I5rZKvj6KuAhGvpTSWQV7
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe
One more conceptual question: In graphs of signals, you often have multiple
“interpretations” of one and the same signal. For instance, you correlate a
change in frequency with a change in amplitude (topologically this is a fan out
followed later by a fan in). Is it correct that for typed signals, this means
that either the output of a UGen has a type class that contains all possible
inputs of all UGens as members?
> On 23.03.2016, at 10:14, Julian Rohrhuber
<email obscured>> wrote:
>
> ― Attachment links are at the end of this email ―
>
> One more conceptual question: In graphs of signals, you often have multiple
“interpretations” of one and the same signal. For instance, you correlate a
change in frequency with a change in amplitude (topologically this is a fan out
followed later by a fan in). Is it correct that for typed signals, this means
that either the output of a UGen has a type class that contains all possible
inputs of all UGens as members?
… or that you need type conversions in between?
hello julian,
it's not that type of typing...
all ugens end up with the same type.
(there is a lot of work on typing data flow
systems, but supercollider bindings aren't really
an approriate place for it)
(ie. signal types could tell things like what
clock-rate the signal is on, how many input tokens
it consumes to produce an output token, the type
of the tokens etc. etc.)
this is more about the haskell record system,
which is very simple
(the history of why it's still the way it is is
interesting...)
in this particular case i don't think the standard
haskell records are so bad
for ugens they behave about the same as sclang
named arguments, except that it's either all
positional or all named, no mixing
ie. http://rd.slavepianos.org/sw/hsc3-rec/Help/cru.hs
the runtime error for setting a field that doesn't
exist (ie. the x_err_no_field value in that file)
is
*** Exception:
/home/rohan/sw/hsc3-rec/Help/cru.hs:52:18-37:
Non-exhaustive patterns in record update
which is pretty good. it's the same situation as
if you wrote SinOsc.ar(width:0.5) in sclang
i've found that, for supercollider work, defering
ugen graph errors to run-time isn't a problem, i
mean there are enough other problems...
the other aspect, annotating "required" arguments,
seems like a separate issue, ie. you could lift
them out as arguments to the "default"
constructor, etc.
it's also kind of ambigous, though less so with
say CombN.ar() than SinOsc.ar().
in any case, for ugens i think the most useful
thing is having an editor that shows what the
parameters and the default values are.
hello rohan,
ah ok, that is a very good explanation. And yes, the separation between runtime
and compile time isn’t really relevant in a dynamic system like supercollider.
> this is more about the haskell record system,
> which is very simple
>
> (the history of why it's still the way it is is
> interesting…)
I’m curious why - maybe it works as an exile where other approaches would get
too involved?
> On 23.03.2016, at 12:57, Rohan Drape <email obscured>> wrote:
>
>> I’m curious why - maybe it works as an exile where other approaches would
get too involved?
>
> i think it's something like that, and that it's actually a hard problem...
>
> there was a "concrete proposal for replacing the labeled field
> mechanisms of Haskell" last century...
>
> 1996 http://web.cecs.pdx.edu/~mpj/pubs/polyrec.html
> 1999 http://research.microsoft.com/en-us/um/people/simonpj/papers/records.htm
>
> there's a very, very long thread starting at
>
https://mail.haskell.org/pipermail/glasgow-haskell-users/2011-September/020897.html
>
> i didn't read very much of it, but do remember spj writing of "the
> vast swamp of competing and overlapping proposals for records"...
> (ie. quoted in "stalled again" at
>
https://mail.haskell.org/pipermail/glasgow-haskell-users/2011-December/021359.html)
>
> the https://ghc.haskell.org/trac/ghc/wiki/Records/OverloadedRecordFields
> extensions seem close though...
impressive history indeed. this is a good example of how programming languages
are trade-offs in terms of simplicity, what is trivial in one is hard in
another - and of course the other way round.
is it correct that one of the main difficulties arise from the fact that names
(identifiers, symbols, or whatever one may want to call them) are not
first-class citizens here? So a name is always inserted and bound into a fixed,
predefined scope?
btw. i’m confident that all this has artistic implications, i’m just not yet
sure which ...
hello tom
> In a way, the solution I arrived on is conceptually simpler,
> since it's just labels: you can use whichever ones you like.
yes. still there's nice aspects to using records that i guess
are lost with this approach?
let o = sinOsc {freq = lfSaw {freq = 0.4} * 24 + 200}
in o + o {freq = freq o * lfSaw {freq = 0.1}}
(for non-haskellers reading along, ie. julian, "freq o" is the
frequency of o, and "o {freq = ...}" is a variant of o where the
frequency is "...". of course o is a variant of sinOsc in exactly
the same way...)
hello julian
> is it correct that one of the main difficulties arise from the
> fact that names (identifiers, symbols, or whatever one may want
> to call them) are not first-class citizens here? So a name is
> always inserted and bound into a fixed, predefined scope?
i'm not sure, in part, it's an aspect. there are many difficulties...
the paper i remember on this is
2005 http://research.microsoft.com/apps/pubs/default.aspx?id=65409
there's a library for anonymous records, with nice syntax courtesy a
pre-processor
https://github.com/nikita-volkov/record-preprocessor
one day...
> btw. i’m confident that all this has artistic implications, i’m
> just not yet sure which ...
"The second time that great inviting door seemed to swing open
was around 1976 - 77 in the California Bay Area, at the time when
micro-computers first became cheap and small."
http://www.furious.com/perfect/behrman.html
> El 23 mar 2016, a las 20:13, Rohan Drape <email obscured>> escribió:
>
> hello tom
>
>> In a way, the solution I arrived on is conceptually simpler,
>> since it's just labels: you can use whichever ones you like.
>
> yes. still there's nice aspects to using records that i guess
> are lost with this approach?
>
> let o = sinOsc {freq = lfSaw {freq = 0.4} * 24 + 200}
> in o + o {freq = freq o * lfSaw {freq = 0.1}}
>
Hey, Rohan!
Yes, it's true that with the labeling system I came up with it's harder to
rearrange ugens as you're making them or retrieve values from inside a ugen
graph as you're making it. It wasn't a priority for me as I was designing, but
I think it's probably possible to make it pretty succinct. Probably not as
succinct as records, though!
In Vivid, you'd write the above something like:
do saw0 <- lfSaw (freq_ 0.4) ~* 24 ~+ 200
sin0 <- sinOsc (freq_ $ saw0 ~* lfSaw (freq_ 0.1))
sinOsc (freq_ saw0) ~+ sin0
So it's a bit longer but also (in my view) quite readable.
By the way, have you had a chance to poke around with the new Vivid? I'd
be very interested to hear what you think of the new designs!
Rest of post
Tom
> (for non-haskellers reading along, ie. julian, "freq o" is the
> frequency of o, and "o {freq = ...}" is a variant of o where the
> frequency is "...". of course o is a variant of sinOsc in exactly
> the same way...)
>
> best,
> rohan
>
> --
>
> Read the whole topic here: Haskell Art:
> http://lurk.org/r/topic/4z5GFidD9x7cFW8lZSd7fA
>
> To leave Haskell Art, email <email obscured> with the following
email subject: unsubscribe
On Tue, 22 Mar 2016, <email obscured> wrote:
> - No required arguments: some UGens don't/can't have a "default"
> value, but there's nothing preventing the user from calling it without
> modifying any args
Then you can fall back to regular Haskell function arguments.
> - It's more work to create a new UGen: you need to create the type of
> the record with "foo" prefixes on its args, then an instance of that
> record, and also the Freq, etc instances for each arg. You'll also need
> a function to convert that particular ugen to something SC understands.
> My hope is that users can make UGens themselves fairly quickly. Most
> ugens in vivid are defined in a couple of lines, with a standard
> "makeUGen" function.
If there is a uniform internal data structure like Binary or String, you
do not even need a new record type per UGen. If a record is the right
internal structure you might compose records on the fly from bricks like
this:
data Freq more = Freq Double more
data Phase more = Phase Double more
data Empty = Empty
type Osc = Freq (Phase Empty)