Command mappings in provided interface implementations

Languages
1

Why can I not do this…

	'Items': collection = (
		'Sales Orders' = $ .'Sales Orders'* as $  (  // <--!
			'Set file': command do on $ ?'Invoice created'|'Processing' ( // <--!!!
				'Add invoice' with (
					'Invoice file': file = @ /'File'
				)
			)
		)
	)

… but should I do this?

	'Items': collection = (
		'Sales Orders' = $ .'Sales Orders'* as $ ?'Invoice created'|'Processing' as $ ( // <--!!!
			'Set file': command do on $ ( // <--!
				'Add invoice' with (
					'Invoice file': file = @ /'File'
				)
			)
		)
	)
2

The two code samples express something very different. In the first example, you express that Sales Orders that you expose via the interface are all Sales Orders from your app. The second example expresses that exposed Sales Orders are those for which ?'Invoice created'|'Processing' holds.

As for why you cannot express:

'Set file': command do on $ ?'Invoice created'|'Processing'

You can already express the filtering above in your application model, so it would just be a second way to express something you can already express. In addition, it would mean that you can express command implementation logic in two different places. Currently, you can only do that in an application model.

The provided interface implementation language aims to be a minimal language specifically tailored to mappings between Alan application-conformant data structures and Alan interface-conformant data structures.

3

Ok, fair enough.
While we’re on the subject of ‘minimal language’, could you explain this notation?

'Items': collection = (
		'Sales Orders' = $ .'Sales Orders'* as $  (
			...
		)
)

Why not write it like this?

'Items': collection = 'Sales Orders' as $ ( 
// interface collection = model collection
	...
)

Or this?

'Items': collection = $ .'Sales Orders'* as $ ( 
// interface collection = path to model collection
	...
)
4

With minimal language I refer to the number of concepts that the language supports; the different possible options that you can choose from. What you suggest with the two alternative formulations is about conciseness of the syntax.

As for conciseness: we plan to support the syntax from your last code sample. (In your penultimate code sample, it is unclear where 'Sales Orders' comes from.)

5

Maybe what is missing here is the explanation for why the syntax currently is the way it is. The fact is that this syntax is prepared for having multiple branches of entries in that collection. For instance, when providing information about ‘Resources’ to a generic planning tool, you could combine ‘Machines’ and ‘Employees’ from your application model. The language will require you to specify unique prefixes and a character to join the keys to make sure the resulting entry id’s are unique.