e ::= v | x | input(p)
| let x = e1 in e2
| (e1, e2)
| unpack e1 as (x1, x2) in e2
| phase(θ, e)
| split(r, e)
| unitary(U, (e1, e2))
| output(p) <- e1; e2
v ::= r ↓ ℝ | p ↓ Port | U ↓ Unitary | ()
τ ::= ℝ | Port | Opt | Unitary | Unit |(τ1 * τ2)
Note that this is not an extension of the pure λ-calculus.
Abstraction (λx.e) and application (f a) are missing,
although the let construct "let x = e1 in e2" is equivalent to their combination
((λx.e2) e1).
The paper has few details on the higher-level specification language in which users specify desired behaviour:
> Specification Language. Specifications are written as relations between input and output ports, expressed using linear expressions. On their own, specifications are not λ _λ programs. It is the job of the synthesizer to find λ _λ programs that realize a given specification. For example, a simple switching behavior can be specified as output[i] = input[j], while a 2x2 AllReduce operation can be written as output[1] = (input[1] + input[2])/sqrt(2) and output[2]= (input[1] - input[2])/sqrt(2).
I am curious why develop a new language instead of building a library for an existing language. What are the benefits as I didn't see this in the paper? Can it interact with other languages?
I understood this language like being something similar to assembly.
Many compiled languages can compile down to assembly and which can be used to debug/optimize/understand the compilation process.
Assembly is so close to the underlying hardware that it's not very practical for us humans to write software with it.
> Can it interact with other languages?
I'd say this is probably similar to the story with assembly. Assembly cannot interop with C. But C can be compiled down to assembly (not sure that counts as "interact" to you).
Well the logical step would be that you are creating a silicon photonics environment that has comparable input and output to the real world (classical computing) which is always into another system to appropriately input, readout, and feedback into the system. Hence why interaction with the languages that readout and input will involve are essential.
The first sentence of the abstract gives a motivation: "λλ uses a linear type system to encode the physical constraints of optics, rejecting unrealizable programs at compile time."
The fact that it its own language does not preclude using it within the context of a different language. You can embed a domain specific language into a general purpose one.
I read that but unless they are able to encode construction, input, output, material, and packaging restraints which I'm not sure this does then I can't see the benefit. It's only ever going to be idealised which are realistically unrealizable.
A key focus of silicon photonics is that it has to interact with classical systems to do readout and input right now so it would be logical to design with that built in.
The second λ is subscripted. As footnote 1 in the paper says:
> Pronounced “lambda lambda”. One λ refers to the λ-calculus and the other refers to an optical wavelength.
Or, in French, Lambdeux.
Ah, the bi-lams.
Full syntax of λλ (from the paper):
Note that this is not an extension of the pure λ-calculus.
Abstraction (λx.e) and application (f a) are missing, although the let construct "let x = e1 in e2" is equivalent to their combination ((λx.e2) e1).
The paper has few details on the higher-level specification language in which users specify desired behaviour:
> Specification Language. Specifications are written as relations between input and output ports, expressed using linear expressions. On their own, specifications are not λ _λ programs. It is the job of the synthesizer to find λ _λ programs that realize a given specification. For example, a simple switching behavior can be specified as output[i] = input[j], while a 2x2 AllReduce operation can be written as output[1] = (input[1] + input[2])/sqrt(2) and output[2]= (input[1] - input[2])/sqrt(2).
So simplified, a bit like System F.
I am curious why develop a new language instead of building a library for an existing language. What are the benefits as I didn't see this in the paper? Can it interact with other languages?
I understood this language like being something similar to assembly.
Many compiled languages can compile down to assembly and which can be used to debug/optimize/understand the compilation process.
Assembly is so close to the underlying hardware that it's not very practical for us humans to write software with it.
> Can it interact with other languages?
I'd say this is probably similar to the story with assembly. Assembly cannot interop with C. But C can be compiled down to assembly (not sure that counts as "interact" to you).
Assembly can totally interop with C.
Well the logical step would be that you are creating a silicon photonics environment that has comparable input and output to the real world (classical computing) which is always into another system to appropriately input, readout, and feedback into the system. Hence why interaction with the languages that readout and input will involve are essential.
The first sentence of the abstract gives a motivation: "λλ uses a linear type system to encode the physical constraints of optics, rejecting unrealizable programs at compile time."
The fact that it its own language does not preclude using it within the context of a different language. You can embed a domain specific language into a general purpose one.
I read that but unless they are able to encode construction, input, output, material, and packaging restraints which I'm not sure this does then I can't see the benefit. It's only ever going to be idealised which are realistically unrealizable.
A key focus of silicon photonics is that it has to interact with classical systems to do readout and input right now so it would be logical to design with that built in.