> On Feb 9, 2018, at 7:46 AM, Robin Vowels <robi...@dodo.com.au> wrote:
> From: "Paul Raulerson" <paul.rauler...@me.com>
> Sent: Friday, February 09, 2018 1:03 PM
>>> On Feb 8, 2018, at 7:31 PM, Robin Vowels <robi...@dodo.com.au> wrote:
>>> From: "Paul Raulerson" <paul.rauler...@me.com>
>>> Sent: Friday, February 09, 2018 9:46 AM
>>>> Because they don’t have any special knowledge of strings,
>>> The only "special knowledge" of strings that is required is that
>>> a string is composed of bytes.
>> Seriously?
> Seriously.
>> Just haven’t to disagree there. From your point of view integers and 
>> character data and strings and floating point values are the same thing, 
>> right?
> No they are not. I never said that they were.
>> Because you can move character them all the same way?
>>>> only untyped data. And the lengths of the data they operate on
>>>> is fixed and defined at compile time, not at run time.
>>> Whether the length of a string is known at compile time or at run time
>>> is irrelevant.
>>> The data is a string.  And the instruction(s) that operate on them are
>>> string instructions.
>> Nope, but you are as welcome to your opinion as I am to mine.  :)
> You are being ridiculous.

Okay - so you want to pick and choose which data types you will recognize, and 
yet you think I am being ridiculous? 

HLASM is not a strongly typed language, which not incidentally, is one of the 
reasons it is not suited for OOP. The introduction of strong types into HLASM 
is always resisted, which is the primary reason to not both extending it to be 
a OOP language. 

It has not definition of a STRING type. 

>> Question - why do you think IBM added string specific instructions if MVC is 
>> all one ever really needs?
> IBM can add any kind of instruction that it likes.
> It didn't need to add specific instructions to deal with null-terminated 
> strings.
> MVC, MVCL are prefectly good for for handling strings.
> IBM used them in all its compilers for handling all kinds of text (i.e., 
> strings).
>>>> How about taking as a definition of a string any text that SuperC will 
>>>> search for? Or a text string in ISP?
>>>> Obviously, what a string is and how it is defined varies from language to 
>>>> language.
>>>> But usually they are not defined as binary data. Unicode excepted.
> Image data consists of arbitrary characters.  It may contain null characters,
> and plenty of them.

This *is* ridiculous - image data, say your average JPEG, is not a string, by 
any definition I know of.  It isn’t even character data. It’s just a byte 
array, at least on an IBM Mainframe. What is difficult to accept about that?

>>>> Just by the way, a NULL as a string terminator seems to make sense.
>>> And if the string _contains_ null characters?
>> Then it isn’t a string - unless of course, the null marks the end of the 
>> string.
> I just said that it didn’t.

No, you just asked what if the string “contains” null characters. The most 
correct answer to that is that the “string” is not then a string. 

Unless you just happen to be using the null as a string terminator. If you are 
not, or if you are using some other character as a delimiter, then your 
“string” is not a string, just a byte array. 

>>>> MVST (Move String), CLST (Compare String), SRST (Search String)
>>>> are all instructs and all work with null terminated strings.
> So?  Also will MVC, MVCL, MVI, CLC, TRT, etc

So NO. Not MVC, MVI, etc. 

>>>> Translate Extended is needed to work with Unicode without loosing one’s 
>>>> mind…
> And TRT will handle null-terminated strings, as well as other kinds. 

What has that got to do with handling Unicode?  TRT has no idea at all about 
handling “null terminated strings” so far as I know. 

Let’s bring this down to a more reasonable discussion, since you seem to be way 
the heck off in left field somewhere building up a hostile attitude. 

1. Yes, you can handle strings, of any type, in HLASM. But, you have to either 
use the IBM String instructions, or you have to roll your own routines. There 
are no standard definitions of a string in the language, and no built in ways 
to handle them. This to me, makes the definition of a string there quite dodgy.

2. If you dispute that, that’s okay with me. However, I see no qualitative data 
typing in HLASM to define a string, no faculties to do common things one might
want to do with a string, and no agreement at all on what a string actually is, 
other than what one wants it to mean at any particular time. No matter *how* 
you define a string.


strcpy() - copies one string to another at run time                             
— the compiler or assembler has no idea of the size of the string
strlcpy() copies n bytes of one string to another at run time           — which 
is quite relevant. 
strlen() returns the length of a string at run time
strcmp() compares two strings at runtime

None of these are standard anything in HLASM, which also has no defined 
facilities at all I know of to deal with wide character strings, or even wide 
characters. (There may be unicode instructions I am not familiar with.) 

Yes, you can write HLASM BASR or BALR routines, or even Macros to do all of 
that. Which work great until someone decides that a binary JPEG data buffer is 
a “string.”  Then it likely will all fail. 

And note, none of this is touching on OOP - a String Object in Java implements 
all those kinds of things above, and exposes methods and attributes to allow 
anyone to successfully manipulate the string. The key of course being that you 
do not know how that string is implemented. It could be null terminated or not, 
but you don’t know, because the implementation is hidden within the object. 

Certainly you can define a HALSM data structure and set of routines to 
implement a string anyway you want, but some yahoo is going to decide that they 
can just modify your defined string on the fly and blow up those nicely crafted 

Which, to bring this all around to the point, is probably why nobody does that, 
or tries to implement OOP in HLASM. 

> ---
> This email has been checked for viruses by Avast antivirus software.
> https://www.avast.com/antivirus

Reply via email to