Most of the time when we use call we feed it pathnames. Pathnames that we create inside Red and that follow Red (to-red-file) semantics. So almost every call requires converting all these pathnames with to-local-file into OS semantics. Now, there's almost zero value of passing Red file to call, so why on earth are we doing it manually all the time?! In short file management scripts it becomes quite repetitive.
Naturally, the solution is that call should convert each file! value into OS semantics. But it only receives the final string, so we should extend it by allowing it to receive a block to rejoin.
However, rejoin-based call-expressions are rather unreadable: see red/red#5085 . So for any reasonable result, call should receive a template string, which it should:
- Parse into a rejoin-expression
- Reduce it
- Convert
file! values in it with to-local-file
- Join the result and do an OS call
In short: call join convert reduce unpack "template".
There are few ways of doing that:
A. Letting call accept yet another refinement that will tell it that the string is a template
B. Using a #call macro based on string-interpolation
C. Having a language support for string interpolation and template strings, so there will be no ambiguity
Note that (B) falls short a bit: it cannot dispatch into #rejoin (topic of PR 5085) directly, it has to insert conversion(3) phase between the reduction(2) and joining(4).
Another request I have is to add a refinement that will throw an error when the call result is non-zero. Because otherwise this always has to be done manually anyway, to show the user that something bad has happened. Or it can be the default, while a refinement may muffle it and return the code.
Most of the time when we use
callwe feed it pathnames. Pathnames that we create inside Red and that follow Red (to-red-file) semantics. So almost everycallrequires converting all these pathnames withto-local-fileinto OS semantics. Now, there's almost zero value of passing Red file tocall, so why on earth are we doing it manually all the time?! In short file management scripts it becomes quite repetitive.Naturally, the solution is that
callshould convert eachfile!value into OS semantics. But it only receives the final string, so we should extend it by allowing it to receive a block to rejoin.However, rejoin-based call-expressions are rather unreadable: see red/red#5085 . So for any reasonable result,
callshould receive a template string, which it should:file!values in it withto-local-fileIn short:
call join convert reduce unpack "template".There are few ways of doing that:
A. Letting
callaccept yet another refinement that will tell it that the string is a templateB. Using a
#callmacro based on string-interpolationC. Having a language support for string interpolation and template strings, so there will be no ambiguity
Note that (B) falls short a bit: it cannot dispatch into
#rejoin(topic of PR 5085) directly, it has to insert conversion(3) phase between the reduction(2) and joining(4).Another request I have is to add a refinement that will throw an error when the call result is non-zero. Because otherwise this always has to be done manually anyway, to show the user that something bad has happened. Or it can be the default, while a refinement may muffle it and return the code.