Is it a bad idea to include global variables in a module? (suppose the module is not written in functional style) For example: Before using the function in the module, module’s user need to call an initial function.
I wouldn’t say that’s a problem. Especially not if it isn’t really avoidable. I’m sure I have seen plenty of modules/libraries that require a one-off initialisation call at some point.
Just make sure that you clearly state in the documentation that it is necessary, and that errors which arise because someone failed to call the initialisation function explain that was the issue.
> Especially not if it isn’t really avoidable. I’m sure I have seen plenty of modules/libraries that require a one-off initialisation call at some point. @jcoo092 Could you give me an example of that modules/libraries?
Not off the top of my head, no, sorry. At least, not specific examples.
More general examples of when this might happen would be things like where, in order to provide the functionality, a state machine of some sort must be maintained, and so in order to ensure that the state machine starts off correctly an explicit call to the initialisation is required. Or, the functions adapt to some information that can only be determined at runtime, but can be fixed after the start. You’d be especially likely to use the latter when someone may not always want to use the functions every time the program runs, and gathering the information is expensive in some way.
I think there are two ways to work around this problem: 1. Using a lambda to encapsulate states in the closure. This is the best way, if your module has only one public function. 2. Using OOP to encapsulate states in a object, if your module has more than two public functions. The downside of the OOP is that it is not very convenient, because we must pass a object and use keyword send (send my-object method-1) Especially when we need to combine higher order methods.
Ultimately, there’s no One True Way. It really comes down to what’s best in the given circumstance, both in terms of the rest of the module/library, and what is being emphasised. E.g. if easy-to-read-&-maintain code is prioritised, then one approach might be favoured (maybe something about applying higher-order functions to a whole heap of lists), whereas if the best possible performance is required, then maybe some funky stuff that looks completely imperative might be preferred.
That is interesting. I never seem to find a use for do and usually use another mechanism.
Are there any music related Racket packages/#langs?
there’s rs, the Racket Sequencer: https://docs.racket-lang.org/rs/index.html
Apropos do once-upon-a-time (before for-loops), I used do.
https://stackoverflow.com/questions/41086158/what-does-the-do-control-construct-do-in-scheme
Nice SO answer @soegaard2 :slightly_smiling_face:
I used named lets a lot!
but don’t know what state it is in
Ditto.
I got very excited when I saw the sonic-pi one. Looks like the embedded executable does not run properly. I get the following error on start up: started scsynth with process id 6629
Found 0 LADSPA plugins
Number of Devices: 4
0 : "AirPods Pro"
1 : "AirPods Pro"
2 : "Built-in Microph"
3 : "Built-in Output"
input and output sample rates do not match. 16000 != 44100
could not initialize audio. It’s an old repo, so I’m not surprised really.
Anyone know where I can get the code from this talk https://www.youtube.com/watch?v=BDg79CPbdXQ?
There’s Jay’s Bithoven project, which he gave a very good racketcon talk about https://youtu.be/BDg79CPbdXQ\|https://youtu.be/BDg79CPbdXQ
Oh wait I see you already found it
@bzyeung has joined the channel