🚀 go-pugleaf

On Thu, 18 Jan 1996, Eric Obermuhlner wrote:

> Hi out there
> 
> How do I do the ugly things that C programmers like so very much in Modula 2?
> Like getting a pointer to a var, pointer arithmetic, bit operations (shift, and, or, exor).
> 
> Thanks in advance.

Well, you can do some of the above with bit sets, but to really do it 
well you either need non-standard M2 or a set of assembly language 
routines to link in.  I wrote a set of ASM's for Stony Brook (old 
version; the new bersion uses BAND, BOR, BXOR).  If you are interested 
(they will probably work for your version, too), let me know.

=============================================================
Douglas Cook, undergraduate in Computer Science at BYU
-------------------------------------------------------------
*REAL* programmers use COPY CON PROGRAM.EXE
=============================================================

Eric Obermuhlner (erico@cnmat.berkeley.edu) wrote:
: Hi out there

: How do I do the ugly things that C programmers like so very much in Modula 2?
: Like getting a pointer to a var, pointer arithmetic, bit operations (shift, and, or, exor).

Well, I wound up doing that kind of stuff in assembly language.  I also
concluded that the insistence on abstraction above all else was sometimes 
detrimental to my efforts to easily write things such as CRC routines.

jguthrie@brokersys.com wrote:
: Eric Obermuhlner (erico@cnmat.berkeley.edu) wrote:
: : Hi out there
: 
: : How do I do the ugly things that C programmers like so very much in Modula 2?
: : Like getting a pointer to a var, pointer arithmetic, bit operations (shift, and, or, exor).
: 
: Well, I wound up doing that kind of stuff in assembly language.  I also
: concluded that the insistence on abstraction above all else was sometimes 
: detrimental to my efforts to easily write things such as CRC routines.
: 
Well there are a few reasons why we consider this sort of thing 'ugly'..
Even so, there should be little need to go to asm for them..

Assigning a pointer to an ordinal variable, would be done thru type
coercion, as in:   ordVar := CARDINAL(ptrVar);

THis assumes, of course, that the length (bit-size) of a CARDINAL is the
same as for a pointer..

Pointer arith.. ugh!!! well if you *must*, coercing the pointer to a
cardinal will often do the trick... but if you work on a platform with
segmented addresses you'll have a lot of fun.. ISO helps, here by providing
functions for incrementing and decrementing Adresses..

Bit operations.. unfortunately with pre-ISO compilers, we where usually
stuck with multiplying or dividing by 2, for shift operations (rotate is
a tad more involved), now ISO also provides functions for those.. for
and/or/xor etc.. it's always been possible to do these, using the set
operators.. first coerce to a BITSET, then apply these ops:

  +  ... set union,   'or'
  *  ... set intersection,  'and'
  /  ... set symmetric difference,  'xor'
  -  ... set difference,  'and not'

Further you can more easily test for a bit, using:   bit IN someBitset

Set a specific bit:  INCL(someBitset, bitToSet)
Reset a specific bit:  EXCL(someBitset, bitToReset)

Ciao!
Michel De Rosa
Aliath@nyongwa.montreal.qc.ca

Michel De Rosa (aliath@nyongwa.montreal.qc.ca) wrote:

: Bit operations.. unfortunately with pre-ISO compilers, we where usually
: stuck with multiplying or dividing by 2, for shift operations (rotate is
: a tad more involved), now ISO also provides functions for those.. for
: and/or/xor etc.. it's always been possible to do these, using the set
: operators.. first coerce to a BITSET...

Please don't talk down to me.  I know how to manipulate bitsets, but 
do WHAT to a BITSET?   As far as I know, NONE of the M2 compilers I have
ever used allow me to convert between any kind of number and any kind of
set.  Otherwise, I'd have used that rather than mucking about with assembly
language.  

I know that that isn't mentioned anywhere in PIM3C.

In article <4du11j$l31@weck.brokersys.com> jguthrie@brokersys.com writes:

>Michel De Rosa (aliath@nyongwa.montreal.qc.ca) wrote:

>: Bit operations.. unfortunately with pre-ISO compilers, we where usually
>: stuck with multiplying or dividing by 2, for shift operations (rotate is
>: a tad more involved), now ISO also provides functions for those.. for
>: and/or/xor etc.. it's always been possible to do these, using the set
>: operators.. first coerce to a BITSET...

>Please don't talk down to me.  I know how to manipulate bitsets, but 
>do WHAT to a BITSET?   As far as I know, NONE of the M2 compilers I have
>ever used allow me to convert between any kind of number and any kind of
>set.  Otherwise, I'd have used that rather than mucking about with assembly
>language.  

They should all allow you to CAST (coerce) to a BITSET and back

  e.g.    A := CARDINAL( BITSET(x) * BITSET(y) )

does AND, and so on.  

Pat Terry (cspt@giraffe.ru.ac.za) wrote:

: They should all allow you to CAST (coerce) to a BITSET and back

:   e.g.    A := CARDINAL( BITSET(x) * BITSET(y) )

: does AND, and so on.  

Why isn't this mentioned in any of the books that I've read on Modula-2?  I
was always left with the impression that it was impossible to do this.

jguthrie@brokersys.com wrote:
: Pat Terry (cspt@giraffe.ru.ac.za) wrote:
: 
: : They should all allow you to CAST (coerce) to a BITSET and back
: 
: :   e.g.    A := CARDINAL( BITSET(x) * BITSET(y) )
: 
: : does AND, and so on.  
: 
: Why isn't this mentioned in any of the books that I've read on Modula-2?  I
: was always left with the impression that it was impossible to do this.

It is mentionned in PIM, it may or may not be in others, but it's usually
mentionned where low-level facilities are discussed...

What i'd love to see mentionned in a book (clearly), is the 'tag-less'
variant case, for records.. :{(

Oh.. just to be clear,  coercion, as done above, is not limited to
base-types.. neither does it do any sort of interpretation of the bits,
i.e. it's a straight copy of the bitmap, if you will..

Ciao!
Michel De Rosa
Aliath@nyongwa.montreal.qc.ca

Eric Obermuhlner (erico@cnmat.berkeley.edu) wrote:

>How do I do the ugly things that C programmers like so very much in Modula 2?
>Like getting a pointer to a var, pointer arithmetic, bit operations (shift, and, or, exor).

All of these things are possible (but see below).
(a) p := ADR(v) makes p point to v;
(b) Pointer arithmetic: support varies from one compiler to another,
    but in the libraries you'll likely find procedures like
    SYSTEM.AddOffset and the like.  Early versions of Modula-2
    even allowed arithmetic on variables of type ADDRESS, but
    this mistake has since been corrected.
(c) Bit operations: usually supported in some low-level library
    module.  If not, you can fake them by type-casting to
    BITSET, though this is a messy solution.

The obvious question, though, is why you would want to do this.
Such operations are common in C programming because C lacks
more elegant ways to get the job done.  In Modula-2, there are
certainly situations where you want to do weird hardware-dependent
things and break the type system, but those situations should
arise only when writing very low-level modules.  In most other
cases, there's almost always a better way to do the job.

Why, then, do C programmers like the ugly style so much?
I can think of two main reasons:
 1. For whatever reason, C does not support the concept of an
    "array".  (The syntax makes it look as if arrays are
    supported, but when you dig deeper you discover that it's
    just a shortcut notation for certain pointer operations.)
    Thus C programmers get used to the idea of doing things
    like stepping a pointer through an array, even when it
    would be easier and clearer - and often more efficient -
    to use subscripts.
 2. Student programmers are often misled into thinking that
    low-level programming leads to greater efficiency.
    (Especially when they've graduated from using Basic to
    C; there's no doubt that C is faster than Basic, but then
    anything's faster than Basic.)  Often they're wrong, but
    they're so convinced that this conclusion is "intuitively
    obvious" that they simply refuse to make the comparison.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html

Michel De Rosa (aliath@nyongwa.montreal.qc.ca) wrote:

: : Why isn't this mentioned in any of the books that I've read on Modula-2?  I
: : was always left with the impression that it was impossible to do this.

: It is mentionned in PIM, it may or may not be in others, but it's usually
: mentionned where low-level facilities are discussed...

I'll be darned.  It's right there in chapter 29.  (However, Wirth does
everything but come out and say "don't ever use this.")  

: Oh.. just to be clear,  coercion, as done above, is not limited to
: base-types.. neither does it do any sort of interpretation of the bits,
: i.e. it's a straight copy of the bitmap, if you will..

One point.  My understanding is that the term coercion is normally reserved
for typecasting that is done sliently by the compiler.

jguthrie@brokersys.com wrote:
>Michel De Rosa (aliath@nyongwa.montreal.qc.ca) wrote:

>: Bit operations.. unfortunately with pre-ISO compilers, we where usually
>: stuck with multiplying or dividing by 2, for shift operations (rotate is
>: a tad more involved), now ISO also provides functions for those.. for
>: and/or/xor etc.. it's always been possible to do these, using the set
>: operators.. first coerce to a BITSET...

>Please don't talk down to me.  I know how to manipulate bitsets, but 
>do WHAT to a BITSET?   As far as I know, NONE of the M2 compilers I have
>ever used allow me to convert between any kind of number and any kind of
>set.  Otherwise, I'd have used that rather than mucking about with assembly
>language.  

>I know that that isn't mentioned anywhere in PIM3C.

Yes it is.  Let c be a CARDINAL (for example) and let b be a BITSET.
Then in ISO M2 you can write  b := CAST(BITSET, c).  In the PIM3
version of M2 the syntax is more obscure:  b := BITSET(c).
The second form should be supported by any M2 compiler you can
lay your hands on.

A trick used by some programmers is to abuse the concept of
a record with variants:

     TYPE Cheat = RECORD
                      CASE :BOOLEAN OF
                          | FALSE: bits: BITSET;
                          | TRUE:  val: CARDINAL;
                      END (*CASE*)
                  END (*RECORD*)

Now, with x a variable of type Cheat, you can do bit operations
on x.bits, and the answer will turn up in x.val.  This isn't
portable, but then operations requiring type-casting are
inherently non-portable in any language.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html

In article <4e1o5v$6i8@seagoon.newcastle.edu.au>, peter@tesla.newcastle.edu.au wrote:

> The obvious question, though, is why you would want to do this.
> Such operations are common in C programming because C lacks
> more elegant ways to get the job done.  In Modula-2, there are
> certainly situations where you want to do weird hardware-dependent
> things and break the type system, but those situations should
> arise only when writing very low-level modules.  In most other
> cases, there's almost always a better way to do the job.

I don't *want* to do this, I didn't find any other way in my case.

<BEGIN WEIRD DESCRIPTION OF MY PROBLEM>
I'm adding Modula code to a project that was 100 percent done in assembler.
I have some global variables that need to be transmitted thru MIDI SYSEX.
I've defined a SYSEX protocoll that allows me to read/write those vars.

SYSEX PARAM_DATA from length val_1 .. val_n SYSEXEND (* sets params to values *)
SYSEX PARAM_REQ from length SYSEXEND (* answered by PARAM_DATA *)

(* Lets assume the vars are: *)
VAR
  alpha : CARDINAL;  (* idx: 0 *)
  beta : CARDINAL;   (* idx: 1 *)
  gamma : CARDINAL;  (* idx: 2 *)

(* My procedure could now look like this *)

PROCEDURE ReadParam( from : CARDINAL, to :CARDINAL);
VAR
  i : CARDINAL;
BEGIN
  FOR i:= from TO to DO
    CASE i OF
    | 0 : alpha := ReadMIDICardinal();
    | 1 : beta := ReadMIDICardinal();
    | 2 : gamma := ReadMIDICardinal();
    (* ... *)
    ELSE
      (* ignore *)
    END; (* CASE i *)
  END; (* FOR i *)
END ReadParam;

(* ... similar for PROCEDURE WriteParam *)

(* or I could use pointer arithmetic to change those values directly. *)

<END WEIRD DESCRIPTION OF MY PROBLEM>

I admit that I don't like the clean Modula solution, because the code will get huge, even if it looks neat. (The variables to change might one day be in the hundreds)

Is there a better way to do this? Maybe like having an array at the same place. (I know, that's C too)

<BEGIN OTHER PROBLEMS>
Are there CONST arrays for ROM tables?
How do I initialize a table with values? (in RAM)
<END OTHER PROBLEMS>

+-------------------------------------------------------------+
|Eric Obermuhlner  
|erico@g-wiz.com
|if (err == err_bounced) send("erico@cnmat.berkeley.edu"); 
+-------------------------------------------------------------+
#include "stddisclaimer"
#include "funnyquotations"
ERROR 10045: FILE "funnyquotations" EXHAUSTED.
OPENING FILE "notsofunnyquotations" INSTEAD.
ERROR -46: FILE "notsofunnyquotations" HAS A BAD BLOCK.
READING "j{Hr4#^_t~~~
ARGH I'M DYING.
dumping core......
(Just kidding)

In article <4e3t1f$d5q@seagoon.newcastle.edu.au>
           peter@tesla.newcastle.edu.au "Peter Moylan" writes:

> jguthrie@brokersys.com wrote:
> >Michel De Rosa (aliath@nyongwa.montreal.qc.ca) wrote:

> >I know that that isn't mentioned anywhere in PIM3C.
> 
> Yes it is.  Let c be a CARDINAL (for example) and let b be a BITSET.
> Then in ISO M2 you can write  b := CAST(BITSET, c).  In the PIM3
> version of M2 the syntax is more obscure:  b := BITSET(c).

I think it might be a matter of taste, I generally prefer the look
of the latter (even if the syntax is more obscure) since it leaves
numerical expressions looking considerably less cluttered.

> The second form should be supported by any M2 compiler you can
> lay your hands on.

Indeed. I don't have the reference to hand but isn't   
	 b := VAL(BITSET, c) valid in PIM3 too ? 
 
> A trick used by some programmers is to abuse the concept of
> a record with variants:
> 
>      TYPE Cheat = RECORD
>                       CASE :BOOLEAN OF
>                           | FALSE: bits: BITSET;
>                           | TRUE:  val: CARDINAL;
>                       END (*CASE*)
>                   END (*RECORD*)
> 
> Now, with x a variable of type Cheat, you can do bit operations
> on x.bits, and the answer will turn up in x.val.  This isn't
> portable, but then operations requiring type-casting are
> inherently non-portable in any language.

This can sometimes be useful. Inherently dangerous too.

Actually it can be portable provided that it contains a flag to say 
what data type is stored in it and your routines agree to abide by the 
rule of only using the data type that was last written to "Cheat" record.  
You have to be severely memory (ram) constrained to contemplate this.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

In <4e01fn$qte@weck.brokersys.com> jguthrie@brokersys.com writes:

>Pat Terry (cspt@giraffe.ru.ac.za) wrote:

>: They should all allow you to CAST (coerce) to a BITSET and back

>:   e.g.    A := CARDINAL( BITSET(x) * BITSET(y) )

>: does AND, and so on.  

>Why isn't this mentioned in any of the books that I've read on Modula-2?  I
>was always left with the impression that it was impossible to do this.

Just have a deeper look into the language report which is included
in "Programming in Modula-2", 3rd edition, by N.Wirth.
There the types BITSET, CARDINAL, INTEGER a.s.o. are described so
as to leave no doubt what can be done and what can't.

cu,
  Torsten

Peter Moylan (peter@fourier.newcastle.edu.au) wrote:

: Now, with x a variable of type Cheat, you can do bit operations
: on x.bits, and the answer will turn up in x.val.  This isn't
: portable, but then operations requiring type-casting are
: inherently non-portable in any language.

(At least you don't call it coercion.)

I disagree with your last statement, because an awful lot of experience
suggests that it just isn't true in the most typical case.

Look, most everyone posting on this newsgroup programs for computers with
certain characteristics.  These computers store signed integers with 
twos-complement notation and use the IEEE floating-point formats.  These
computers use either 16 or 32 bits to hold INTEGERs and 32 or 64 bits to
hold REALs.  Leaving alone the "endianness" of the processor (which
really doesn't make any difference to what we're discussing) it is quite
possible to write portable code that makes use of casts to BITSET().

One of the other posts in response to my statement that "it isn't in PIM3C"
pointed out that such a cast rarely has any real semantic content.  However,
you could very easily require that the cast to BITSET results in the BITSET
that corresponds to the twos-complement representation of whatever the
INTEGER or CARDINAL (yeah, I know:  twos-complement doesn't really apply to
cards) was.  You would then also require that the conversion back do the
reverse thing.  That would be as portable as anything else in Modula-2,
and would handle the truly wierd cases (the ones-complement and
sign-magnitude computers) better than what C does, which is to use the
"natural" notation for the computer.

Why is it dangerous to recognize that all of these data values are composed
of bits?

I also take exception to your statement that you hardly ever need to use
such code, and therefore, it must not be important.  One of the main
reasons that I stopped using Modula-2 for the stuff I was doing
professionally was the difficulty I had coding CRC routines because I
didn't know about the casts to BITSET.  That may be a small use, but it
was vital to what I needed at the time.

In article <4e5b5u$7s5@weck.brokersys.com> jguthrie@brokersys.com  writes:

> Peter Moylan (peter@fourier.newcastle.edu.au) wrote:
> 
> : Now, with x a variable of type Cheat, you can do bit operations
> : on x.bits, and the answer will turn up in x.val.  This isn't
> : portable, but then operations requiring type-casting are
> : inherently non-portable in any language.
> 
> (At least you don't call it coercion.)
> 
> I disagree with your last statement, because an awful lot of experience
> suggests that it just isn't true in the most typical case.
> 
> Look, most everyone posting on this newsgroup programs for computers with
> certain characteristics.  These computers store signed integers with 
> twos-complement notation and use the IEEE floating-point formats.

Yes but one of reasons I sometimes have to use serious bit twiddling
is to read alien data tapes from systems that stored raw binary data
in well defined but either proprietory or non IEEE real number formats.
 
> computers use either 16 or 32 bits to hold INTEGERs and 32 or 64 bits to
> hold REALs.  

I do wonder what would happen to a lot of modern software if a new
and popular architecture appeared that chose non-standard data sizes 
say 7 bit bytes, 35 bit words and 42 bit addresses. I can guess :-)
It would be a severe test of truely portable code!

> Leaving alone the "endianness" of the processor (which
> really doesn't make any difference to what we're discussing) it is quite
> possible to write portable code that makes use of casts to BITSET().

It depends how you are intending to access the bits individually.
Among the bitset numbering orders I have seen are
	{31, 30, ....    1, 0}
	{24, 25, .... 32, 16, 17, ... 23, 8, 9,  ... 15,  7, 6, ... 0 }
	{7, 6,   .... 0,  15, 14, ... 8, 23, 22, ... 16,  31, 30, ... 24 }

You can write portable code that will work with all of these, but it
is easy to fall into the trap of machine dependence.

> Why is it dangerous to recognize that all of these data values are composed
> of bits?

Because you open up the can of worms about how the internal bits 
have been numbered - and there are no guarantees on that at all.
(Perhaps the new standard says something about this? I don't know). 
 
> I also take exception to your statement that you hardly ever need to use
> such code, and therefore, it must not be important.

I don't think he said the second part, and it is true that you very
rarely need to go down to the bits level unless you are programming
i/o devices at the hardware level or communicating with odd systems.
When you do need it then it can be crucial.

Regards,
-- 
Martin Brown  <martin@nezumi.demon.co.uk>     __                CIS: 71651,470
Scientific Software Consultancy             /^,,)__/

When I first came to Modula-2 I used BITSET for things like
manipulating I/O ports; I imagine that Wirth had things like that
in mind when he put BITSET into the language.  I've since
switched to other methods - in fact, I almost never use BITSET
now, even though most of my programming is of the "down to the
bare metal" variety - because of two problems:

1. Size: is a BITSET 8 bits wide, or 16, or 32, or something else?
   You might think that this doesn't matter if the software is
   for a very specific hardware configuration; but the fact is
   that the width of a BITSET varies even between two different
   compilers for the same machine.
2. Bit numbering: is bit 0 the leftmost bit, or the rightmost?
   People have been arguing over which of these two conventions
   is "best" for years, and neither camp has dominated over the
   other.  (Some people even use big-endian at the bit level
   combined with little-endian at the byte level, or vice versa.)
   Whichever convention you use, you'll soon find a compiler
   writer who prefers the opposite.

When I used FTL Modula-2 for the PC, one of the claimed features
of the compiler was that "unlike other compilers, this compiler
uses the correct numbering for bits in a BITSET".  The author's
definition of "correct" was, as nearly as I could judge, the
numbering system defined in the hardware documentation for the
6502 microprocessor.  One consequence of this was that the bits
in a byte were numbered 8..15 (i.e. bits 0..7 didn't exist).
Well, the author was entitled to his opinion, but it did make
him inconsistent with most other compilers for the PC.

The ISO M2 standard does, I think, dictate a little-endian
ordering for BITSET.  (That's from memory; I've forgotten which
section I should look up.)  But that doesn't completely resolve
the problems that arise when, for example, you upgrade your
PC compiler from 16-bit to 32-bit support.

I remain convinced that BITSET should have been defined in
SYSTEM, so that it was clearly labelled as non-portable.

--
Peter Moylan                       peter@ee.newcastle.edu.au
                           ftp://ee.newcastle.edu.au/pub/www/Moylan.html

jguthrie@brokersys.com wrote:
: Michel De Rosa (aliath@nyongwa.montreal.qc.ca) wrote:
: 
: : [...]
: : and/or/xor etc.. it's always been possible to do these, using the set
: : operators.. first coerce to a BITSET...
: 
: Please don't talk down to me.

Sorry it wasn't my intention to do so..

: I know how to manipulate bitsets, but do WHAT to a BITSET?

Well other posts have, i hope, already cleared that up..

: As far as I know, NONE of the M2 compilers I have ever used allow me
: to convert between any kind of number and any kind of set.

Again it may be only due to the fact that you weren't aware of the
type-coercion facility..

I've used a number of different compilers, Logitech v3 (pc/dos), JPI
TopSpeed (pc/dos), gpm-pc (again pc/dos), and an old pim2-based compiler
for VAX/VMS.. they've all allowed this sort of coercion, with some caveats,
mainly some of them would have restrictions, on a size of a set (the same
with as a cardinal), and some wouldn't allow coercing from<->to a variable
of a different size (say a bitset to a char)..

: I know that that isn't mentioned anywhere in PIM3C.

I've been at m2 for a long time (i mean real long time).. i honestly can't
say how or when i first became aware of the facility.. i know it's in Pim4,
because i recently had occasion to look it up..

I do use the term coercion, rather than casting, because there's a
difference.. the way pim4 documents the facility, absolutely no
interpretation of the bits is made.. we're forcing (coercing) the compiler
to treat the expression, as if it was of a different type.

My understanding of type-casting, suggests that there's a minimum of
interpretation being done, an attempt is made to preserve the value being
cast to another type. That is assuming we have a short-integer type,
than:

 si : SHORTINT;
 i  : INTEGER;
 ...
   si := -1;              (* On intel this maps to  FFh *)
   (* cast si to i *)
   ... at this point i should be -1 , or FFFFh...

With type-coercion, we'd likely get a positive value (always assuming
the compiler let's us cast/coerce between different bit-sizes).

   si := -1;
   i := INTEGER(si);      (* we now have  00FFh *)


Michel De Rosa
Aliath@Nyongwa.montreal.qc.ca

On 24 Jan 1996 jguthrie@brokersys.com wrote:

> I also take exception to your statement that you hardly ever need to use
> such code, and therefore, it must not be important.  One of the main
> reasons that I stopped using Modula-2 for the stuff I was doing
> professionally was the difficulty I had coding CRC routines because I
> didn't know about the casts to BITSET.  That may be a small use, but it
> was vital to what I needed at the time.

Hmm...  That's too bad.  I still swear by Modula II, but I also had to 
write a CRC routine.  I ended up writing one in assembler.  It was just 
as easy as doing it in a high level language, a lot more efficient, and 
the only problem was that I had to mess with my make file for a while 
before it linked in correctly.  I also wrote a set of AND, OR, XOR, etc. 
routines, but then I ended up never needing them again in my program.  
Bitwise operations are usually avoidable, and when they aren't, you have 
your options.  However, now the best option is to get a new version of 
your compiler.  The new Stony Brook compiler (I don't know if it has been 
released yet - I used a Beta release last summer) has BAND, BOR, and BXOR 
as compiler extentions.  I expect that most other compilers also have 
extentions (I have heard rumors about them here and there).

============================================================
Douglas Cook, undergraduate in Computer Science at BYU
------------------------------------------------------------
This sentence is false.
============================================================