Re: My point about variables -- interesting side-effect

I think the confusion revolves around the fact that we have yet to
decide the divide between variables and ports.

My personal preference is to model everything internally as a function
which gives us deferred processing and a lot of flexibility:

I wonder if we could decide that

-> is a promise and >> means to atomise down to value

this then allows for both constructions, where

      [ $stdin, $stylesheet ] -> mystep() -> $result

sets $result to contain a function that when invoked returns the value
(but does not give it a name)

eg. doing $result() invokes (like a step no?)

and

[ $stdin, $stylesheet ] -> mystep() >> $result

where >> is equal to $result() and placing the value into variable $result.

this 'collapsing' has implications in terms of streaming, etc but it
seems to follow our current set of assumptions.

thoughts ?

J

On 20 April 2016 at 20:16, Murray Maloney <murray@muzmo.com> wrote:
> Sorry I missed today’s call. We were celebrating.
>
>> On Apr 20, 2016, at 2:25 PM, Henry S. Thompson <ht@inf.ed.ac.uk> wrote:
>>
>> If my way of thinking of variables as having an input port and an output
>> port, i.e. as a way of giving a pipe of flowing data a name for later
>> reuse, then it becomes a lightweight way of specifying the identity step.
>>
>> That is, I claim that
>>
>> ... -> ...
>>
>> is equivalent to
>>
>> ... -> identity() -> ...
>>
>> is equivalent to
>>
>> ... >> $foo
>> [$foo] -> ...
>>
>> with an added name for later reuse.
>
> FWIW, I agree with Henry, intuitively. I might add that there is cost associated with instantiating $foo.
>
>>
>> Which brings me back to thinking that the -> vs. >> distinction is
>> misleading at best, and I should just be able to write
>>
>> ... -> $foo -> …
>
> Yes, just so. And why isn’t it > instead of ->? And why don’t we call stdin, $stdin, and use ‘-‘ as shorthand?
>
>         [ $stdin, $stylesheet ]
>         [ -, $stylesheet ]
>
> I find >> confusing again. The >> operator has always meant that the left side would be appended (added to at its endpoint) to whatever was already present in the file, as opposed to the > operator which just steps on the previous contents of the right hand side (re-initializes the file and then appends).
>
> The proposed use of >> does not ‘append’ so much as it just throws the left side into a bag on the right side.
>
> So, in this processing context in which there is no sense of order, where chain sequences ‘append’ results onto a URI in timeless harmony, the >> really means ’throw into bag’ named by the URI, where; the bag may have other content, and the order of top-level content is indeterminate. So, we can only create unordered lists of documents with the >> operator, is that correct? (I can see the value in being able to rapidly create, use, and destroy document universes.)
>
> How does one create ordered lists of documents? Is there a convenient operator to perform file append, in the classic sense?
>
>
>
>

Received on Wednesday, 20 April 2016 19:48:36 UTC