The Inbox: Collections-ul.564.mcz

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
14 messages Options
Reply | Threaded
Open this post in threaded view
|

The Inbox: Collections-ul.564.mcz

commits-2
A new version of Collections was added to project The Inbox:
http://source.squeak.org/inbox/Collections-ul.564.mcz

==================== Summary ====================

Name: Collections-ul.564
Author: ul
Time: 3 February 2014, 2:35:36.802 pm
UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
Ancestors: Collections-ul.563

Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.

=============== Diff against Collections-ul.563 ===============

Item was changed:
  ----- Method: Array>>isLiteral (in category 'testing') -----
  isLiteral
+
+ ^self class == Array and: [
+ self isLiteralIfContainedBy: IdentitySet new ]!
- ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!

Item was added:
+ ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
+ isLiteralIfContainedBy: parents
+ " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
+
+ (parents includes: self) ifTrue: [ ^false ].
+ parents add: self.
+ 1 to: self size do: [ :index |
+ | element |
+ element := self at: index.
+ (element class == Array
+ ifTrue: [ element isLiteralIfContainedBy: parents ]
+ ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
+ parents remove: self.
+ ^true!


Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Frank Shearar-3
On 3 February 2014 13:48,  <[hidden email]> wrote:

> A new version of Collections was added to project The Inbox:
> http://source.squeak.org/inbox/Collections-ul.564.mcz
>
> ==================== Summary ====================
>
> Name: Collections-ul.564
> Author: ul
> Time: 3 February 2014, 2:35:36.802 pm
> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
> Ancestors: Collections-ul.563
>
> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>
> =============== Diff against Collections-ul.563 ===============
>
> Item was changed:
>   ----- Method: Array>>isLiteral (in category 'testing') -----
>   isLiteral
> +
> +       ^self class == Array and: [
> +               self isLiteralIfContainedBy: IdentitySet new ]!
> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>
> Item was added:
> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
> + isLiteralIfContainedBy: parents
> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
> +
> +       (parents includes: self) ifTrue: [ ^false ].
> +       parents add: self.
> +       1 to: self size do: [ :index |
> +               | element |
> +               element := self at: index.
> +               (element class == Array
> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
> +       parents remove: self.
> +       ^true!

So this is a basic depth first traversal with cycle protection, yes?
(This pattern seems to crop up _a lot_. Maybe it's worth pulling out
as a separate algorithm?)

frank

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Tobias Pape
On 03.02.2014, at 15:28, Frank Shearar <[hidden email]> wrote:

> On 3 February 2014 13:48,  <[hidden email]> wrote:
>> A new version of Collections was added to project The Inbox:
>> http://source.squeak.org/inbox/Collections-ul.564.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Collections-ul.564
>> Author: ul
>> Time: 3 February 2014, 2:35:36.802 pm
>> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
>> Ancestors: Collections-ul.563
>>
>> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>>
>> =============== Diff against Collections-ul.563 ===============
>>
>> Item was changed:
>>  ----- Method: Array>>isLiteral (in category 'testing') -----
>>  isLiteral
>> +
>> +       ^self class == Array and: [
>> +               self isLiteralIfContainedBy: IdentitySet new ]!
>> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>>
>> Item was added:
>> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
>> + isLiteralIfContainedBy: parents
>> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
>> +
>> +       (parents includes: self) ifTrue: [ ^false ].
>> +       parents add: self.
>> +       1 to: self size do: [ :index |
>> +               | element |
>> +               element := self at: index.
>> +               (element class == Array
>> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
>> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
>> +       parents remove: self.
>> +       ^true!
>
> So this is a basic depth first traversal with cycle protection, yes?
> (This pattern seems to crop up _a lot_. Maybe it's worth pulling out
> as a separate algorithm?)
Well, there are two such applications:
One with an explicit down-handling of a variable (like this)
and one with an implicit variable (semi-global)
        (Dynamic variable, probably, at least thread-local)

I would like to have both.
I propose the (seaside-inspired) #use:during: message for the second.

However I cannot imagine a generic message for the first variant.

Best
        -Tobias





signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Frank Shearar-3
On 3 February 2014 14:49, Tobias Pape <[hidden email]> wrote:

> On 03.02.2014, at 15:28, Frank Shearar <[hidden email]> wrote:
>
>> On 3 February 2014 13:48,  <[hidden email]> wrote:
>>> A new version of Collections was added to project The Inbox:
>>> http://source.squeak.org/inbox/Collections-ul.564.mcz
>>>
>>> ==================== Summary ====================
>>>
>>> Name: Collections-ul.564
>>> Author: ul
>>> Time: 3 February 2014, 2:35:36.802 pm
>>> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
>>> Ancestors: Collections-ul.563
>>>
>>> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>>>
>>> =============== Diff against Collections-ul.563 ===============
>>>
>>> Item was changed:
>>>  ----- Method: Array>>isLiteral (in category 'testing') -----
>>>  isLiteral
>>> +
>>> +       ^self class == Array and: [
>>> +               self isLiteralIfContainedBy: IdentitySet new ]!
>>> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>>>
>>> Item was added:
>>> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
>>> + isLiteralIfContainedBy: parents
>>> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
>>> +
>>> +       (parents includes: self) ifTrue: [ ^false ].
>>> +       parents add: self.
>>> +       1 to: self size do: [ :index |
>>> +               | element |
>>> +               element := self at: index.
>>> +               (element class == Array
>>> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
>>> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
>>> +       parents remove: self.
>>> +       ^true!
>>
>> So this is a basic depth first traversal with cycle protection, yes?
>> (This pattern seems to crop up _a lot_. Maybe it's worth pulling out
>> as a separate algorithm?)
>
> Well, there are two such applications:
> One with an explicit down-handling of a variable (like this)
> and one with an implicit variable (semi-global)
>         (Dynamic variable, probably, at least thread-local)
>
> I would like to have both.
> I propose the (seaside-inspired) #use:during: message for the second.

Except that DynamicVariable's #use:during: is incompatible with
stack-slicing, because those kinds of dynamic variables aren't
delimited. (Unlike resumable exceptions, for instance.)

> However I cannot imagine a generic message for the first variant.

myArray depthFirstDo: [:each | each doSomething] havingVisited:
IdentitySet new ?

frank

> Best
>         -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Tobias Pape
On 03.02.2014, at 16:01, Frank Shearar <[hidden email]> wrote:

> On 3 February 2014 14:49, Tobias Pape <[hidden email]> wrote:
>> On 03.02.2014, at 15:28, Frank Shearar <[hidden email]> wrote:
>>
>>> On 3 February 2014 13:48,  <[hidden email]> wrote:
>>>> A new version of Collections was added to project The Inbox:
>>>> http://source.squeak.org/inbox/Collections-ul.564.mcz
>>>>
>>>> ==================== Summary ====================
>>>>
>>>> Name: Collections-ul.564
>>>> Author: ul
>>>> Time: 3 February 2014, 2:35:36.802 pm
>>>> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
>>>> Ancestors: Collections-ul.563
>>>>
>>>> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>>>>
>>>> =============== Diff against Collections-ul.563 ===============
>>>>
>>>> Item was changed:
>>>> ----- Method: Array>>isLiteral (in category 'testing') -----
>>>> isLiteral
>>>> +
>>>> +       ^self class == Array and: [
>>>> +               self isLiteralIfContainedBy: IdentitySet new ]!
>>>> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>>>>
>>>> Item was added:
>>>> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
>>>> + isLiteralIfContainedBy: parents
>>>> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
>>>> +
>>>> +       (parents includes: self) ifTrue: [ ^false ].
>>>> +       parents add: self.
>>>> +       1 to: self size do: [ :index |
>>>> +               | element |
>>>> +               element := self at: index.
>>>> +               (element class == Array
>>>> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
>>>> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
>>>> +       parents remove: self.
>>>> +       ^true!
>>>
>>> So this is a basic depth first traversal with cycle protection, yes?
>>> (This pattern seems to crop up _a lot_. Maybe it's worth pulling out
>>> as a separate algorithm?)
>>
>> Well, there are two such applications:
>> One with an explicit down-handling of a variable (like this)
>> and one with an implicit variable (semi-global)
>>        (Dynamic variable, probably, at least thread-local)
>>
>> I would like to have both.
>> I propose the (seaside-inspired) #use:during: message for the second.
>
> Except that DynamicVariable's #use:during: is incompatible with
> stack-slicing, because those kinds of dynamic variables aren't
> delimited. (Unlike resumable exceptions, for instance.
Sorry, I (currently) don’t know what you mean by stack-slicing.
Are we speaking of Martin von Löwis’ DynamicVariables currently in 4.5/trunk
that are based on Thread-local storage
or the Seaside ones based on Exceptions?

(I just see that DV is using #value:during: rather than #use:during:
the former is consistent while the latter IMHO speaks better)


>> However I cannot imagine a generic message for the first variant.
>
> myArray depthFirstDo: [:each | each doSomething] havingVisited:
> IdentitySet new ?

Sounds squeakish :)

Best
        -Tobias



signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Frank Shearar-3
On 3 February 2014 15:06, Tobias Pape <[hidden email]> wrote:

> On 03.02.2014, at 16:01, Frank Shearar <[hidden email]> wrote:
>
>> On 3 February 2014 14:49, Tobias Pape <[hidden email]> wrote:
>>> On 03.02.2014, at 15:28, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 3 February 2014 13:48,  <[hidden email]> wrote:
>>>>> A new version of Collections was added to project The Inbox:
>>>>> http://source.squeak.org/inbox/Collections-ul.564.mcz
>>>>>
>>>>> ==================== Summary ====================
>>>>>
>>>>> Name: Collections-ul.564
>>>>> Author: ul
>>>>> Time: 3 February 2014, 2:35:36.802 pm
>>>>> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
>>>>> Ancestors: Collections-ul.563
>>>>>
>>>>> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>>>>>
>>>>> =============== Diff against Collections-ul.563 ===============
>>>>>
>>>>> Item was changed:
>>>>> ----- Method: Array>>isLiteral (in category 'testing') -----
>>>>> isLiteral
>>>>> +
>>>>> +       ^self class == Array and: [
>>>>> +               self isLiteralIfContainedBy: IdentitySet new ]!
>>>>> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>>>>>
>>>>> Item was added:
>>>>> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
>>>>> + isLiteralIfContainedBy: parents
>>>>> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
>>>>> +
>>>>> +       (parents includes: self) ifTrue: [ ^false ].
>>>>> +       parents add: self.
>>>>> +       1 to: self size do: [ :index |
>>>>> +               | element |
>>>>> +               element := self at: index.
>>>>> +               (element class == Array
>>>>> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
>>>>> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
>>>>> +       parents remove: self.
>>>>> +       ^true!
>>>>
>>>> So this is a basic depth first traversal with cycle protection, yes?
>>>> (This pattern seems to crop up _a lot_. Maybe it's worth pulling out
>>>> as a separate algorithm?)
>>>
>>> Well, there are two such applications:
>>> One with an explicit down-handling of a variable (like this)
>>> and one with an implicit variable (semi-global)
>>>        (Dynamic variable, probably, at least thread-local)
>>>
>>> I would like to have both.
>>> I propose the (seaside-inspired) #use:during: message for the second.
>>
>> Except that DynamicVariable's #use:during: is incompatible with
>> stack-slicing, because those kinds of dynamic variables aren't
>> delimited. (Unlike resumable exceptions, for instance.
>
> Sorry, I (currently) don’t know what you mean by stack-slicing.
> Are we speaking of Martin von Löwis’ DynamicVariables currently in 4.5/trunk
> that are based on Thread-local storage
> or the Seaside ones based on Exceptions?

Ah! I thought that the Seaside ones were the same the DynamicVariable in trunk!

> (I just see that DV is using #value:during: rather than #use:during:
> the former is consistent while the latter IMHO speaks better)

Right. So if Seaside's version uses resumable exceptions, there's no trouble.

By "stack-slicing" I mean tricks like using delimited continuations.
Oleg Kiselyov demonstrated [1] how, since there are multiple
reasonable ways of using delimited control and dynamic bindings
(trunk's DynamicVariable) together, that there were therefore _no_
reasonable ways of combining them. Dynamic bindings either capture too
much or too little of the environment. The answer is to _delimit_ the
dynamic bindings. Handily, that's exactly what we have with resumable
exceptions + #on:do:.

[1] http://www.cs.indiana.edu/~sabry/papers/delim-dyn-bind.pdf

frank

>>> However I cannot imagine a generic message for the first variant.
>>
>> myArray depthFirstDo: [:each | each doSomething] havingVisited:
>> IdentitySet new ?
>
> Sounds squeakish :)
>
> Best
>         -Tobias

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Chris Muller-3
In reply to this post by commits-2
I guess there's infinite recursion in Array's printing method too...

An Array containing itself?  Obviously that's a rare structure the
system has never dealt with.

Do you think there'll be any other traversing methods that might be affected?

On Mon, Feb 3, 2014 at 7:48 AM,  <[hidden email]> wrote:

> A new version of Collections was added to project The Inbox:
> http://source.squeak.org/inbox/Collections-ul.564.mcz
>
> ==================== Summary ====================
>
> Name: Collections-ul.564
> Author: ul
> Time: 3 February 2014, 2:35:36.802 pm
> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
> Ancestors: Collections-ul.563
>
> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>
> =============== Diff against Collections-ul.563 ===============
>
> Item was changed:
>   ----- Method: Array>>isLiteral (in category 'testing') -----
>   isLiteral
> +
> +       ^self class == Array and: [
> +               self isLiteralIfContainedBy: IdentitySet new ]!
> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>
> Item was added:
> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
> + isLiteralIfContainedBy: parents
> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
> +
> +       (parents includes: self) ifTrue: [ ^false ].
> +       parents add: self.
> +       1 to: self size do: [ :index |
> +               | element |
> +               element := self at: index.
> +               (element class == Array
> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
> +       parents remove: self.
> +       ^true!
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Tobias Pape
In reply to this post by Frank Shearar-3
On 03.02.2014, at 16:14, Frank Shearar <[hidden email]> wrote:

> On 3 February 2014 15:06, Tobias Pape <[hidden email]> wrote:
>> On 03.02.2014, at 16:01, Frank Shearar <[hidden email]> wrote:
>>
>>> On 3 February 2014 14:49, Tobias Pape <[hidden email]> wrote:
>>>> On 03.02.2014, at 15:28, Frank Shearar <[hidden email]> wrote:
>>>>
>>>>> On 3 February 2014 13:48,  <[hidden email]> wrote:
>>>>>
>>>>> So this is a basic depth first traversal with cycle protection, yes?
>>>>> (This pattern seems to crop up _a lot_. Maybe it's worth pulling out
>>>>> as a separate algorithm?)
>>>>
>>>> Well, there are two such applications:
>>>> One with an explicit down-handling of a variable (like this)
>>>> and one with an implicit variable (semi-global)
>>>>       (Dynamic variable, probably, at least thread-local)
>>>>
>>>> I would like to have both.
>>>> I propose the (seaside-inspired) #use:during: message for the second.
>>>
>>> Except that DynamicVariable's #use:during: is incompatible with
>>> stack-slicing, because those kinds of dynamic variables aren't
>>> delimited. (Unlike resumable exceptions, for instance.
>>
>> Sorry, I (currently) don’t know what you mean by stack-slicing.
>> Are we speaking of Martin von Löwis’ DynamicVariables currently in 4.5/trunk
>> that are based on Thread-local storage
>> or the Seaside ones based on Exceptions?
>
> Ah! I thought that the Seaside ones were the same the DynamicVariable in trunk!
No; the trunk ones should be better, performance-wise, since they don’t
have to walk the stack on #value

>> (I just see that DV is using #value:during: rather than #use:during:
>> the former is consistent while the latter IMHO speaks better)
>
> Right. So if Seaside's version uses resumable exceptions, there's no trouble.
>
> By "stack-slicing" I mean tricks like using delimited continuations.
> Oleg Kiselyov demonstrated [1] how, since there are multiple
> reasonable ways of using delimited control and dynamic bindings
> (trunk's DynamicVariable) together, that there were therefore _no_
> reasonable ways of combining them. Dynamic bindings either capture too
> much or too little of the environment. The answer is to _delimit_ the
> dynamic bindings. Handily, that's exactly what we have with resumable
> exceptions + #on:do:.
> [1] http://www.cs.indiana.edu/~sabry/papers/delim-dyn-bind.pdf
Yes, but I think that is more of concern for continuations than for
dynamically scoped variables, no? Aren’t those by definition delimitted?

Best
        -Tobias



signature.asc (1K) Download Attachment
Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Levente Uzonyi-2
In reply to this post by Chris Muller-3
On Mon, 3 Feb 2014, Chris Muller wrote:

> I guess there's infinite recursion in Array's printing method too...
>
> An Array containing itself?  Obviously that's a rare structure the
> system has never dealt with.

Not really. We already have #shouldBePrintedAsLiteral which handles
recursive array structures the same way the code I just uploaded does.

And we have Object >> #printString, which limits the length of the
returned string to 50000 characters.

>
> Do you think there'll be any other traversing methods that might be affected?

Definitely. One example is #includes:.


Levente

>
> On Mon, Feb 3, 2014 at 7:48 AM,  <[hidden email]> wrote:
>> A new version of Collections was added to project The Inbox:
>> http://source.squeak.org/inbox/Collections-ul.564.mcz
>>
>> ==================== Summary ====================
>>
>> Name: Collections-ul.564
>> Author: ul
>> Time: 3 February 2014, 2:35:36.802 pm
>> UUID: 4b9a37ef-df86-40a0-a0dd-8e8b2c04d4ed
>> Ancestors: Collections-ul.563
>>
>> Make sure that Array >> #isLiteral won't get into an infinite recursion, even if the receiver has an recursive structure.
>>
>> =============== Diff against Collections-ul.563 ===============
>>
>> Item was changed:
>>   ----- Method: Array>>isLiteral (in category 'testing') -----
>>   isLiteral
>> +
>> +       ^self class == Array and: [
>> +               self isLiteralIfContainedBy: IdentitySet new ]!
>> -       ^self class == Array and: [self allSatisfy: [:each | each isLiteral]]!
>>
>> Item was added:
>> + ----- Method: Array>>isLiteralIfContainedBy: (in category 'testing') -----
>> + isLiteralIfContainedBy: parents
>> +       " Answer whether the receiver has a literal text form recognized by the compiler. Precondition: the receiver is an instance of Array. "
>> +
>> +       (parents includes: self) ifTrue: [ ^false ].
>> +       parents add: self.
>> +       1 to: self size do: [ :index |
>> +               | element |
>> +               element := self at: index.
>> +               (element class == Array
>> +                       ifTrue: [ element isLiteralIfContainedBy: parents ]
>> +                       ifFalse: [ element isLiteral ]) ifFalse: [ ^false ] ].
>> +       parents remove: self.
>> +       ^true!
>>
>>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Frank Shearar-3
In reply to this post by Tobias Pape
On 3 February 2014 16:08, Tobias Pape <[hidden email]> wrote:

> On 03.02.2014, at 16:14, Frank Shearar <[hidden email]> wrote:
>
>> On 3 February 2014 15:06, Tobias Pape <[hidden email]> wrote:
>>> On 03.02.2014, at 16:01, Frank Shearar <[hidden email]> wrote:
>>>
>>>> On 3 February 2014 14:49, Tobias Pape <[hidden email]> wrote:
>>>>> On 03.02.2014, at 15:28, Frank Shearar <[hidden email]> wrote:
>>>>>
>>>>>> On 3 February 2014 13:48,  <[hidden email]> wrote:
>>>>>>
>>>>>> So this is a basic depth first traversal with cycle protection, yes?
>>>>>> (This pattern seems to crop up _a lot_. Maybe it's worth pulling out
>>>>>> as a separate algorithm?)
>>>>>
>>>>> Well, there are two such applications:
>>>>> One with an explicit down-handling of a variable (like this)
>>>>> and one with an implicit variable (semi-global)
>>>>>       (Dynamic variable, probably, at least thread-local)
>>>>>
>>>>> I would like to have both.
>>>>> I propose the (seaside-inspired) #use:during: message for the second.
>>>>
>>>> Except that DynamicVariable's #use:during: is incompatible with
>>>> stack-slicing, because those kinds of dynamic variables aren't
>>>> delimited. (Unlike resumable exceptions, for instance.
>>>
>>> Sorry, I (currently) don’t know what you mean by stack-slicing.
>>> Are we speaking of Martin von Löwis’ DynamicVariables currently in 4.5/trunk
>>> that are based on Thread-local storage
>>> or the Seaside ones based on Exceptions?
>>
>> Ah! I thought that the Seaside ones were the same the DynamicVariable in trunk!
>
> No; the trunk ones should be better, performance-wise, since they don’t
> have to walk the stack on #value

Absolutely they're more efficient. O(1) lookup versus O(n) in the call
stack. And they're also broken when considered with delimited
continuations :) I haven't pushed hard on the issue because I don't
know yet how to make them efficient. (Other languages do things like
"shallow binding", in Henry Baker's terminology. We could possibly get
the same thing with VM modifications.)

>>> (I just see that DV is using #value:during: rather than #use:during:
>>> the former is consistent while the latter IMHO speaks better)
>>
>> Right. So if Seaside's version uses resumable exceptions, there's no trouble.
>>
>> By "stack-slicing" I mean tricks like using delimited continuations.
>> Oleg Kiselyov demonstrated [1] how, since there are multiple
>> reasonable ways of using delimited control and dynamic bindings
>> (trunk's DynamicVariable) together, that there were therefore _no_
>> reasonable ways of combining them. Dynamic bindings either capture too
>> much or too little of the environment. The answer is to _delimit_ the
>> dynamic bindings. Handily, that's exactly what we have with resumable
>> exceptions + #on:do:.
>> [1] http://www.cs.indiana.edu/~sabry/papers/delim-dyn-bind.pdf
>
> Yes, but I think that is more of concern for continuations than for
> dynamically scoped variables, no? Aren’t those by definition delimitted?

No, DynamicVariable style dynamic variables are not delimited, because
their keep-the-old-value-around and their restore-old-value logic
isn't on the call stack. But that's an implementation detail. The
point of the referenced paper is that _no matter what_ implementation
of dynamic variables you have, unless they're delimited they're broken
when considered with delimited continuations. (Or delimited
continuations are broken with them. Point is, their semantics cannot
be sensibly combined.) And delimited continuations are baked into the
bedrock of the language!

frank

> Best
>         -Tobias
>
>
>

Reply | Threaded
Open this post in threaded view
|

Re: The Inbox: Collections-ul.564.mcz

Tobias Pape
On 03.02.2014, at 17:27, Frank Shearar <[hidden email]> wrote:

> On 3 February 2014 16:08, Tobias Pape <[hidden email]> wrote:
>> On 03.02.2014, at 16:14, Frank Shearar <[hidden email]> wrote:
>>
>>> On 3 February 2014 15:06, Tobias Pape <[hidden email]> wrote:
>>>> On 03.02.2014, at 16:01, Frank Shearar <[hidden email]> wrote:
>>>>
>>>>> On 3 February 2014 14:49, Tobias Pape <[hidden email]> wrote:
>>>>>
>>>>> Except that DynamicVariable's #use:during: is incompatible with
>>>>> stack-slicing, because those kinds of dynamic variables aren't
>>>>> delimited. (Unlike resumable exceptions, for instance.
>>>>
>>>> Sorry, I (currently) don’t know what you mean by stack-slicing.
>>>> Are we speaking of Martin von Löwis’ DynamicVariables currently in 4.5/trunk
>>>> that are based on Thread-local storage
>>>> or the Seaside ones based on Exceptions?
>>>
>>> Ah! I thought that the Seaside ones were the same the DynamicVariable in trunk!
>>
>> No; the trunk ones should be better, performance-wise, since they don’t
>> have to walk the stack on #value
>
> Absolutely they're more efficient. O(1) lookup versus O(n) in the call
> stack. And they're also broken when considered with delimited
> continuations :) I haven't pushed hard on the issue because I don't
> know yet how to make them efficient. (Other languages do things like
> "shallow binding", in Henry Baker's terminology. We could possibly get
> the same thing with VM modifications.)
>
>>>> (I just see that DV is using #value:during: rather than #use:during:
>>>> the former is consistent while the latter IMHO speaks better)
>>>
>>> Right. So if Seaside's version uses resumable exceptions, there's no trouble.
>>>
>>> By "stack-slicing" I mean tricks like using delimited continuations.
>>> Oleg Kiselyov demonstrated [1] how, since there are multiple
>>> reasonable ways of using delimited control and dynamic bindings
>>> (trunk's DynamicVariable) together, that there were therefore _no_
>>> reasonable ways of combining them. Dynamic bindings either capture too
>>> much or too little of the environment. The answer is to _delimit_ the
>>> dynamic bindings. Handily, that's exactly what we have with resumable
>>> exceptions + #on:do:.
>>> [1] http://www.cs.indiana.edu/~sabry/papers/delim-dyn-bind.pdf
>>
>> Yes, but I think that is more of concern for continuations than for
>> dynamically scoped variables, no? Aren’t those by definition delimitted?
>
> No, DynamicVariable style dynamic variables are not delimited, because
> their keep-the-old-value-around and their restore-old-value logic
> isn't on the call stack. But that's an implementation detail. The
> point of the referenced paper is that _no matter what_ implementation
> of dynamic variables you have, unless they're delimited they're broken
> when considered with delimited continuations. (Or delimited
> continuations are broken with them. Point is, their semantics cannot
> be sensibly combined.) And delimited continuations are baked into the
> bedrock of the language!
Ok, something that is earliest for 4.6 or even 4.7 :)

best
        -Tobias



signature.asc (1K) Download Attachment
tty
Reply | Threaded
Open this post in threaded view
|

PostgresV3 Help beta

tty
In reply to this post by Levente Uzonyi-2

Hi Levente

Beta version here:



I will contribute more as I get time.

cheers,

t




Reply | Threaded
Open this post in threaded view
|

Re: PostgresV3 Help beta

Levente Uzonyi
Hi Timothy,

I'll add it to the squeaksource repository if it's okay with you?

Levente

On Sun, 11 Mar 2018, gettimothy wrote:

>
> Hi Levente
>
> Beta version here:
>
> https://github.com/gettimothy/postgresV3Help
>
>
> I will contribute more as I get time.
>
> cheers,
>
> t
>
>
>
>

tty
Reply | Threaded
Open this post in threaded view
|

Re: PostgresV3 Help beta

tty
Yes! Please. Thank you very much.



---- On Sun, 11 Mar 2018 16:30:20 -0400 Levente Uzonyi <[hidden email]> wrote ----
Hi Timothy,

I'll add it to the squeaksource repository if it's okay with you?

Levente

On Sun, 11 Mar 2018, gettimothy wrote:

>
> Hi Levente
>
> Beta version here:
>
> https://github.com/gettimothy/postgresV3Help
>
>
> I will contribute more as I get time.
>
> cheers,
>
> t
>
>
>
>