Re: Evaluating functor application only once
"'Phil Clayton' via MLton-user" <[email protected]> Sun, 22 Dec 2019 01:39:22 +0000
| Newsgroups | gmane.comp.lang.ml.mlton.user |
|---|---|
| Message-ID | <[email protected]> |
This is a multi-part message in MIME format. --===============0298534281317648436== Content-Type: multipart/alternative; boundary="------------956B9BACD3F5B8BEC8574792" Content-Language: en-GB This is a multi-part message in MIME format. --------------956B9BACD3F5B8BEC8574792 Content-Type: text/plain; charset="UTF-8"; format=flowed Content-Transfer-Encoding: quoted-printable On 21/12/19 21:02, Matthew Fluet wrote: > On Sat, Dec 21, 2019 at 1:15 PM Phil Clayton via MLton-user=20 > <[email protected]=20 > <mailto:[email protected]>> wrote: > > On 04/04/19 11:15, Matthew Fluet wrote: > > On Thu, Apr 4, 2019 at 3:18 AM Phil Clayton > <[email protected] <mailto:[email protected]> > > <mailto:[email protected] > <mailto:[email protected]>>> wrote: > > > >=C2=A0 =C2=A0 =C2=A0In the absence of applicative functors, I am try= ing to > ensure that > >=C2=A0 =C2=A0 =C2=A0certain functors are applied only once.=C2=A0 (W= ithout going into > too much > >=C2=A0 =C2=A0 =C2=A0detail, the issue is that a library that needs e= .g. > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0structure GUInt8Array =3D CArray(GU= Int8) > >=C2=A0 =C2=A0 =C2=A0can't know whether another library has already i= ntroduced > the same > >=C2=A0 =C2=A0 =C2=A0structure.) > > > >=C2=A0 =C2=A0 =C2=A0My approach is to have the functor application i= n its own > SML file: > > > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0<Name>.sml > >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0structure <Name> =3D F(X) > > > >=C2=A0 =C2=A0 =C2=A0With Poly/ML, which doesn't support MLB files, I= can have a > >=C2=A0 =C2=A0 =C2=A0variant of > >=C2=A0 =C2=A0 =C2=A0"use" that only processes a file <Name>.sml if t= here is no > existing > >=C2=A0 =C2=A0 =C2=A0structure <Name>. > > > >=C2=A0 =C2=A0 =C2=A0With MLB files, I plan to also introduce <Name>.= mlb (which > >=C2=A0 =C2=A0 =C2=A0contains only > >=C2=A0 =C2=A0 =C2=A0<Name>.sml) and refer to that, so that it won't = have any > effect if > >=C2=A0 =C2=A0 =C2=A0another library has already evaluated <Name>.mlb= . What I am > doing is > >=C2=A0 =C2=A0 =C2=A0inherently complier-specific, so I wondered - is= there is > any other > >=C2=A0 =C2=A0 =C2=A0MLton-specific way of achieving the same thing, = e.g. MLB > extension? > > > > > > No.=C2=A0 Your plan to use <Name>.mlb would be my suggestion; the > semantics > > of MLB files to evaluate a <file>.mlb exactly once is precisely to > > support this style of "one definition". > This is not working out as simply as I had hoped: <Name>.mlb can't > contain just <Name>.sml, it must also contain the dependencies of > <Name>.sml.=C2=A0 To avoid evaluating dependencies more than once, it > is my > understanding that they need their own MLB files and we end up in a > situation where every SML file needs its own MLB file, which is > pretty > ugly.=C2=A0 Or have I misunderstood the semantics of MLB files? > > > No, you aren't necessarily misunderstanding the semantics of MLB=20 > files. Every MLB file must be closed (self-contained).=C2=A0 So, if you= =20 > trying to model very fine grained dependencies, then yes, you may end=20 > up with a MLB file per SML file.=C2=A0 The expectation is that one would= =20 > have an MLB file per "library" (a group of related modules). Thanks for confirming. > It's unfortunate that MLB files don't support conditional compilation > like CM files.=C2=A0 Achieving 'one definition' would have been simpl= e > if we > could write something like > > =C2=A0=C2=A0 if not (defined (structure S)) > =C2=A0=C2=A0 then > =C2=A0=C2=A0=C2=A0=C2=A0 <basdec> > =C2=A0=C2=A0 end > > > I don't understand how this would help.=C2=A0 CM files are also required = to=20 > be closed (self-contained).=C2=A0 And, even if MLB files did support this= =20 > kind of conditional compilation, unless each module that might need to=20 > define the structure S also exported the structure S, then later=20 > modules would not necessarily "see" that the structure S is defined. You're right, it doesn't help!=C2=A0 I think the capability I was actually= =20 looking for was a way for an MLB file to declare that it inherits a=20 structure from its environment with the option to provide a definition=20 if the structure doesn't exist in the initial environment, where that=20 structure may be exported by the MLB file and, if the structure is=20 exported, the export is suppressed if the structure existed in the=20 initial environment (so there is no effect on the enclosing environment=20 in that case).=C2=A0 Perhaps better syntax for this would be =C2=A0 with structure <strid> =C2=A0[orelse <basdec>] =C2=A0 end (This is not a well thought through proposal.=C2=A0 Possibly a horrible=20 kludge if it could even work at all.) > I do agree that SML (and CM and MLB) files deviate somewhat from other=20 > languages in their treatment of "import"-like declarations.=C2=A0 I do fi= nd=20 > that students sometimes find SML source code confusing, because when=20 > they encounter a structure/identifier that isn't defined in the file,=20 > they cannot just jump to the beginning of the file and look at the=20 > various "import" declarations to determine where the=20 > structure/identifier might be coming from.=C2=A0 Instead, they need to ju= mp=20 > to the CM/MLB file that contains the source SML file and then piece=20 > together the imports from the CM/MLB file. > > I have thought that perhaps we should have an extended MLB format that=20 > allows the inclusion of SML code after an import prelude and before an=20 > export postlude; then at least the SML and MLB code would be in the=20 > same file.=C2=A0 One of my past students tried out a simple surface-level= =20 > pre-processor to give this kind of behavior; see=20 > https://github.com/myegorov/transmler. Interesting idea.=C2=A0 Allowing imports/exports in the source files=20 themselves would avoid the sea of MLB files.=C2=A0 I have some initial=20 thoughts about how native support for such 'SMLB' files would work in my=20 situation: 1. The separate MLB files are, in principle, compiler agnostic (if I were to replace "mlton" by $(COMPILER) to allow other compilers) whereas the SML files defining structures (which use FFI features) are not typically.=C2=A0 These SML files would become compiler-specific SMLB files, so the imports/exports would be duplicated for each compiler.=C2=A0 However that is not a practical issue in my case becaus= e the files are all automatically generated and the duplication overhead is not significant. 2. As a matter of principle, I have ensured that the SML files defining signatures are common to all SML compilers (just Poly/ML and MLton for now).=C2=A0 Using SMLB files for these SML files could only be used if SMLB files were supported by all compilers (or that principle were abandoned).=C2=A0 To that end, perhaps this is a proposal for successor ML? --=20 To unsubscribe from this group and stop receiving emails from it, send an e= mail to [email protected]. --------------956B9BACD3F5B8BEC8574792 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable <html> <head> <meta http-equiv=3D"Content-Type" content=3D"text/html; charset=3Dutf-8= "> </head> <body text=3D"#000000" bgcolor=3D"#FFFFFF"> <div class=3D"moz-cite-prefix">On 21/12/19 21:02, Matthew Fluet wrote:<= br> </div> <blockquote type=3D"cite" cite=3D"mid:[email protected]= l.com"> <div dir=3D"ltr"> <div dir=3D"ltr"> <div class=3D"gmail_default" style=3D"font-family:courier new,monospace;font-size:large"><span style=3D"font-family:Arial,Helvetica,sans-serif;font-size:sma= ll">On Sat, Dec 21, 2019 at 1:15 PM Phil Clayton via MLton-user <<a href=3D"mailto:[email protected]" moz-do-not-send=3D"true">[email protected]</= a>> wrote:</span><br> </div> </div> <div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 04/04/19 11:15, Matthew Fluet wrote:<br> > On Thu, Apr 4, 2019 at 3:18 AM Phil Clayton <<a href=3D"mailto:[email protected]" target=3D"_blank" moz-do-not-send=3D"true">[email protected]</a> <br> > <mailto:<a href=3D"mailto:[email protected]" target=3D"_blank" moz-do-not-send=3D"true">phil.clayton@veoni= x.com</a>>> wrote:<br> ><br> >=C2=A0 =C2=A0 =C2=A0In the absence of applicative functors,= I am trying to ensure that<br> >=C2=A0 =C2=A0 =C2=A0certain functors are applied only once.= =C2=A0 (Without going into too much<br> >=C2=A0 =C2=A0 =C2=A0detail, the issue is that a library tha= t needs e.g.<br> >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0structure GUInt8Array =3D = CArray(GUInt8)<br> >=C2=A0 =C2=A0 =C2=A0can't know whether another library has = already introduced the same<br> >=C2=A0 =C2=A0 =C2=A0structure.)<br> ><br> >=C2=A0 =C2=A0 =C2=A0My approach is to have the functor appl= ication in its own SML file:<br> ><br> >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0<Name>.sml<br> >=C2=A0 =C2=A0 =C2=A0=C2=A0 =C2=A0 =C2=A0structure <Name&= gt; =3D F(X)<br> ><br> >=C2=A0 =C2=A0 =C2=A0With Poly/ML, which doesn't support MLB= files, I can have a<br> >=C2=A0 =C2=A0 =C2=A0variant of<br> >=C2=A0 =C2=A0 =C2=A0"use" that only processes a file <Na= me>.sml if there is no existing<br> >=C2=A0 =C2=A0 =C2=A0structure <Name>.<br> ><br> >=C2=A0 =C2=A0 =C2=A0With MLB files, I plan to also introduc= e <Name>.mlb (which<br> >=C2=A0 =C2=A0 =C2=A0contains only<br> >=C2=A0 =C2=A0 =C2=A0<Name>.sml) and refer to that, so= that it won't have any effect if<br> >=C2=A0 =C2=A0 =C2=A0another library has already evaluated <Name>.mlb. What I am doing is<br> >=C2=A0 =C2=A0 =C2=A0inherently complier-specific, so I wond= ered - is there is any other<br> >=C2=A0 =C2=A0 =C2=A0MLton-specific way of achieving the sam= e thing, e.g. MLB extension?<br> ><br> ><br> > No.=C2=A0 Your plan to use <Name>.mlb would be my suggestion; the semantics <br> > of MLB files to evaluate a <file>.mlb exactly once is precisely to <br> > support this style of "one definition".<br> This is not working out as simply as I had hoped: <Name>.mlb can't <br> contain just <Name>.sml, it must also contain the dependencies of <br> <Name>.sml.=C2=A0 To avoid evaluating dependencies more than once, it is my <br> understanding that they need their own MLB files and we end up in a <br> situation where every SML file needs its own MLB file, which is pretty <br> ugly.=C2=A0 Or have I misunderstood the semantics of MLB files?= <br> <br> </blockquote> <div><br> </div> <div> <div class=3D"gmail_default" style=3D"font-family:"courier new",monospace;font-size:large">No, you aren't necessarily misunderstanding the semantics of MLB files.=C2= =A0 Every MLB file must be closed (self-contained).=C2=A0 So, if you trying to model very fine grained dependencies, then yes, you may end up with a MLB file per SML file.=C2=A0 The expectation is that one would have an MLB file per "library" (a group of related modules).</div> </div> </div> </div> </blockquote> Thanks for confirming.<br> <br> <blockquote type=3D"cite" cite=3D"mid:[email protected]= l.com"> <div dir=3D"ltr"> <div class=3D"gmail_quote"> <blockquote class=3D"gmail_quote" style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">It's unfortunate that MLB files don't support conditional compilation <br> like CM files.=C2=A0 Achieving 'one definition' would have been simple if we <br> could write something like<br> <br> =C2=A0=C2=A0 if not (defined (structure S))<br> =C2=A0=C2=A0 then<br> =C2=A0=C2=A0=C2=A0=C2=A0 <basdec><br> =C2=A0=C2=A0 end<br> </blockquote> <div><br> </div> <div class=3D"gmail_default" style=3D"font-family:"courier new",monospace;font-size:large">I don't understand how this would help.=C2=A0 CM files are also required to be closed (self-contained).=C2=A0 And, even if MLB files did support this kind of conditional compilation, unless each module that might need to define the structure S also exported the structure S, then later modules would not necessarily "see" that the structure S is defined.</div> </div> </div> </blockquote> <p>You're right, it doesn't help!=C2=A0 I think the capability I was actually looking for was a way for an MLB file to declare that it inherits a structure from its environment with the option to provide a definition if the structure doesn't exist in the initial environment, where that structure may be exported by the MLB file and, if the structure is exported, the export is suppressed if the structure existed in the initial environment (so there is no effect on the enclosing environment in that case).=C2=A0 Perhaps bett= er syntax for this would be</p> <p>=C2=A0 with structure <strid><br> =C2=A0[orelse <basdec>]<br> =C2=A0 end</p> (This is not a well thought through proposal.=C2=A0 Possibly a horrible kludge if it could even work at all.)<br> <blockquote type=3D"cite" cite=3D"mid:[email protected]= l.com"> <div dir=3D"ltr"> <div class=3D"gmail_quote"> <div class=3D"gmail_default" style=3D"font-family:"courier new",monospace;font-size:large">I do agree that SML (and CM and MLB) files deviate somewhat from other languages in their treatment of "import"-like declarations.=C2=A0 I do fi= nd that students sometimes find SML source code confusing, because when they encounter a structure/identifier that isn't defined in the file, they cannot just jump to the beginning of the file and look at the various "import" declarations to determine where the structure/identifier might be coming from.=C2=A0 Instead, they need to jump to the CM/MLB file that contains the source SML file and then piece together the imports from the CM/MLB file.</div> <div class=3D"gmail_default" style=3D"font-family:"courier new",monospace;font-size:large"><br> </div> <div class=3D"gmail_default" style=3D"font-family:"courier new",monospace;font-size:large">I have thought that perhaps we should have an extended MLB format that allows the inclusion of SML code after an import prelude and before an export postlude; then at least the SML and MLB code would be in the same file.=C2=A0 One of my past students tried out a simple surface-level pre-processor to give this kind of behavior; see <a href=3D"https://github.com/myegorov/transmler" moz-do-not-send=3D"true">https://github.com/myegorov/transmle= r</a>.</div> </div> </div> </blockquote> <p>Interesting idea.=C2=A0 Allowing imports/exports in the source files themselves would avoid the sea of MLB files.=C2=A0 I have some initia= l thoughts about how native support for such 'SMLB' files would work in my situation:<br> </p> <ol> <li>The separate MLB files are, in principle, compiler agnostic (if I were to replace "mlton" by $(COMPILER) to allow other compilers) whereas the SML files defining structures (which use FFI features) are not typically.=C2=A0 These SML files would become compiler-specific SMLB files, so the imports/exports would be duplicated for each compiler.=C2=A0 However that is not a practical issue in my case because the files are all automatically generated and the duplication overhead is not significant.<br> <br> </li> <li>As a matter of principle, I have ensured that the SML files defining signatures are common to all SML compilers (just Poly/ML and MLton for now).=C2=A0 Using SMLB files for these SML files could only be used if SMLB files were supported by all compilers (or that principle were abandoned).=C2=A0 To that end, perhaps this is a proposal for successor ML?<br> </li> </ol> </body> </html> <p></p> -- <br /> To unsubscribe from this group and stop receiving emails from it, send an e= mail to <a href=3D"mailto:[email protected]">mlton-user+unsu= [email protected]</a>.<br /> --------------956B9BACD3F5B8BEC8574792-- --===============0298534281317648436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline --===============0298534281317648436== Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: 7bit Content-Disposition: inline _______________________________________________ MLton-user mailing list [email protected]; [email protected] https://lists.sourceforge.net/lists/listinfo/mlton-user --===============0298534281317648436==--