probably
Association class>>inClass:c return:anObject
     ^( ( anObject isKindOf:c )
            ifTrue:[ self key:c value:anObject ]
            itFalse:[ self error:’wrong type’ ] )
would be the best place to do the type check
so now Associations are Monads or Association subClass:#Monad or whatever
so then
Association>>=<< a1InputValua
     ^( self class inClass:( self key )return:( a1InputValua value:( self
value ) ) )

On Wed, Aug 3, 2022 at 22:53 Kjell Godo <squeaklist at gmail.com> wrote:

> correct me if i am wrong but
>
> Association class>>return: anObject ^( self new value: anObject )
> Association>>=<< aOneInputValua
>      ^( self class return:( aOneInputValua value:( self value ) ) )
>
> where
>      ( aOneInputValua respondsTo:#value: )=true
>
> or
> Association class>>inClass:c return: anObject ^( self key:c value:
> anObject )
> Association>>=<< a2InputValua
>      ^( self class inClass:( self key )return:(
>              aOneInputValua value:( self key )value:( self value ) ) )
>              “where aOneInputValua uses its first input which is aClass to
> do some
>                kind of runtime type checking or like
> or maybe more like”
> Association class>>inClass:c return: anObject ^( self key:c value:
> anObject )
> Association>>=<< a1InputValua
>      ^( self class inClass:( self key )return:(
>           a1InputValua value:(
>                ( ( self value )isKindOf:( self key ) )
>                     ifTrue:[ self value ]ifFlase:[ self Error:’wrong type’
> ] ) ) )
>
> you see the thing about Haskell is that it is completely lazy so there is
> no evaluation ordering that can be counted on so monads are a way to impose
> an execution order via function composition like
> ( h value:( g value:( f value: x ) ) ) forces f to be done first and h
> last and g second
>
> but Smalltalk is not lazy , so there is a runtime ordering , so maybe
> Smalltalk can get an equivalent functionality out of just composing one
> input valua which is just composing one input functions , unless you want
> to insist on the >>isKindOf: type checking
>
> On Wed, Aug 3, 2022 at 15:18 Eliot Miranda <eliot.miranda at gmail.com>
> wrote:
>
>> Hi Tony,
>>
>> On Mon, Aug 1, 2022 at 1:48 AM Tony Garnock-Jones <
>> tonyg at leastfixedpoint.com> wrote:
>>
>>> On the Squeak Slack, @asarch asked "Are there monads in Squeak?"
>>>
>>> My answer was:
>>>
>>> Tricky question. Monads are a kind of design pattern reflecting a formal
>>> mathematical structure. Languages with static type systems are able to
>>> enforce some (but usually not all) of the mathematical monad laws; in
>>> Smalltalk, the type system is not strong enough to enforce any monad
>>> laws. So, monads do appear in Smalltalk in two ways: implicitly, in that
>>> theoretically every expression is "in the IO monad"; and explicitly, in
>>> examples such as the API on class Promise. Squeak's Promise class
>>> implements monadic operations and honours the monad laws.
>>>
>>
>> I'd love to read a definition of the monad laws in plain English.  I
>> think I understand promises perfectly well.  I've never understood what a
>> monad is.  I'm unable to think algebraically very effectively but can think
>> visually (for example I didn't understand the fourier transform
>> algebraically (the double integral formulation), but understand it
>> perfectly well as an infinite set of infinite integrals of the products of
>> a sine wave with an arbitrary waveform (itself composed of sine waves)).
>> So if you can explain monads without recourse to algebra (but as much
>> recourse to Smalltalk as you like) then you have my full attention.
>>
>> So TL;DR is "yes, but..." :-)
>>>
>>> Cheers,
>>>    Tony
>>>
>>
>> _,,,^..^,,,_
>> best, Eliot
>>
>>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.squeakfoundation.org/pipermail/squeak-dev/attachments/20220803/fcc35ae1/attachment.html>