From mika at async.caltech.edu Fri Sep 1 18:30:22 2017 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Sep 2017 09:30:22 -0700 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <20170828180549.GA14224@topoi.pooq.com> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> <239249321.5067398.1503941236042@mail.yahoo.com> <20170828180549.GA14224@topoi.pooq.com> Message-ID: <20170901163022.9B7191A206B@async.async.caltech.edu> Is there some consensus on what precisely needs to be extracted in terms of a release? The Linux discussion earlier on this list made no sense to me, it almost sounded like someone was wilfully misinterpreting the plain English of the legalese. Also who is/has been the best lead so far? I can see if I can find someone through various connections... Mika Hendrik Boom writes: >On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Benavides D. wro= >te: >> Hello:I fear most viable way to keep te language alive is to GPL it . Soo= >n we wont have the resortes to keep alive. Im not understimating anyone her= >e. But IMHO is de time to do it.=A0Thanks in advance > >Any GPL-compatible license will work. Even MIT. Possibly even the = > >so-called Creative Commons variation on public domain, which is = > >meaningful in jurisdictions without a concept of public domain. > >The hard part is liberating the parts of the system that are currently = > >inder the existing Modula 3 license. They will have to be replaced if = > >we can't get the copyright owner to respond usefully. > >And that's a lot of work. > >-- hendrik >_______________________________________________ >M3devel mailing list >M3devel at elegosoft.com >https://m3lists.elegosoft.com/mailman/listinfo/m3devel From lists at darko.org Fri Sep 1 19:08:00 2017 From: lists at darko.org (Darko Volaric) Date: Fri, 1 Sep 2017 19:08:00 +0200 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <20170901163022.9B7191A206B@async.async.caltech.edu> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> <239249321.5067398.1503941236042@mail.yahoo.com> <20170828180549.GA14224@topoi.pooq.com> <20170901163022.9B7191A206B@async.async.caltech.edu> Message-ID: Wait, there is a serious move toward releasing under GPL? Or have I misunderstood this email. > On Sep 1, 2017, at 6:30 PM, mika at async.caltech.edu wrote: > > > Is there some consensus on what precisely needs to be extracted in terms > of a release? The Linux discussion earlier on this list made no sense > to me, it almost sounded like someone was wilfully misinterpreting the > plain English of the legalese. > > Also who is/has been the best lead so far? I can see if I can find > someone through various connections... > > Mika > > Hendrik Boom writes: >> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Benavides D. wro= >> te: >>> Hello:I fear most viable way to keep te language alive is to GPL it . Soo= >> n we wont have the resortes to keep alive. Im not understimating anyone her= >> e. But IMHO is de time to do it.=A0Thanks in advance >> >> Any GPL-compatible license will work. Even MIT. Possibly even the = >> >> so-called Creative Commons variation on public domain, which is = >> >> meaningful in jurisdictions without a concept of public domain. >> >> The hard part is liberating the parts of the system that are currently = >> >> inder the existing Modula 3 license. They will have to be replaced if = >> >> we can't get the copyright owner to respond usefully. >> >> And that's a lot of work. >> >> -- hendrik >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel From jayk123 at hotmail.com Fri Sep 1 20:19:00 2017 From: jayk123 at hotmail.com (Jay K) Date: Fri, 1 Sep 2017 18:19:00 +0000 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> <239249321.5067398.1503941236042@mail.yahoo.com> <20170828180549.GA14224@topoi.pooq.com> <20170901163022.9B7191A206B@async.async.caltech.edu>, Message-ID: Please no. A relicense would be nice though-- BSD. - Jay ________________________________ From: M3devel on behalf of Darko Volaric Sent: Friday, September 1, 2017 10:08:00 AM To: mika at async.caltech.edu Cc: m3devel at elegosoft.com Subject: Re: [M3devel] On the way to release other packages in GPL? Wait, there is a serious move toward releasing under GPL? Or have I misunderstood this email. > On Sep 1, 2017, at 6:30 PM, mika at async.caltech.edu wrote: > > > Is there some consensus on what precisely needs to be extracted in terms > of a release? The Linux discussion earlier on this list made no sense > to me, it almost sounded like someone was wilfully misinterpreting the > plain English of the legalese. > > Also who is/has been the best lead so far? I can see if I can find > someone through various connections... > > Mika > > Hendrik Boom writes: >> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Benavides D. wro= >> te: >>> Hello:I fear most viable way to keep te language alive is to GPL it . Soo= >> n we wont have the resortes to keep alive. Im not understimating anyone her= >> e. But IMHO is de time to do it.=A0Thanks in advance >> >> Any GPL-compatible license will work. Even MIT. Possibly even the = >> >> so-called Creative Commons variation on public domain, which is = >> >> meaningful in jurisdictions without a concept of public domain. >> >> The hard part is liberating the parts of the system that are currently = >> >> inder the existing Modula 3 license. They will have to be replaced if = >> >> we can't get the copyright owner to respond usefully. >> >> And that's a lot of work. >> >> -- hendrik >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel > _______________________________________________ > M3devel mailing list > M3devel at elegosoft.com > https://m3lists.elegosoft.com/mailman/listinfo/m3devel _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From mika at async.caltech.edu Fri Sep 1 22:59:30 2017 From: mika at async.caltech.edu (mika at async.caltech.edu) Date: Fri, 01 Sep 2017 13:59:30 -0700 Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> <239249321.5067398.1503941236042@mail.yahoo.com> <20170828180549.GA14224@topoi.pooq.com> <20170901163022.9B7191A206B@async.async.caltech.edu>, Message-ID: <20170901205930.427881A206B@async.async.caltech.edu> Yeah I didn't mean to imply anything about GPL (or BSD, even, even though I agree with Jay---I would much prefer that myself, I think that would be an ideal outcome, because you can always incorporate BSD software in a GPL distribution if that is what you want to do). The problem as I see it is that the old SRC license has one or two clauses that make the M3 license effectively "non-free". Someone with legal authority would have to give permission to license the system without those clauses. Ideally just remove them, in which case I seem to remember the license wouldn't be too far from BSD... Mika Jay K writes: >--_000_MWHPR18MB1214FAEB491872008CBDA390E6920MWHPR18MB1214namp_ >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: quoted-printable > >Please no. A relicense would be nice though-- BSD. > >- Jay >________________________________ >From: M3devel on behalf of Darko Volaric ists at darko.org> >Sent: Friday, September 1, 2017 10:08:00 AM >To: mika at async.caltech.edu >Cc: m3devel at elegosoft.com >Subject: Re: [M3devel] On the way to release other packages in GPL? > >Wait, there is a serious move toward releasing under GPL? Or have I misun= >derstood this email. > > >> On Sep 1, 2017, at 6:30 PM, mika at async.caltech.edu wrote: >> >> >> Is there some consensus on what precisely needs to be extracted in terms >> of a release? The Linux discussion earlier on this list made no sense >> to me, it almost sounded like someone was wilfully misinterpreting the >> plain English of the legalese. >> >> Also who is/has been the best lead so far? I can see if I can find >> someone through various connections... >> >> Mika >> >> Hendrik Boom writes: >>> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Benavides D. = >wro=3D >>> te: >>>> Hello:I fear most viable way to keep te language alive is to GPL it . S= >oo=3D >>> n we wont have the resortes to keep alive. Im not understimating anyone = >her=3D >>> e. But IMHO is de time to do it.=3DA0Thanks in advance >>> >>> Any GPL-compatible license will work. Even MIT. Possibly even the =3D >>> >>> so-called Creative Commons variation on public domain, which is =3D >>> >>> meaningful in jurisdictions without a concept of public domain. >>> >>> The hard part is liberating the parts of the system that are currently = >=3D >>> >>> inder the existing Modula 3 license. They will have to be replaced if = >=3D >>> >>> we can't get the copyright owner to respond usefully. >>> >>> And that's a lot of work. >>> >>> -- hendrik >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel > >_______________________________________________ >M3devel mailing list >M3devel at elegosoft.com >https://m3lists.elegosoft.com/mailman/listinfo/m3devel > >--_000_MWHPR18MB1214FAEB491872008CBDA390E6920MWHPR18MB1214namp_ >Content-Type: text/html; charset="us-ascii" >Content-Transfer-Encoding: quoted-printable > > > >> > > > > >
>
rg/EmailMessage" style=3D"direction:ltr"> >ganization"> >
>
Please no. A relicense would be nice though-- = >BSD.
>

>
>
- Jay
>
>
>
>
color=3D"#000000" style=3D"font-size:11pt">From: M3devel <m3devel= >-bounces at elegosoft.com> on behalf of Darko Volaric <lists at darko.org&g= >t;
>Sent: Friday, September 1, 2017 10:08:00 AM
>To: mika at async.caltech.edu
>Cc: m3devel at elegosoft.com
>Subject: Re: [M3devel] On the way to release other packages in GPL?<= >/font> >
 
>
>
> >
Wait, there is a serious move toward releasing und= >er GPL?   Or have I misunderstood this email.
>
>
>> On Sep 1, 2017, at 6:30 PM, mika at async.caltech.edu wrote:
>>
>>
>> Is there some consensus on what precisely needs to be extracted in ter= >ms
>> of a release?  The Linux discussion earlier on this list made no = >sense
>> to me, it almost sounded like someone was wilfully misinterpreting the= >
>> plain English of the legalese.
>>
>> Also who is/has been the best lead so far?  I can see if I can fi= >nd
>> someone through various connections...
>>
>>    Mika
>>
>> Hendrik Boom writes:
>>> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Ben= >avides D. wro=3D
>>> te:
>>>> Hello:I fear most viable way to keep te language alive is to G= >PL it . Soo=3D
>>> n we wont have the resortes to keep alive. Im not understimating a= >nyone her=3D
>>> e. But IMHO is de time to do it.=3DA0Thanks in advance
>>>
>>> Any GPL-compatible license will work.  Even MIT.  Possib= >ly even the =3D
>>>
>>> so-called Creative Commons variation on public domain, which is = >=3D
>>>
>>> meaningful in jurisdictions without a concept of public domain.> >>>
>>> The hard part is liberating the parts of the system that are curre= >ntly =3D
>>>
>>> inder the existing Modula 3 license.  They will have to be re= >placed if =3D
>>>
>>> we can't get the copyright owner to respond usefully.
>>>
>>> And that's a lot of work.
>>>
>>> -- hendrik
>>> _______________________________________________
>>> M3devel mailing list
>>> M3devel at elegosoft.com
>>> >https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> htt= >ps://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
>_______________________________________________
>M3devel mailing list
>M3devel at elegosoft.com
>https://= >m3lists.elegosoft.com/mailman/listinfo/m3devel
>
>
> > > >--_000_MWHPR18MB1214FAEB491872008CBDA390E6920MWHPR18MB1214namp_-- From dabenavidesd at yahoo.es Sun Sep 3 00:29:13 2017 From: dabenavidesd at yahoo.es (Daniel Alejandro Benavides D.) Date: Sat, 2 Sep 2017 22:29:13 +0000 (UTC) Subject: [M3devel] On the way to release other packages in GPL? In-Reply-To: <20170901205930.427881A206B@async.async.caltech.edu> References: <1323059193.3673624.1503775758492.ref@mail.yahoo.com> <1323059193.3673624.1503775758492@mail.yahoo.com> <20170827234046.GB31000@topoi.pooq.com> <8381B1BB-75DE-41D1-8DE1-65B788471E5D@purdue.edu> <239249321.5067398.1503941236042@mail.yahoo.com> <20170828180549.GA14224@topoi.pooq.com> <20170901163022.9B7191A206B@async.async.caltech.edu> <20170901205930.427881A206B@async.async.caltech.edu> Message-ID: <1295668575.2731917.1504391353235@mail.yahoo.com> Hello:DEC SRC involvement in releasing some "buggy code" (see differently from garbage collected programming work DEC SRC did proposals on C++ GC) to be studied: Measurements of small academic programs don't cut it. (Small is anything less than 100,00 lines that runs for less than a few minutes.) Microsoft couldn't care less about a 25,000 line VLSI routing program.?? Getting commercial-scale benchmarks is very hard, not least because vendors treat their applications' source code as family jewels. When I was at DEC SRC, I initiated a project to measure the performance of some large DEC programs modified to use garbage collection, and I got Ben Zorn a research grant that would allow him to use those programs for his own university research. We need more such industry-research cooperation: ftp://ftp.cs.utexas.edu/pub/garbage/GC93/ellis.txt In fact there was a research on ESC project to make manual memory management (memory leaks) in Modula-3 checked by ESC, but it was dismissed, because of complexity of logic (meaning it was feasible but need more hard work). So even we get ever GPL Extended Static Checker Modula-3 code project (<100000 M3 loc) it would be invaluable (and DEC-SRC are mines of gold) to anyone using commercial applications and to us. Thanks in advance El Viernes 1 de septiembre de 2017 16:00, "mika at async.caltech.edu" escribi?: Yeah I didn't mean to imply anything about GPL (or BSD, even, even though I agree with Jay---I would much prefer that myself, I think that would be an ideal outcome, because you can always incorporate BSD software in a GPL distribution if that is what you want to do). The problem as I see it is that the old SRC license has one or two clauses that make the M3 license effectively "non-free".? Someone with legal authority would have to give permission to license the system without those clauses.? Ideally just remove them, in which case I seem to remember the license wouldn't be too far from BSD... ? ? Mika Jay K writes: >--_000_MWHPR18MB1214FAEB491872008CBDA390E6920MWHPR18MB1214namp_ >Content-Type: text/plain; charset="us-ascii" >Content-Transfer-Encoding: quoted-printable > >Please no. A relicense would be nice though-- BSD. > >- Jay >________________________________ >From: M3devel on behalf of Darko Volaric ists at darko.org> >Sent: Friday, September 1, 2017 10:08:00 AM >To: mika at async.caltech.edu >Cc: m3devel at elegosoft.com >Subject: Re: [M3devel] On the way to release other packages in GPL? > >Wait, there is a serious move toward releasing under GPL?? Or have I misun= >derstood this email. > > >> On Sep 1, 2017, at 6:30 PM, mika at async.caltech.edu wrote: >> >> >> Is there some consensus on what precisely needs to be extracted in terms >> of a release?? The Linux discussion earlier on this list made no sense >> to me, it almost sounded like someone was wilfully misinterpreting the >> plain English of the legalese. >> >> Also who is/has been the best lead so far?? I can see if I can find >> someone through various connections... >> >>? ? Mika >> >> Hendrik Boom writes: >>> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Benavides D. = >wro=3D >>> te: >>>> Hello:I fear most viable way to keep te language alive is to GPL it . S= >oo=3D >>> n we wont have the resortes to keep alive. Im not understimating anyone = >her=3D >>> e. But IMHO is de time to do it.=3DA0Thanks in advance >>> >>> Any GPL-compatible license will work.? Even MIT.? Possibly even the =3D >>> >>> so-called Creative Commons variation on public domain, which is =3D >>> >>> meaningful in jurisdictions without a concept of public domain. >>> >>> The hard part is liberating the parts of the system that are currently = >=3D >>> >>> inder the existing Modula 3 license.? They will have to be replaced if = >=3D >>> >>> we can't get the copyright owner to respond usefully. >>> >>> And that's a lot of work. >>> >>> -- hendrik >>> _______________________________________________ >>> M3devel mailing list >>> M3devel at elegosoft.com >>> https://m3lists.elegosoft.com/mailman/listinfo/m3devel >> _______________________________________________ >> M3devel mailing list >> M3devel at elegosoft.com >> https://m3lists.elegosoft.com/mailman/listinfo/m3devel > >_______________________________________________ >M3devel mailing list >M3devel at elegosoft.com >https://m3lists.elegosoft.com/mailman/listinfo/m3devel > >--_000_MWHPR18MB1214FAEB491872008CBDA390E6920MWHPR18MB1214namp_ >Content-Type: text/html; charset="us-ascii" >Content-Transfer-Encoding: quoted-printable > > > >> > > > > >
>
rg/EmailMessage" style=3D"direction:ltr"> >ganization"> >
>
Please no. A relicense would be nice though-- = >BSD.
>

>
>
- Jay
>
>
>
>
color=3D"#000000" style=3D"font-size:11pt">From: M3devel <m3devel= >-bounces at elegosoft.com> on behalf of Darko Volaric <lists at darko.org&g= >t;
>Sent: Friday, September 1, 2017 10:08:00 AM
>To: mika at async.caltech.edu
>Cc: m3devel at elegosoft.com
>Subject: Re: [M3devel] On the way to release other packages in GPL?<= >/font> >
 
>
>
> >
Wait, there is a serious move toward releasing und= >er GPL?   Or have I misunderstood this email.
>
>
>> On Sep 1, 2017, at 6:30 PM, mika at async.caltech.edu wrote:
>>
>>
>> Is there some consensus on what precisely needs to be extracted in ter= >ms
>> of a release?  The Linux discussion earlier on this list made no = >sense
>> to me, it almost sounded like someone was wilfully misinterpreting the= >
>> plain English of the legalese.
>>
>> Also who is/has been the best lead so far?  I can see if I can fi= >nd
>> someone through various connections...
>>
>>    Mika
>>
>> Hendrik Boom writes:
>>> On Mon, Aug 28, 2017 at 05:27:16PM +0000, Daniel Alejandro Ben= >avides D. wro=3D
>>> te:
>>>> Hello:I fear most viable way to keep te language alive is to G= >PL it . Soo=3D
>>> n we wont have the resortes to keep alive. Im not understimating a= >nyone her=3D
>>> e. But IMHO is de time to do it.=3DA0Thanks in advance
>>>
>>> Any GPL-compatible license will work.  Even MIT.  Possib= >ly even the =3D
>>>
>>> so-called Creative Commons variation on public domain, which is = >=3D
>>>
>>> meaningful in jurisdictions without a concept of public domain.> >>>
>>> The hard part is liberating the parts of the system that are curre= >ntly =3D
>>>
>>> inder the existing Modula 3 license.  They will have to be re= >placed if =3D
>>>
>>> we can't get the copyright owner to respond usefully.
>>>
>>> And that's a lot of work.
>>>
>>> -- hendrik
>>> _______________________________________________
>>> M3devel mailing list
>>> M3devel at elegosoft.com
>>> >https://m3lists.elegosoft.com/mailman/listinfo/m3devel
>> _______________________________________________
>> M3devel mailing list
>> M3devel at elegosoft.com
>> htt= >ps://m3lists.elegosoft.com/mailman/listinfo/m3devel
>
>_______________________________________________
>M3devel mailing list
>M3devel at elegosoft.com
>https://= >m3lists.elegosoft.com/mailman/listinfo/m3devel
>
>
> > > >--_000_MWHPR18MB1214FAEB491872008CBDA390E6920MWHPR18MB1214namp_-- _______________________________________________ M3devel mailing list M3devel at elegosoft.com https://m3lists.elegosoft.com/mailman/listinfo/m3devel -------------- next part -------------- An HTML attachment was scrubbed... URL: From rodney_bates at lcwb.coop Sat Sep 23 17:59:37 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sat, 23 Sep 2017 10:59:37 -0500 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) Message-ID: <59d825fa-832d-c945-6334-ea905ba55db7@lcwb.coop> The following didn't come through the first time, at least not to me: Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 Deleted the assertion, which is neither true nor needed. But see below: On 09/16/2017 11:54 PM, jcchu wrote: > See the fragment below. > > VAR r := SET OF [0..31] { 0 }; (* OK *) > s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) Are you aware that the BITS 32 here has no effect on the size of the global variable? Quoting from 2.2.5, Packed types: TYPE T = BITS n FOR Base where Base is a type and n is an integer-valued constant expression. The values of type T are the same as the values of type Base, but variables of type T that occur in records, objects, or arrays ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ will occupy exactly n bits and be packed adjacent to the preceding field or element. s is not inside a record, object, or array, so the BITS specification has no effect on the memory allocated by the compiler. There are, however some more obscure differences: 1) Although T and BITS n FOR T are are assignable to each other, BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability relationship, so to assign one to the other would require two assignment steps, with a T as the intermediate type. 2) Anywhere type equality, as opposed to assignability, is required, T and BITS n FOR T will not match. For example, you cannot pass one of these to the other as a VAR parameter. -- Rodney Bates rodney.m.bates at acm.org From jcchu at acm.org Sun Sep 24 14:04:28 2017 From: jcchu at acm.org (JC Chu) Date: Sun, 24 Sep 2017 12:04:28 +0000 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: Message-ID: > Are you aware that the BITS 32 here has no effect on the size of the global variable? Yes. I was looking for a bit set type that?s guaranteed to have the same representation as some integer type, such as BITS BITSIZE(INTEGER) FOR [0..-1 + BITSIZE(INTEGER)] for INTEGER. But that guarantee doesn?t seem to exist, according to the language definition. Seems like the correct way is to use Word interface (but then Long (the corresponding interface for LONGINT) doesn?t seem to be usable). ? JC From: Rodney M. Bates [mailto:notifications at github.com] Sent: Wednesday, September 20, 2017 5:35 To: modula3/cm3 Cc: jcchu ; Author Subject: Re: [modula3/cm3] Packed set literal generation issue (#21) Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 Deleted the assertion, which is neither true nor needed. But see below: On 09/16/2017 11:54 PM, jcchu wrote: > See the fragment below. > > VAR r := SET OF [0..31] { 0 }; (* OK *) > s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) Are you aware that the BITS 32 here has no effect on the size of the global variable? Quoting from 2.2.5, Packed types: TYPE T = BITS n FOR Base where Base is a type and n is an integer-valued constant expression. The values of type T are the same as the values of type Base, but variables of type T that occur in records, objects, or arrays ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ will occupy exactly n bits and be packed adjacent to the preceding field or element. s is not inside a record, object, or array, so the BITS specification has no effect on the memory allocated by the compiler. There are, however some more obscure differences: 1) Although T and BITS n FOR T are are assignable to each other, BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability relationship, so to assign one to the other would require two assignment steps, with a T as the intermediate type. 2) Anywhere type equality, as opposed to assignability, is required, T and BITS n FOR T will not match. For example, you cannot pass one of these to the other as a VAR parameter. > > ? > You are receiving this because you are subscribed to this thread. > Reply to this email directly, view it on GitHub , or mute the thread . > ? You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub, or mute the thread. -------------- next part -------------- An HTML attachment was scrubbed... URL: -------------- next part -------------- A non-text attachment was scrubbed... Name: image001.jpg Type: image/jpeg Size: 332 bytes Desc: image001.jpg URL: From rodney_bates at lcwb.coop Sun Sep 24 22:59:44 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Sun, 24 Sep 2017 15:59:44 -0500 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: Message-ID: On 09/24/2017 07:04 AM, JC Chu wrote: >> Are you aware that the BITS 32 here has no effect on the size of the global variable? > > > > Yes. I was looking for a bit set type that?s guaranteed to have the same representation as some integer type, such as BITS BITSIZE(INTEGER) FOR [0..-1 + BITSIZE(INTEGER)] for INTEGER. But that guarantee doesn?t seem to exist, according to the language definition. Seems like the correct way is to use Word interface (but then Long (the corresponding interface for LONGINT) doesn?t seem to be usable). > > Yes, the language considers scalar variable sizes (locals, globals, parameters) to be the implementation's business. However, for low-level coding, you can wrap what you want inside a record, usually with only one field, and access the field: TYPE SetT = SET OF [0..31]; TYPE IntSizedSetT = RECORD S : BITS BITSIZE(INTEGER) FOR SetT END; VAR Set := IntSizedSetT { SetT { 0 } }; VAR Int : INTEGER; BEGIN Int := LOOPHOLE(Set.S, INTEGER); END Any mistakes or failure of the size self-adaptation code will give a compile-time error on the LOOPHOLE, due to unequal sizes. I have used this technique a number of times in low-level code to make it self-adapt to different word sizes, and more complicated variations to adapt to different endianness. The compiler and runtime do this in some places. In some other places, they just make assumptions about what the compiler will do that happen to be correct currently, but are not guaranteed. I think not all of them would give compile-time errors if/when the assumptions changed. I have fixed a few of them, but not systematically. I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling. I do use Word.T instead of INTEGER where appropriate in declarations just as documentation of the way they will be used. Otherwise (anyway?) it gets tedious keeping track of when to use '+' and when to use Word.Plus. Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it. This looks easy to fix, but would require thorough vetting to be sure all the various paths in the front and back ends can handle it. BTW, the compiler looks to be padding every record out to a full byte length, which won't affect this technique but limits some other things. Also BTW, in working on the fix of the assertion failure you reported, I find there is another assertion failure when trying to pass BITS n FOR SetT as an actual parameter to a SetT formal.For VALUE and READONLY, this should work, as the types are assignable. > > ? JC > > > > *From:* Rodney M. Bates [mailto:notifications at github.com] > *Sent:* Wednesday, September 20, 2017 5:35 > *To:* modula3/cm3 > *Cc:* jcchu ; Author > *Subject:* Re: [modula3/cm3] Packed set literal generation issue (#21) > > > > Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 > > Deleted the assertion, which is neither true nor needed. > > But see below: > > On 09/16/2017 11:54 PM, jcchu wrote: >> See the fragment below. >> >> VAR r := SET OF [0..31] { 0 }; (* OK *) >> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) > > Are you aware that the BITS 32 here has no effect on the size of the global variable? > > Quoting from 2.2.5, Packed types: > > TYPE T = BITS n FOR Base > > where Base is a type and n is an integer-valued constant expression. > The values of type T are the same as the values of type Base, but variables of type T > that occur in records, objects, or arrays > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > will occupy exactly n bits and be packed adjacent to the preceding field or element. > > s is not inside a record, object, or array, so the BITS specification has no effect on > the memory allocated by the compiler. > > There are, however some more obscure differences: > > 1) Although T and BITS n FOR T are are assignable to each other, > BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability > relationship, so to assign one to the other would require two assignment > steps, with a T as the intermediate type. > > 2) Anywhere type equality, as opposed to assignability, is required, T and > BITS n FOR T will not match. For example, you cannot pass one of these to > the other as a VAR parameter. > > > > > >> >> ? >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub , or mute the thread . >> > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub , or mute the thread .Image removed by sender. > -- Rodney Bates rodney.m.bates at acm.org From jcchu at acm.org Mon Sep 25 13:25:01 2017 From: jcchu at acm.org (JC Chu) Date: Mon, 25 Sep 2017 11:25:01 +0000 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: Message-ID: > I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling. I was really more concerned about the bit layout of sets: just which bit of SET OF [0..31] {0} should be 1? We know it?s supposed to be whichever bit that represents the first element of ARRAY [0..31] OF BITS 1 FOR BOOLEAN, but the language definition doesn?t tell us that, either. So in the end I guess sets are just sets, suitable when you want a?nice syntax and don?t have to care about the representation. Bit sets as used in other languages are really words, whose bits can be inspected and manipulated by using Word.Extract and Word.Insert, respectively. > Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it. That?s weird. Here on my host INTEGER and LONGINT are 32- and 64-bit, respectively, and the type BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] is accepted, and 64 bits and 8 bytes in size. The type BITS 24 FOR [0..16777215] is also valid, and 24 bits and 3 bytes in size. (On the other hand, the type RECORD s: BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] END is unaccepted, which I think is allowed by the language definition.) ??JC -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Monday, September 25, 2017 5:00 To: JC Chu ; modula3/cm3 Cc: rodney.m.bates at acm.org; m3devel at elegosoft.com Subject: Re: [modula3/cm3] Packed set literal generation issue (#21) On 09/24/2017 07:04 AM, JC Chu wrote: >> Are you aware that the BITS 32 here has no effect on the size of the global variable? > > > > Yes. I was looking for a bit set type that?s guaranteed to have the same representation as some integer type, such as BITS BITSIZE(INTEGER) FOR [0..-1 + BITSIZE(INTEGER)] for INTEGER. But that guarantee doesn?t seem to exist, according to the language definition. Seems like the correct way is to use Word interface (but then Long (the corresponding interface for LONGINT) doesn?t seem to be usable). > > Yes, the language considers scalar variable sizes (locals, globals, parameters) to be the implementation's business. However, for low-level coding, you can wrap what you want inside a record, usually with only one field, and access the field: TYPE SetT = SET OF [0..31]; TYPE IntSizedSetT = RECORD S : BITS BITSIZE(INTEGER) FOR SetT END; VAR Set := IntSizedSetT { SetT { 0 } }; VAR Int : INTEGER; BEGIN Int := LOOPHOLE(Set.S, INTEGER); END Any mistakes or failure of the size self-adaptation code will give a compile-time error on the LOOPHOLE, due to unequal sizes. I have used this technique a number of times in low-level code to make it self-adapt to different word sizes, and more complicated variations to adapt to different endianness. The compiler and runtime do this in some places. In some other places, they just make assumptions about what the compiler will do that happen to be correct currently, but are not guaranteed. I think not all of them would give compile-time errors if/when the assumptions changed. I have fixed a few of them, but not systematically. I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling. I do use Word.T instead of INTEGER where appropriate in declarations just as documentation of the way they will be used. Otherwise (anyway?) it gets tedious keeping track of when to use '+' and when to use Word.Plus. Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it. This looks easy to fix, but would require thorough vetting to be sure all the various paths in the front and back ends can handle it. BTW, the compiler looks to be padding every record out to a full byte length, which won't affect this technique but limits some other things. Also BTW, in working on the fix of the assertion failure you reported, I find there is another assertion failure when trying to pass BITS n FOR SetT as an actual parameter to a SetT formal.For VALUE and READONLY, this should work, as the types are assignable. > > ? JC > > > > *From:* Rodney M. Bates [mailto:notifications at github.com] > *Sent:* Wednesday, September 20, 2017 5:35 > *To:* modula3/cm3 > *Cc:* jcchu ; Author > *Subject:* Re: [modula3/cm3] Packed set literal generation issue (#21) > > > > Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 > > Deleted the assertion, which is neither true nor needed. > > But see below: > > On 09/16/2017 11:54 PM, jcchu wrote: >> See the fragment below. >> >> VAR r := SET OF [0..31] { 0 }; (* OK *) >> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) > > Are you aware that the BITS 32 here has no effect on the size of the global variable? > > Quoting from 2.2.5, Packed types: > > TYPE T = BITS n FOR Base > > where Base is a type and n is an integer-valued constant expression. > The values of type T are the same as the values of type Base, but variables of type T > that occur in records, objects, or arrays > ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ > will occupy exactly n bits and be packed adjacent to the preceding field or element. > > s is not inside a record, object, or array, so the BITS specification has no effect on > the memory allocated by the compiler. > > There are, however some more obscure differences: > > 1) Although T and BITS n FOR T are are assignable to each other, > BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability > relationship, so to assign one to the other would require two assignment > steps, with a T as the intermediate type. > > 2) Anywhere type equality, as opposed to assignability, is required, T and > BITS n FOR T will not match. For example, you cannot pass one of these to > the other as a VAR parameter. > > > > > >> >> ? >> You are receiving this because you are subscribed to this thread. >> Reply to this email directly, view it on GitHub , or mute the thread . >> > > ? > You are receiving this because you authored the thread. > Reply to this email directly, view it on GitHub , or mute the thread .Image removed by sender. > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Mon Sep 25 18:14:42 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Mon, 25 Sep 2017 11:14:42 -0500 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: Message-ID: <4b516f1c-4b61-cf47-1465-90f8bb2f8a87@lcwb.coop> On 09/25/2017 06:25 AM, JC Chu wrote: >> I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling. > > I was really more concerned about the bit layout of sets: just which bit of SET OF [0..31] {0} should be 1? We know it?s supposed to be whichever bit that represents the first element of ARRAY [0..31] OF BITS 1 FOR BOOLEAN, but the language definition doesn?t tell us that, either. > > So in the end I guess sets are just sets, suitable when you want a nice syntax and don?t have to care about the representation. Yes, Most of Modula3's builtin types are more abstract in a few ways than in many languages. > Bit sets as used in other languages are really words, whose bits can be inspected and manipulated by using Word.Extract and Word.Insert, respectively. But you can alternatively do it with bit twiddling in Modula3 too, but the language is inviting you to use the more abstract types and operators. If you use low-level techniques, there are going to be a lot more things to address in source code to make things independent of word size and endianness. I have written a fair amount of code like this, and it requires a *lot* of attention to details that you could forget about otherwise >> Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it. > > That?s weird. Here on my host INTEGER and LONGINT are 32- and 64-bit, respectively, and the type BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] is accepted, and 64 bits and 8 bytes in size.The type BITS 24 FOR [0..16777215] is also valid, and 24 bits and 3 bytes in size. (On the other hand, the type RECORD s: BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] END is unaccepted, which I think is allowed by the language definition.) > From 2.2.5: The values allowed for n are implementation-dependent. An illegal value for n is a static error. The legality of a packed type can depend on its context; for example, an implementation could prohibit packed integers from spanning word boundaries. So the language pretty much allows a compiler to refuse anything it doesn't want to do, as long as it gives a compile error. Probably it accepts the BITS 64 for a scalar (which it is not required to actually honor, but not inside a record, where it honoring it would entail spanning a word boundary. Just my speculative attempt to read the original compiler developers' minds. > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 25, 2017 5:00 > To: JC Chu ; modula3/cm3 > Cc: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [modula3/cm3] Packed set literal generation issue (#21) > > > > On 09/24/2017 07:04 AM, JC Chu wrote: >>> Are you aware that the BITS 32 here has no effect on the size of the global variable? >> >> >> >> Yes. I was looking for a bit set type that?s guaranteed to have the same representation as some integer type, such as BITS BITSIZE(INTEGER) FOR [0..-1 + BITSIZE(INTEGER)] for INTEGER. But that guarantee doesn?t seem to exist, according to the language definition. Seems like the correct way is to use Word interface (but then Long (the corresponding interface for LONGINT) doesn?t seem to be usable). >> >> > > Yes, the language considers scalar variable sizes (locals, globals, parameters) to be > the implementation's business. However, for low-level coding, you can wrap what you > want inside a record, usually with only one field, and access the field: > > TYPE SetT = SET OF [0..31]; > TYPE IntSizedSetT = RECORD S : BITS BITSIZE(INTEGER) FOR SetT END; > VAR Set := IntSizedSetT { SetT { 0 } }; > VAR Int : INTEGER; > > BEGIN > Int := LOOPHOLE(Set.S, INTEGER); > END > > Any mistakes or failure of the size self-adaptation code will give a > compile-time error on the LOOPHOLE, due to unequal sizes. > > I have used this technique a number of times in low-level code to make > it self-adapt to different word sizes, and more complicated variations > to adapt to different endianness. The compiler and runtime do this in > some places. In some other places, they just make assumptions about > what the compiler will do that happen to be correct currently, but are > not guaranteed. I think not all of them would give compile-time errors > if/when the assumptions changed. I have fixed a few of them, but not > systematically. > > I don't think Word and Long will help, since, as far as types are concerned, > Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators > that apply unsigned interpretation to the bits and do other bit-twiddling. > I do use Word.T instead of INTEGER where appropriate in declarations just > as documentation of the way they will be used. Otherwise (anyway?) it gets > tedious keeping track of when to use '+' and when to use Word.Plus. > > Unfortunately, the compiler currently insists every set must be a full native > INTEGER size, whether you try to size it yourself with BITS or let the > compiler do it. This looks easy to fix, but would require thorough vetting > to be sure all the various paths in the front and back ends can handle it. > > BTW, the compiler looks to be padding every record out to a full byte > length, which won't affect this technique but limits some other things. > > Also BTW, in working on the fix of the assertion failure you reported, > I find there is another assertion failure when trying to pass > BITS n FOR SetT as an actual parameter to a SetT formal.For VALUE and > READONLY, this should work, as the types are assignable. > > >> >> ? JC >> >> >> >> *From:* Rodney M. Bates [mailto:notifications at github.com] >> *Sent:* Wednesday, September 20, 2017 5:35 >> *To:* modula3/cm3 >> *Cc:* jcchu ; Author >> *Subject:* Re: [modula3/cm3] Packed set literal generation issue (#21) >> >> >> >> Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 >> >> Deleted the assertion, which is neither true nor needed. >> >> But see below: >> >> On 09/16/2017 11:54 PM, jcchu wrote: >>> See the fragment below. >>> >>> VAR r := SET OF [0..31] { 0 }; (* OK *) >>> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) >> >> Are you aware that the BITS 32 here has no effect on the size of the global variable? >> >> Quoting from 2.2.5, Packed types: >> >> TYPE T = BITS n FOR Base >> >> where Base is a type and n is an integer-valued constant expression. >> The values of type T are the same as the values of type Base, but variables of type T >> that occur in records, objects, or arrays >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> will occupy exactly n bits and be packed adjacent to the preceding field or element. >> >> s is not inside a record, object, or array, so the BITS specification has no effect on >> the memory allocated by the compiler. >> >> There are, however some more obscure differences: >> >> 1) Although T and BITS n FOR T are are assignable to each other, >> BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability >> relationship, so to assign one to the other would require two assignment >> steps, with a T as the intermediate type. >> >> 2) Anywhere type equality, as opposed to assignability, is required, T and >> BITS n FOR T will not match. For example, you cannot pass one of these to >> the other as a VAR parameter. >> >> >> >> >> >>> >>> ? >>> You are receiving this because you are subscribed to this thread. >>> Reply to this email directly, view it on GitHub , or mute the thread . >>> >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub , or mute the thread .Image removed by sender. >> > -- Rodney Bates rodney.m.bates at acm.org From jcchu at acm.org Tue Sep 26 13:03:21 2017 From: jcchu at acm.org (JC Chu) Date: Tue, 26 Sep 2017 11:03:21 +0000 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: <4b516f1c-4b61-cf47-1465-90f8bb2f8a87@lcwb.coop> References: <4b516f1c-4b61-cf47-1465-90f8bb2f8a87@lcwb.coop> Message-ID: > If you use low-level techniques, there are going to be a lot more things to address in source code to make things independent of word size and endianness. I suppose you?re also going to have to deal with native byte sizes and addressing unit sizes... Also, what did you mean when you previously mentioned ?more complicated variations to adapt to different endianness?? ??JC -----Original Message----- From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] Sent: Tuesday, September 26, 2017 0:15 To: JC Chu ; rodney.m.bates at acm.org Cc: m3devel at elegosoft.com Subject: Re: [modula3/cm3] Packed set literal generation issue (#21) On 09/25/2017 06:25 AM, JC Chu wrote: >> I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling. > > I was really more concerned about the bit layout of sets: just which bit of SET OF [0..31] {0} should be 1? We know it?s supposed to be whichever bit that represents the first element of ARRAY [0..31] OF BITS 1 FOR BOOLEAN, but the language definition doesn?t tell us that, either. > > So in the end I guess sets are just sets, suitable when you want a nice syntax and don?t have to care about the representation. Yes, Most of Modula3's builtin types are more abstract in a few ways than in many languages. > Bit sets as used in other languages are really words, whose bits can be inspected and manipulated by using Word.Extract and Word.Insert, respectively. But you can alternatively do it with bit twiddling in Modula3 too, but the language is inviting you to use the more abstract types and operators. If you use low-level techniques, there are going to be a lot more things to address in source code to make things independent of word size and endianness. I have written a fair amount of code like this, and it requires a *lot* of attention to details that you could forget about otherwise >> Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it. > > That?s weird. Here on my host INTEGER and LONGINT are 32- and 64-bit, respectively, and the type BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] is accepted, and 64 bits and 8 bytes in size.The type BITS 24 FOR [0..16777215] is also valid, and 24 bits and 3 bytes in size. (On the other hand, the type RECORD s: BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] END is unaccepted, which I think is allowed by the language definition.) > From 2.2.5: The values allowed for n are implementation-dependent. An illegal value for n is a static error. The legality of a packed type can depend on its context; for example, an implementation could prohibit packed integers from spanning word boundaries. So the language pretty much allows a compiler to refuse anything it doesn't want to do, as long as it gives a compile error. Probably it accepts the BITS 64 for a scalar (which it is not required to actually honor, but not inside a record, where it honoring it would entail spanning a word boundary. Just my speculative attempt to read the original compiler developers' minds. > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Monday, September 25, 2017 5:00 > To: JC Chu ; modula3/cm3 > Cc: rodney.m.bates at acm.org; m3devel at elegosoft.com > Subject: Re: [modula3/cm3] Packed set literal generation issue (#21) > > > > On 09/24/2017 07:04 AM, JC Chu wrote: >>> Are you aware that the BITS 32 here has no effect on the size of the global variable? >> >> >> >> Yes. I was looking for a bit set type that?s guaranteed to have the same representation as some integer type, such as BITS BITSIZE(INTEGER) FOR [0..-1 + BITSIZE(INTEGER)] for INTEGER. But that guarantee doesn?t seem to exist, according to the language definition. Seems like the correct way is to use Word interface (but then Long (the corresponding interface for LONGINT) doesn?t seem to be usable). >> >> > > Yes, the language considers scalar variable sizes (locals, globals, parameters) to be > the implementation's business. However, for low-level coding, you can wrap what you > want inside a record, usually with only one field, and access the field: > > TYPE SetT = SET OF [0..31]; > TYPE IntSizedSetT = RECORD S : BITS BITSIZE(INTEGER) FOR SetT END; > VAR Set := IntSizedSetT { SetT { 0 } }; > VAR Int : INTEGER; > > BEGIN > Int := LOOPHOLE(Set.S, INTEGER); > END > > Any mistakes or failure of the size self-adaptation code will give a > compile-time error on the LOOPHOLE, due to unequal sizes. > > I have used this technique a number of times in low-level code to make > it self-adapt to different word sizes, and more complicated variations > to adapt to different endianness. The compiler and runtime do this in > some places. In some other places, they just make assumptions about > what the compiler will do that happen to be correct currently, but are > not guaranteed. I think not all of them would give compile-time errors > if/when the assumptions changed. I have fixed a few of them, but not > systematically. > > I don't think Word and Long will help, since, as far as types are concerned, > Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators > that apply unsigned interpretation to the bits and do other bit-twiddling. > I do use Word.T instead of INTEGER where appropriate in declarations just > as documentation of the way they will be used. Otherwise (anyway?) it gets > tedious keeping track of when to use '+' and when to use Word.Plus. > > Unfortunately, the compiler currently insists every set must be a full native > INTEGER size, whether you try to size it yourself with BITS or let the > compiler do it. This looks easy to fix, but would require thorough vetting > to be sure all the various paths in the front and back ends can handle it. > > BTW, the compiler looks to be padding every record out to a full byte > length, which won't affect this technique but limits some other things. > > Also BTW, in working on the fix of the assertion failure you reported, > I find there is another assertion failure when trying to pass > BITS n FOR SetT as an actual parameter to a SetT formal.For VALUE and > READONLY, this should work, as the types are assignable. > > >> >> ? JC >> >> >> >> *From:* Rodney M. Bates [mailto:notifications at github.com] >> *Sent:* Wednesday, September 20, 2017 5:35 >> *To:* modula3/cm3 >> *Cc:* jcchu ; Author >> *Subject:* Re: [modula3/cm3] Packed set literal generation issue (#21) >> >> >> >> Fixed on github, commit 12f50b4cde746056b943bd8aaa105c3fcb46b1a8 >> >> Deleted the assertion, which is neither true nor needed. >> >> But see below: >> >> On 09/16/2017 11:54 PM, jcchu wrote: >>> See the fragment below. >>> >>> VAR r := SET OF [0..31] { 0 }; (* OK *) >>> s := BITS 32 FOR SET OF [0..31] { 0 }; (* -- assertion failure in ?SetExpr.m3? *) >> >> Are you aware that the BITS 32 here has no effect on the size of the global variable? >> >> Quoting from 2.2.5, Packed types: >> >> TYPE T = BITS n FOR Base >> >> where Base is a type and n is an integer-valued constant expression. >> The values of type T are the same as the values of type Base, but variables of type T >> that occur in records, objects, or arrays >> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ >> will occupy exactly n bits and be packed adjacent to the preceding field or element. >> >> s is not inside a record, object, or array, so the BITS specification has no effect on >> the memory allocated by the compiler. >> >> There are, however some more obscure differences: >> >> 1) Although T and BITS n FOR T are are assignable to each other, >> BITS n FOR T and BITS m FOR T, (n#m) have no subtype or assignability >> relationship, so to assign one to the other would require two assignment >> steps, with a T as the intermediate type. >> >> 2) Anywhere type equality, as opposed to assignability, is required, T and >> BITS n FOR T will not match. For example, you cannot pass one of these to >> the other as a VAR parameter. >> >> >> >> >> >>> >>> ? >>> You are receiving this because you are subscribed to this thread. >>> Reply to this email directly, view it on GitHub , or mute the thread . >>> >> >> ? >> You are receiving this because you authored the thread. >> Reply to this email directly, view it on GitHub , or mute the thread .Image removed by sender. >> > -- Rodney Bates rodney.m.bates at acm.org From rodney_bates at lcwb.coop Wed Sep 27 19:39:17 2017 From: rodney_bates at lcwb.coop (Rodney M. Bates) Date: Wed, 27 Sep 2017 12:39:17 -0500 Subject: [M3devel] [modula3/cm3] Packed set literal generation issue (#21) In-Reply-To: References: <4b516f1c-4b61-cf47-1465-90f8bb2f8a87@lcwb.coop> Message-ID: <44bead5b-bdf1-dc2d-7703-16679207729c@lcwb.coop> On 09/26/2017 06:03 AM, JC Chu wrote: >> If you use low-level techniques, there are going to be a lot more things to address in source code to make things independent of word size and endianness. > > I suppose you?re also going to have to deal with native byte sizes and addressing unit sizes... > > Also, what did you mean when you previously mentioned ?more complicated variations to adapt to different endianness?? > For extreme examples, look in m3-libs/ordsets/ordsets/src/OrdSets.mg, particularly SetSpecialRead. Here, the code has to take into account the word size and endianness of both the machine it is executing on and of the machine that wrote the pickle, in addition to properties of the somewhat complex dynamic set data structure. Or look in m3-libs/libm3/pickle/src/ver2/Pickle2.m3, PickleStubs.m3, and especially ConvertPacking.m3. Or m3-libs/libunicode/src/UnsafeUniCodec.m3 > ? JC > > -----Original Message----- > From: Rodney M. Bates [mailto:rodney_bates at lcwb.coop] > Sent: Tuesday, September 26, 2017 0:15 > To: JC Chu ; rodney.m.bates at acm.org > Cc: m3devel at elegosoft.com > Subject: Re: [modula3/cm3] Packed set literal generation issue (#21) > > > > On 09/25/2017 06:25 AM, JC Chu wrote: >>> I don't think Word and Long will help, since, as far as types are concerned, Word.T = INTEGER and Long.T = LONGINT. They mainly just provide operators that apply unsigned interpretation to the bits and do other bit-twiddling. >> >> I was really more concerned about the bit layout of sets: just which bit of SET OF [0..31] {0} should be 1? We know it?s supposed to be whichever bit that represents the first element of ARRAY [0..31] OF BITS 1 FOR BOOLEAN, but the language definition doesn?t tell us that, either. >> >> So in the end I guess sets are just sets, suitable when you want a nice syntax and don?t have to care about the representation. > > Yes, Most of Modula3's builtin types are more abstract in a few ways than in many > languages. > >> Bit sets as used in other languages are really words, whose bits can be inspected and manipulated by using Word.Extract and Word.Insert, respectively. > > But you can alternatively do it with bit twiddling in Modula3 too, but the language > is inviting you to use the more abstract types and operators. If you use low-level > techniques, there are going to be a lot more things to address in source code to make > things independent of word size and endianness. I have written a fair amount of code > like this, and it requires a *lot* of attention to details that you could forget about > otherwise > > >>> Unfortunately, the compiler currently insists every set must be a full native INTEGER size, whether you try to size it yourself with BITS or let the compiler do it. >> >> That?s weird. Here on my host INTEGER and LONGINT are 32- and 64-bit, respectively, and the type BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] is accepted, and 64 bits and 8 bytes in size.The type BITS 24 FOR [0..16777215] is also valid, and 24 bits and 3 bytes in size. (On the other hand, the type RECORD s: BITS BITSIZE(LONGINT) FOR [0..-1 + BITSIZE(LONGINT)] END is unaccepted, which I think is allowed by the language definition.) >> > > From 2.2.5: > > The values allowed for n are implementation-dependent. An illegal value for n is a static error. > The legality of a packed type can depend on its context; for example, an implementation could > prohibit packed integers from spanning word boundaries. > > So the language pretty much allows a compiler to refuse anything it doesn't want to do, as long > as it gives a compile error. Probably it accepts the BITS 64 for a scalar (which it is not required > to actually honor, but not inside a record, where it honoring it would entail spanning a word > boundary. Just my speculative attempt to read the original compiler developers' minds. > -- Rodney Bates rodney.m.bates at acm.org