Soul syntax

1

I’m finally starting to play a bit with soul :smiley:
a couple of questions :

  • I’m not sure why the following won’t compile for processor state variables?

      int[4] myArray;
  let x = myArray[0];     // error : Found an expression when expecting a constant
  let y = myArray.at (0); // error : Found an expression when expecting a constant

  • any plan to support that?
    float<> values = (1.f, 2.f, 3.f, 4.f);

  • I’m also curious if the following will be allowed in the future:

      let
  {
      x = 1.0;
      y = 1.0;
  }

  var
  {
      a = 1;
      b = 2;
  }
2

Hmm, I created a test for that, but can’t make it fail… Could be something we already fixed (we’ll have a new version out very soon)

Can you share a whole program that fails?

3

Re: the nested let syntax… I can’t really see the point, TBH.

Why would

  let
  {
      x = 1.0;
      y = 1.0;
  }

be better than

  let x = 1.0,
      y = 1.0;

?

Also don’t really want to have syntax that encourages big lists of named variables at the top of a scope, when you really want fewer variables and for them to be declared in the smallest necessary scope.

4

Probably not… We do have unsized arrays with that syntax, but vectors are more primitive and I have a gut feeling that allowing it for vectors would be somehow a Bad Thing.

5 
processor Test
{
    output stream float audioOut;

    int[4] myArray;
    let x = myArray[0];
    let y = myArray.at (0);

    void run()
    {
        advance();
    }
}

the nested let syntax: I don’t want it, I was just curious about it, cause the following is allowed :

let
{
    processorA = MyProcessor;
    processorB = MyProcessor;
    processorC = MyProcessor;
}

So it would have been coherent to have it for primitive types and I was expecting it.

6

oh, yeah, it doesn’t allow state variables to be initialised using bits of other ones (to prevent recursive order of evaluation problems, etc). If you need to do that, you can just set up any values you need at the start of your run() function.

Yep, I understand what you’re saying about the nested let syntax, but it felt to us that it fitted into a graph where the whole thing is a big set of declarations, whereas in a processor it’s more procedural and less relevant. But hey, it’d be trivial to add, maybe one day we will. However, our whole approach is to be ultra-conservative about syntax because it’s easy to add, but hard to take it away.

2 Likes