Looks like let is even stricter than variable declarations in other languages, which is probably not a bad thing. Generally, shadowing should be avoided.
I donāt think we have any obligation to support obscurantist corner cases. Iād vote no on hoisting.
No one argued for hoisting! The example demonstrates shadowing. Itās just a quirk of JS that it decides to hoist the second variable declaration to the top of the block.
Note that sclang does allow variable shadowing. Confusing situations like above just donāt occur because variables can only be declared at the top. Once this restriction is lifted, the ācorner caseā above would just be a natural result of the scoping rules. You could make it a syntax error, but it probably takes extra work.
Needless to say, variable shadowing is confusing and error prone and should be avoided in the first place.
Oh ok, sorry for confusion over terminology.
Now that I check the definition of hoisting, I have to change my comment, then.
A sensible rule is, if a function scope declares x, then within that scope, x has one and only one referent. In Rohanās example, the assignment to x before var x has a different referent. This, I think, we could legitimately disallow.
Perhaps better than hoisting would be to produce a syntax error if there is a declaration of an identifier after the first use of the identifier within the block.
I vaguely recall SC allows this; I think it shouldnāt.
f = {
var a = 10.rand + x;
var x = 50;
a
};
But of course this is not to be encouraged.
hjh
Agreed.
Perhaps better than hoisting
Anything is better than hoisting 
I vaguely recall SC allows this; I think it shouldnāt.
f = {
var a = 10.rand + x;
var x = 50;
a
};
Wow, this is terrible 
Curiously, it seems to only work if the hoisted variable is assigned to a constant value:
f = {
var a = 10.rand + x;
var x = 50 + 10;
a
}
f.value;
I think this āfeatureā is really just a bug in the parser.
Be aware that this author, then, could be Microsoft or Apple or Steinberg. If itās an open licensing model, then it becomes much more difficult to prevent a commercial entity from appropriating our communityās gratis development labor and perhaps applying āembrace extend extinguishā to it. The latter is a hypothetical worst case that probably would never happen, but with GPL, it canāt happen (at least not without a fight from the Free Software Foundation).
At the time SC Server was being released under GPL, its up-to-then sole author James McCartney was preparing to take a job at Apple. One of the terms of Appleās employment contract is that all software developed independently while employed at Apple becomes the property of Apple. Imagine: No Linux or Windows versions. $300 for a single user license (or a free edition with limited features). You might be able to develop Mac apps in it but at the loss of freedom. Now, you could blame GPL for preventing app development in SC, but you could also blame Apple for making it attractive to apply GPL at all (but the last few comments on licensing didnāt consider that 
).
Be that as it may: I doubt JMc would consent to relicense his source code under a scheme that is friendlier to closed-source app development. So āopen licensingā requires effectively a ground-up total rewrite, with clean room isolation from the original code base. Thatās not impossible but itās a huge undertaking. (āOuchā? But big chunks of SC do consist of JMcās work, years of it. I think thereās an ethical problem if the SC community said, effectively, āWell itās ours nowā and went against his wishes as expressed in the GPL preamble).
hjh
2 Likes
A thousand times this. Thank you for saying so.
The example demonstrates shadowing.
Yes, in relation to making this efficient, and that some implementations are quite strange.
Iād imagined SuperCollider doing something like:
{var x; x = 0; var y = 1; x + y} => {var x; x = 0; {var y = 1; x + y}.value}
and then analysing it to know if it was safe to delete the inner function.
It seemed like quite a bit of work, and I was just curious if it was worth it.
Iām very happy to know itās actually straightforwards!
Best,
Rohan
Ps. Thereās this (very old!) issue about possibly useful interpreter warnings, including shadowing.
https://github.com/supercollider/supercollider/issues/923
Pps. Also (and obliquely related to Lua) the commentary at https://github.com/rochus-keller/Smalltalk has some interesting notes about implementing Smalltalk like interpreters, ie. āFinal conclusion December 2020ā.
{var a = 10.rand + x; var x = 50; a}
Very nice knowledge!
Of course this looks completely normal as Haskell!
let {a = 10 + x;x = 50} in a
Best,
Rohan
The reason why it (ahem) āworksā is because vars initialized to literals save the initial value in the functionās prototypeFrame, so they are available from the beginning of the functionās execution. Initializing to an expression requires evaluating the expression, which of course doesnāt happen until the interpreter reaches the expressionās bytecodes (so the result is not available at the start of the function.
Not really a parser bug ā a side effect of the design of execution frames.
hjh
2 Likes
Thanks for the explanation! Makes sense.
I think thereās a way to make SC4 a strong realityā¦ which seems very difficult, considering many conflicts of interest.
Here is the top ten list of most frequently answered āpain pointsā from the most recent survey, most of them are related:
- Documentation is missing / unclear
- Tutorial materials are missing / unclear
- Debugging is difficult
- Errors messages confusing
- sclang syntax is difficult
- making GUIās is difficult
- ā¦too many ways of doing things
ā¦and so with so many ideas contributing to the same idea pool, it seems the language has become to an extent scattered and disorganized.
Iāve been thinking of the possibility of organizing SCās reference source into 4/5 main sectionsā¦ something like:
Client Server Guides Extensions
ā¦with perhaps GUI being the fifth, or perhaps as a client abstraction.
Guides would be reserved for reference material to cross boundaries, as well as introductory material.
Each one of the four, five, or six Main sections would then have a limited number of sub-sections (abstractions like Collections, Streams, Ugens, JITLib, etc.) ā¦and each sub-section would most likely end with itās own dedicated tutorial, and itās class reference.
Itās just an ideaā¦ to keep everything organized would make it easier for everyone when trying to meet a specific intent, as well as for building extensions that fit in well with the rest of the language.
1 Like
There is definitely something that we can do to improve the state of SuperColliderās documentation. I guess that it is not necessary to wait for SuperCollider 4 to start the work on this aspect. I suppose that many wouldnāt object to a refactoring, because it is slightly less political than licensing or organization. The actual documentation is really good but nowadays it feels like something that grew organically to the point of being too scaterred (Iām pretty sure that this is what happened).
I would love to spend some time improving the documentation but I donāt really understand how to collaborate and how the development team is organized. I have a lot of time to devote to this task if needed. I would be greateful if someone is available to help me and explain how to contribute (DM or mail). Although it is difficult for many to make a relevant contribution to the improvement of the audio engine or the language, I am convinced that it is possible for a large number of users to share their knowledge and skills to restructure the documentation.
One way to start would be to encourage people to contribute by providing guided steps or some sort of āfirst contribution tutorialā.
This might temporarily bring unstability to the structure / content of the documentation, but I am sure that it will ultimately lead to something nice, clean and more actual. Itās not clear how a transition from the classic documentation to the new documentation would take place but this is something that can be done, maybe by providing the two versions until one is visibly preferred to the other.
Anyway, I enjoy working on docs, so please contact me if you are willing to talk about this. I already refactored the Tidalcycles docs recently, and it was really a nice project to undertake!
1 Like
Alternate view: Perhaps we donāt need to remove ways of doing things, but rather start documenting best practices.
-
Current situation: Here are 8 ways to do x. 5 are terrible; 2 are ok; 1 is really good. You guess which is which.
-
Better situation: This is the best way to do x. (And hereās one alternative.)
Then refactor the docs to steer users toward best practices docs.
We like writing class documentation (which is necessary). The idea of writing mid-level documentation hasnāt gained as much traction. Max/MSP has done a great job of shipping intermediate/advanced topic-focused tutorials. We havenāt (except for the Practical Guide to Patterns, but even this in hindsight is less topic-driven than it could be), and I think this contributes to that ālost at seaā feeling. We tell you that thereās a Starbucks on the corner, but we donāt tell you how it relates to other shops on other corners and how to get there.
I think this is really the first step. Some useful topics:
- Basic synthesis technique cookbook. (We donāt need to replicate the Computer Music Tutorial, just provide templates for basic subtractive, FM, waveshaping, etc synths).
- Effects (how to write standard studio fx; best practices for managing fx buses and node order).
- Time and tempo, quant factors, sequencing.
- Cool things to do with buffers.
- Responding to external input (basic concepts of UI callbacks that apply to GUI widgets, MIDI, OSC, and HID). Especially the idea of the callback updating a model only, and active tasks refer to the model. Everybody gets stuck on this ā because the class interfaces by themselves lead users toward a weaker design, but nowhere do we suggest better designs.
- Specifics for GUI.
- Specifics for MIDI.
- ā¦ for OSC etc.
hjh
4 Likes
Iāve been thinking about a quark that would help us contribute to the documentationā¦
ā¦allowing you to edit the help source āin-placeāā¦ & with a simple edit | preview split view along with a drop-down menu for āclick-to-addā instances of schelp markdown syntax.
ā¦ and git integration under the hood (perhaps a dedicated branch for doc-only updatesā¦) and a Submit button over the hood, and Iām sure A LOT of us would be able to contribute.
Currently thereās 2502 documents across 37 sectionsā¦ with around 14-16 sections having only 5 entries or less.
Thereās 6 classes or document typesā¦ one of them (Other) applies to only one documentā¦ and at a glance Tutorial Reference Overview & Guide could all easily refer to the same kind of content.
If the core reference is well organizedā¦ then thereās far more room for all of those interesting things @jamshark70 is already brainstormingā¦ things like that are sorely missed from the current reference.
Is it possible that we could build something that would speed up a common workflow?
1 Like
That got me thinkingā¦ POC of simplified responders
hjh
Cycling74 did something clever. They acknowledged the fact that help and reference are not the same thing and they introduced two different kind of help documents. They also introduced built-in tutorials, demo patches, and many many things that are only shipped with the software because it demonstrates what good practices are.
Iām not entirely convinced, but I still agree with your plan. A first clean-up phase is really important, and I agree with @Rainer, there are too many sections and the documentation has succumbed to entropy. The actual reference is the low-level documentation, so it should be sane before building something else on the top of it.
I think that this is simply too much work to add on the devs shoulders, at least for the beginning. There is no need to wait for a system if the job can be done manually. In the near future, I guess that a simplification in the contribution workflow would be welcome, but Iām not sure how it could work because I donāt really know how the dev team would think / implement something like this.
I could have made this more clear:
The editor can be built as a script written in pure supercollider, and then run inside the scide.
Thereās only four features: edit, preview, add syntax, and submit.
A very rough and quick draft, for the sake of demonstration:
- Edit : Use Documentās robust interface.
- Preview: use classes ScDocEntry and HelpBrowser, have a full local copy of help source for work, (use PathName & File to clone a local working directory) ā¦have the preview update every 1-2 seconds using a SkipJack, or use Document.globalKeyDownAction_ to constantly update changes made to the in-edit copy, perhapsā¦
- Add syntax: At first, a cheat sheet using copy & paste is half-way thereā¦ or good enough for pre-alpha
- Submit: The most basic operation would be just like any normal git pull requestā¦ But ideally, you could update and submit as many times as you wanted to, and all of the updates would then be merged or managed by git somehowā¦ The devs would be able to view all of the doc changes at once and at their convenience, and perhaps requiring a separate ādevelop-referenceā branch, if it would be sensible to do so.
Documentation seems to be a thing when reading this topic indeed.
One small addition to this from my side: there are quite some nice tutorials or learning SC especially from @elifieldsteel. What might be missing in this realm are clear instructions on the language itself. How to program in SC. What are the base principles. How to write functions, lists, arrays etc and how to use itās syntax.
Hello,
Iāve been working for a while now on a drop-in replacement for sclang called Hadron. Hadron is a complete rewrite for sclang and is designed as a JIT compiler.
I originally started it over a year ago mainly as a way to teach myself more about compilers by working on a non-trivial project. I took a long break due to personal reasons, but have recently been working on it consistently. Iāve been having a lot of fun defining the basic architecture and building (and re-building) some of the fundamental components of the compiler.
Iām not ready to accept contributions to either the design or code, but as the project has started to take shape itās made me wonder if it could be useful to the SC community. A friend called my attention to this thread (I normally lurk on Discord and Slack and only rarely browse this forum), and I thought it might be time to say hello.
My plan is to work on Hadron independently until enough of the design is established and the test infrastructure is in place that I could invite contributions from other folks. I would estimate this will take another 6 months of work at least. If you have questions about Hadron I would first invite you to read through some of the requirements and other documentation in the docs/ directory in the Hadron repository. Thatās the best place to track the development of the project as well. I have limited time to respond to online communications here so apologies in advance if thereās a long delay in responses.
My goal of communicating about Hadron now is mostly to reduce the chances of duplicate effort. If youāve been working in secret on a JIT compiler replacement for sclang please do get in touch, perhaps we can join forces!
Cheers!
8 Likes
Love the sound of it.
1 Like