I would like to have ARB meetings for ooRexx (and NetRexx, for that matter). As
a long time has gone by without them, we would need to set those up again.
Maybe it is best that those who would like to participate, send me their time
zones and preferences for meeting date/time. For these meetings to be useful,
we need an agenda. So agenda items are also welcome.
best regards,
René.
> On 10 Nov 2016, at 17:37, Rony G. Flatscher <rony.flatsc...@wu.ac.at> wrote:
>
> Hmm, as no one has commented so far, this is in a sort of limbo.
> How about reinstating/reactivating the ooRexx ARB (architecture review board
> following democratic principles) for the ooRexx project, which originally was
> meant to overview how the ooRexx language should evolve?
> Language related questions like this could be gathered or presented there and
> discussed.
> Of course a lot of implemented concepts have not been formally put through
> the ooRexx ARB in the past. Nevertheless, there is a lot (and sound)
> reasoning behind why and how concepts got implemented, so I would think that
> Rick's thoughts, reasonings and knowledge would be very helpful there as well.
>
> So how about reinstating/reactivating the ooRexx ARB, maybe at least after
> ooRexx 5.0 got out of beta and general available?
>
> Any thoughts, comments?
> ---rony
>
> On 07.11.2016 18:41, Rony G. Flatscher wrote:
>>
>> On 06.11.2016 17:35, Erich Steinböck wrote:
>>> rexxref says that for DO OVER Collection, a MAKEARRAY method is required,
>>> but that's not the full story: Rexx uses the REQUEST("ARRAY") mechanism to
>>> do the conversion, which will send a MAKEARRAY message, and if no such
>>> method exists, will fail (as documented) without testing for an UNKNOWN
>>> method.
>> Well, sending a message that is not implemented, but an UNKNOWN method
>> exists in the searched classes will invoke the UNKNOWN method in lieu.
>>
>> For the sender it does not make a difference whether a message was served by
>> a method implemented by the same name or by the UNKNOWN method. This makes
>> ooRexx very powerful (as it does Smalltalk from which this concept is
>> probably drawn).
>>
>> The REQUEST-protocol in the object class states (from the ooRexx 5.0.0 beta
>> reference):
>> 5.1.4.17. request
>>
>> request( classid )
>>
>> Returns an object of the classid class, or .nil if the request cannot be
>> satisfied.
>> This method first compares the identity of the object's class (see the id
>> method of the Class
>> class) to classid. If they are the same, the receiver object is returned as
>> the result. Otherwise,
>> request tries to obtain and return an object satisfying classid by sending
>> the receiver object the
>> conversion message make with the string classid appended (converted to
>> uppercase). For example,
>> a request("string") message causes a makeString message to be sent. If the
>> object does not
>> have the required conversion method, request returns .nil.
>> The question also occurs here what the meaning of "does not have the
>> required conversion method": does that imply that it must physically exist
>> or does that imply that such a conversion message should be served
>> successfully?
>> The conversion methods cause objects to produce different representations of
>> themselves.
>> The presence or absence of a conversion method defines an object's
>> capability to produce the
>> corresponding representations. For example, lists can represent themselves
>> as arrays, because they
>> have a makeArray method, but they cannot represent themselves as
>> directories, because they do
>> not have a makeDirectory method. Any conversion method must return an object
>> of the requested
>> class. For example, makeArray must return an array. The language processor
>> uses the makeString
>> method to obtain string values in certain contexts; see Section 4.2.11,
>> “Required String Values”.
>> Also, in this context, DO WITH...OVER should probably use the a
>> request("supplier") message, where the current collection classes having a
>> "mere" supplier method should get a synonymous method "makesupplier" in
>> order to match the request protocol.
>>
>>> Whether this is in fact working as designed (but should probably be better
>>> documented) I'm not sure.
>> Maybe others can chime in and give their perspective, point-of-view as
>> feedback to be taken into account.
>>
>> ---rony
>>
>>
>>>
>>> On Sun, Nov 6, 2016 at 3:34 PM, Rony G. Flatscher <rony.flatsc...@wu.ac.at
>>> <mailto:rony.flatsc...@wu.ac.at>> wrote:
>>> The DO...OVER statement allows one to iterate over a collection. To do so a
>>> MAKEARRAY is requested and the resulting array is then iterated over.
>>>
>>> It seems, that the code in DO...OVER does not send the MAKEARRAY message,
>>> if it does not find that method in the receiver object, irrespectible
>>> whether an UNKNOWN method is available that may step in and return that
>>> array upon request.
>>>
>>> Here is a Rexx program demonstrating this problem, bug:
>>>
>>> t=.test~new
>>> tArr=t~makearray~toString(,"/")
>>> say "tArr:" tArr
>>>
>>> do o over t
>>> say o
>>> end
>>> say "---"
>>>
>>> u=.uuu~new
>>> uArr=u~makearray~toString(,"/")
>>> say "uArr:" uArr
>>> do o over u
>>> say o
>>> end
>>> say "---"
>>>
>>>
>>> ::class test
>>> ::method makearray
>>> return ("one", "two", "three")
>>>
>>> ::class uuu
>>> ::method unknown
>>> use arg methName, methArgs
>>> if methName="MAKEARRAY" then return ("one", "two", "three")
>>>
>>> say "in" self"::unknown, about to raise a syntax condition"
>>> raise syntax 98.913 array (self)
>>>
>>> The class "TEST" implements the MAKEARRAY method and the DO...OVER succeeds.
>>>
>>> The class "UUU" does not implement the MAKEARRAY method, but an UNKNOWN
>>> method that returns an array, if a MAKEARRAY message was received. Here,
>>> DO...OVER causes a 98.913 syntax error, which aborts the program!
>>>
>>> Here is the output of running the above program:
>>>
>>> F:\test\oorexx\makearray>test1
>>> tArr: one/two/three
>>> one
>>> two
>>> three
>>> ---
>>> uArr: one/two/three
>>> 13 *-* do o over u
>>> Error 98 running F:\test\oorexx\makearray\test1.rex line 13: Execution
>>> error.
>>> Error 98.913: Unable to convert object "an UUU" to a single-dimensional
>>> array value.
>>> It may be the case that the interpreter tries to optimize by checking for
>>> the existence of a MAKEARRAY method in the receiving object and if not
>>> found short-circuiting by raising the syntax error. Instead it should let
>>> the UNKNOWN mechanism to get exercised, such that it becomes possible to
>>> delegate the execution of such unknown messages (like MAKEARRAY in the
>>> class UUU above) by other code, which is the purpose of the UNKNOWN
>>> mechanism in the first place.
>>>
>>> This is with ooRexx 5.0.0 beta, not sure about previous versions.
>>>
>>> If there are no counter arguments, then I will file a bug report for this
>>> in the tracker.
>>>
>>> ---rony
>>>
>>> P.S.: "DO WITH index i and item o" works by supplying the SUPPLIER method
>>> explicitly or implicitly by the UNKNOWN method. Here is an example for that
>>> variant:
>>>
>>> t=.test~new
>>> say "tArr:" tArr
>>>
>>> do with index idx item o over t
>>> say "index:" idx "item:" o
>>> end
>>> say "---"
>>>
>>> u=.uuu~new
>>> say "uArr:" uArr
>>> do with index idx item o over u
>>> say "index:" idx "item:" o
>>> end
>>> say "---"
>>>
>>>
>>> ::class test
>>> ::method supplier
>>> return .supplier~new((1,2,3), ("one", "two", "three"))
>>>
>>> ::class uuu
>>> ::method unknown
>>> use arg methName, methArgs
>>> if methName="SUPPLIER" then return .supplier~new((1,2,3), ("one", "two",
>>> "three"))
>>>
>>> say "in" self"::unknown, about to raise a syntax condition"
>>> raise syntax 98.913 array (self)
>>> Output (no runtime error):
>>>
>>> F:\test\oorexx\makearray>test2
>>> tArr: TARR
>>> index: one item: 1
>>> index: two item: 2
>>> index: three item: 3
>>> ---
>>> uArr: UARR
>>> index: one item: 1
>>> index: two item: 2
>>> index: three item: 3
>>> ---
> ------------------------------------------------------------------------------
> Developer Access Program for Intel Xeon Phi Processors
> Access to Intel Xeon Phi processor-based developer platforms.
> With one year of Intel Parallel Studio XE.
> Training and support from Colfax.
> Order your platform today.
> http://sdm.link/xeonphi_______________________________________________
> Oorexx-devel mailing list
> Oorexx-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/oorexx-devel
------------------------------------------------------------------------------
_______________________________________________
Oorexx-devel mailing list
Oorexx-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/oorexx-devel
