mlton-user — [MLton-user] User community discussion

[MLton-user] ICFP 2025 (Co-Located with SPLASH!): Call for Participation

['ICFP P. v. MLton-u. <mlt...@ml...>]

==================================================
Call for Participation

The 30th ACM SIGPLAN International Conference
on Functional Programming (ICFP 2025) and
affiliated events

*** This year, co-located with SPLASH for a ***
*** joint ICFP/SPLASH Conference ***

https://icfp25.sigplan.org
Singapore; Oct 12-18, 2025

*** Register by Aug 31, 2025 for a discount! ***
==================================================

ICFP is a celebration of the art and science of
functional programming, providing a forum for
researchers and developers to engage on a variety
of topics, from foundations to features, and from
abstraction to application.

This year, for the first time in history, ICFP will
be co-located with SPLASH and its satellite events
as a part of the joint ICFP/SPLASH 2025 conference.

You are invited to participate in a full week of
events dedicated to the art and science of programming,
featuring both the ICFP and SPLASH main conferences
as well as numerous related events.

* ICFP Accepted Papers:
https://icfp25.sigplan.org/track/icfp-2025-papers#event-overview

* Registration:
https://icfp25.sigplan.org/attending/registration
*The early-bird deadline is August 31, 2025*
(Additionally, there is a full week discount
if you register for 7 days!)

* Venue (Sunday Workshops only): NUS School of Computing
https://icfp25.sigplan.org/venue/splash-2025-venue1

* Venue (Main Conference): Marina Bay Sands Convention Centre
https://icfp25.sigplan.org/venue/splash-2025-venue


Full list of events:

October 12
Tutorials
-
https://conf.researchr.org/track/icfp-splash-2025/icfp-splash-2025-tutorials
PLMW
- https://conf.researchr.org/home/icfp-splash-2025/plmw-icfp-splash-2025
TyDE
- https://conf.researchr.org/home/icfp-splash-2025/tyde-2025
FARM
- https://2025.splashcon.org/track/splash-2025-farm
HOPE
- https://conf.researchr.org/home/icfp-splash-2025/hope-2025
Erlang
- https://conf.researchr.org/home/icfp-splash-2025/erlang-2025
FUNARCH
- https://conf.researchr.org/home/icfp-splash-2025/funarch-2025

October 13-15
ICFP (3 days)
- https://icfp25.sigplan.org/

October 13-14
SAS (2 days)
- https://2025.splashcon.org/home/sas-2025

October 13
SPLASH Doctoral Symposium
- https://2025.splashcon.org/track/splash-2025-Doctoral-Symposium
SCALA
- https://conf.researchr.org/home/icfp-splash-2025/scala-2025
PROPL
- https://conf.researchr.org/home/icfp-splash-2025/propl-2025

October 14-15
OlivierFest (2 days)
- https://conf.researchr.org/home/icfp-splash-2025/olivierfest-2025
October 14
HATRA
- https://conf.researchr.org/home/icfp-splash-2025/hatra-2025
MPLR
- https://conf.researchr.org/home/icfp-splash-2025/mplr-2025
IWACO
- https://conf.researchr.org/home/icfp-splash-2025/iwaco-2025
October 15
PAINT
- https://conf.researchr.org/home/icfp-splash-2025/paint-2025
LMPL
- https://conf.researchr.org/home/icfp-splash-2025/lmpl-2025
VMIL
- https://conf.researchr.org/home/icfp-splash-2025/vmil-2025

October 16-18
OOPSLA (3 days)
- https://2025.splashcon.org/track/OOPSLA
ONWARD! (3 days)
- https://2025.splashcon.org/track/splash-2025-Onward-papers

October 16-17
HASKELL (2 days)
- https://conf.researchr.org/home/icfp-splash-2025/haskellsymp-2025

October 16
ML Family
- https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025
SCHEME
- https://conf.researchr.org/home/icfp-splash-2025/scheme-2025
WASM
- https://conf.researchr.org/home/icfp-splash-2025/webassembly-ws-2025

October 17
OCAML
- https://conf.researchr.org/home/icfp-splash-2025/ocaml-2025
MINI KANREN
- https://conf.researchr.org/home/icfp-splash-2025/minikanren-2025
October 18
SPLASH-E
- https://2025.splashcon.org/track/splash-2025-SPLASH-E
REBASE
- https://conf.researchr.org/home/icfp-splash-2025/rebase-2025
Industry Forum
- https://conf.researchr.org/home/icfp-splash-2025/industry-forum-2025


ICFP 2025 will feature three keynotes:

Ekaterina Komendantskaya:
Proof-Carrying Neuro-Symbolic Code
https://icfp25.sigplan.org/details/icfp-2025-icfp-keynotes/2/Proof-Carrying-Neuro-Symbolic-Code

Christos Dimoulas:
The Rational Programmer, A Method for Investigating Programming Language
Pragmatics
https://icfp25.sigplan.org/details/icfp-2025-icfp-keynotes/3/The-Rational-Programmer-A-Method-for-Investigating-Programming-Language-Pragmatics

Satnam Singh:
Functional Programming for Hardware Design
https://icfp25.sigplan.org/details/icfp-2025-icfp-keynotes/1/Functional-Programming-for-Hardware-Design


ICFP 2025 conference organizers:

https://icfp25.sigplan.org/committee/icfp-2025-organizing-committee


We hope to see you in Singapore in October. Don't forget
to register by *August 31, 2025* for the early-bird
discount! Additionally, there is a *full-week discount*:
register for the whole 7 days and only pay for 6!

https://icfp25.sigplan.org/attending/registration

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

[Matthew F. <mat...@gm...>]

You could use the CoreML IR, but (as a whole-program compiler), MLton will
always give you the CoreML IR for the whole program, so you'll need to
"find" your datatypes within there.

I'm not sure about the complexity of SML datatype definitions that you
expect to encounter, but I suspect that it might be simpler to just write
your own tiny parser for SML type definitions (and assume that the
complexities of type definitions aren't really used).  I kind of see the
appeal of the type-level "marking" of types in the datatypes, but I wonder
if a simple custom comment syntax might suffice:

```
datatype 'a tree = Leaf | Node of 'a tree * 'a * 'a tree
type iitree = (*#1*) ((*#0*) int tree) tree
```

I note that in your original example, you used a `type` definition to
describe the type of data to be generated, but note that elaboration to
CoreML has completely expanded all `type` definitions, so there wouldn't be
one to find in the CoreML program.

I suppose that in a larger application, it would be convenient to have all
of the datatype definitions available, but you will still need to parse the
CoreML sufficiently to find all of the involved types.

-Matthew


On Fri, Jul 25, 2025 at 9:41 PM Arnav Sabharwal <arn...@an...>
wrote:

> Hello Prof. Matthew, Yawar,
>
> Thank you for your response and advice! Apologies, I miscommunicated
> earlier: my OCaml "generator" (not generator - generator) takes in an SML
> type and the user specified target sizes for each involved inductive type
> and yields an SML term of said type, which meets the size constraints.
>
> I was considering the approach of stopping MLton at **some** point since:
>
>    1. I was hoping I could get MLton to unique-ify type variables for me
>    2. MLton could simplify the grammar of type and datatype declarations
>    for me, making parsing easier (as compared to say, parsing SML from source)
>
> Seemingly, the Core-ML IR seems to have these properties? Please correct
> me if I'm wrong!
>
> Thanks,
> Arnav.
>
> On Thu, Jul 24, 2025 at 9:21 PM Matthew Fluet <mat...@gm...>
> wrote:
>
>> Aranav isn’t subscribed, so I needed to moderate/accept the email before
>> it was sent to the whole list.
>>
>> On Thu, Jul 24, 2025 at 8:03 PM 'Yawar Raza (RIT Student)' via MLton-user
>> <mlt...@ml...> wrote:
>>
>>> Nevermind to my first paragraph. I just received the original email.
>>> Apparently they can get sent to me out of order...
>>>
>>> On Thursday, July 24, 2025, Yawar Raza (RIT Student) <ys...@ri...>
>>> wrote:
>>>
>>>> Arnav, I think you might need to use "Reply-All" for the reply to
>>>> remain on the mailing list, as only Prof. Fluet got your second email (I
>>>> didn't get it, at least).
>>>>
>>>> Anyway, I don't think "stopping the MLton compiler part way through" is
>>>> the best way to do the sort of thing you're trying to do.
>>>>
>>>> Something you _could_ look into is this one family of SML tricks
>>>> centered around http://mlton.org/Fold, possibly more specifically
>>>> http://mlton.org/VariableArityPolymorphism. I don't really understand
>>>> these libraries though, and I'm personally very averse to this sort of code.
>>>>
>>>> I don't really get what you're trying to do. Why do you have a
>>>> generator-generator? Is the generator (output by the generator-generator)
>>>> in SML itself or does it just output SML? Does it output just datatype
>>>> declarations or complete programs? I think saying what each level inputs
>>>> and outputs would be helpful.
>>>>
>>>> In general, you should probably end up doing one of the following:
>>>> - Push arity-polymorphism or similarly un-simple stuff up one generator
>>>> level, generating different SML source code text for each (rather than
>>>> trying to extract MLton compiler output).
>>>> - Give up on perfect type safety relating to arities, and just have the
>>>> different arities of some things share a single general type.
>>>> - Use a different language that either has dependent types (e.g. Idris)
>>>> or has more featureful metaprogramming (e.g. F# with its type providers).
>>>>
>>>> But maybe I'm just misunderstanding something. Feel free to ignore
>>>> those last two paragraph if so, but I hope those two MLton links above were
>>>> useful to learn exist, at least.
>>>>
>>>>
>>>> On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...>
>>>> wrote:
>>>>>
>>>>> Well, if you just want a somewhat normalized representation of the
>>>>> types, then you might just use the CoreML representation immediately after
>>>>> elaboration (`-keep-pass parseAndElaborate`).
>>>>>
>>>>> For example:
>>>>> ```
>>>>> $ cat z.sml
>>>>> datatype zero = Zero
>>>>> datatype 'n succ = Succ
>>>>>
>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>> 'index) my_list
>>>>> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
>>>>> $ mlton -keep-pass parseAndElaborate z.sml
>>>>> $ tail z.parseAndElaborate.post.core-ml
>>>>> (* deadCode: true *)
>>>>> (* deadCode: true *)
>>>>> (* deadCode: false *)
>>>>> datatype zero_21 = Zero_0
>>>>> datatype 'a_4547 succ_2 = Succ_0
>>>>> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>>>>>                                         | Cons_0 of 'a_4549
>>>>>                                                     * ('a_4549,
>>>>> 'a_4548) my_list_0
>>>>> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>>>>>    raise (Fail_0 "todo")
>>>>> ```
>>>>>
>>>>> But, note, you'll still need to see through the uniquification of all
>>>>> identifiers.
>>>>>
>>>>> -Matthew
>>>>>
>>>>> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <
>>>>> arn...@an...> wrote:
>>>>>
>>>>>> Hello Matthew,
>>>>>>
>>>>>> Thank you for your response! My larger goal here is to make a random
>>>>>> generator for (regular) SML inductive types that allows the user to
>>>>>> configure "target sizes" for every inductive structure within their type.
>>>>>> The type labels are meant to be a way for the user and the tool to agree on
>>>>>> a common language for referring to said inductive types.
>>>>>>
>>>>>> For example, say the user wants to generate 2-d lists where the outer
>>>>>> list has length 3 and each inner list has length 2. Then, they'd define
>>>>>> their list type like so, building towards their monomorphic "final" type:
>>>>>> ```
>>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>>> 'index) my_list
>>>>>> type final = ((int, zero) my_list, zero succ) my_list
>>>>>> ```
>>>>>> This way, the user could later provide the lengths [2, 3] and the
>>>>>> tool would unambiguously be able to generate the type with the
>>>>>> specified constraints.
>>>>>>
>>>>>> Oh, and I'm writing the "random generator"-generator tool in OCaml.
>>>>>> So, I suppose one way could be to parse out the data-type and type
>>>>>> declarations from source, while these tags still hang around. But then I'd
>>>>>> have to "evaluate" type applications to bring them into a normal form, due
>>>>>> to the lingering type variables...which is why I was considering delaying
>>>>>> the point at which I "parse into an OCaml representation" as much as
>>>>>> possible.
>>>>>>
>>>>>> Happy to clarify more if necessary, would greatly appreciate your
>>>>>> advice!
>>>>>>
>>>>>> Arnav.
>>>>>>
>>>>>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <
>>>>>> mat...@gm...> wrote:
>>>>>>
>>>>>>> Arnav,
>>>>>>>
>>>>>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism
>>>>>>> whatsoever (for functions or datatypes) and type parameters that do not
>>>>>>> contribute to the representation of a datatype will have been eliminated.
>>>>>>>
>>>>>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>>>>>> optimization will have already eliminated these unused type parameters,
>>>>>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>>>>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>>>>>> that may be present for high-level API reasons, but do not affect the
>>>>>>> dynamics because they do not influence the data representation.
>>>>>>>
>>>>>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>>>>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>>>>>> of your tagged datatypes to be separately monmorphised, though with the
>>>>>>> current heuristics for naming monomorphised variants, you probably won't
>>>>>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>>>>>> SXML program.
>>>>>>>
>>>>>>> Could you say a bit more about your goals?  That might help to
>>>>>>> inform whether there is a better way to accomplish what you are trying to
>>>>>>> do.
>>>>>>>
>>>>>>> -Matthew
>>>>>>>
>>>>>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <
>>>>>>> arn...@an...> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'm trying to tag every instance of a recursive type in a type
>>>>>>>> definition with a tag. This tag is essentially a "type-level natural
>>>>>>>> number". By way of example, here's what I mean:
>>>>>>>>
>>>>>>>> datatype zero = Zero
>>>>>>>> datatype 'n succ = Succ
>>>>>>>>
>>>>>>>> (* example: rose tree *)
>>>>>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>>>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>>>>>
>>>>>>>> (* example: tree with int list data *)
>>>>>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>>>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>>>>>
>>>>>>>> As seen, each type is given as many type parameters as is necessary
>>>>>>>> to instantiate its own tag as well as the tags of its "recursive
>>>>>>>> sub-structures". The first type argument is meant for the tag of the
>>>>>>>> recursive type currently being defined.
>>>>>>>>
>>>>>>>> Now, when I use MLton to compile this, the tag types seem to be
>>>>>>>> removed during monomorphization. Thus,
>>>>>>>>
>>>>>>>> (zero, zero succ) rose_tree
>>>>>>>> and
>>>>>>>>
>>>>>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>>>>>> appear to be the same type in SXML. What are my options here, if
>>>>>>>> I'd like to maintain such a type level distinction? Is XML necessarily the
>>>>>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>>>>>> some advice here!
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Arnav.
>>>>>>>> ,
>>>>>>>>
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to mlt...@ml....
>>>>>>>> _______________________________________________
>>>>>>>> MLton-user mailing list
>>>>>>>> MLt...@li...; mlt...@ml...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>>>>>
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to mlt...@ml....
>>>>>
>>>>
>>>>
>>>> --
>>>> -- Yawar Raza
>>>>
>>>>
>>>
>>> --
>>> -- Yawar Raza
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mlt...@ml....
>>> _______________________________________________
>>> MLton-user mailing list
>>> MLt...@li...; mlt...@ml...
>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>
>>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

['Yawar R. (R. Student)' v. MLton-u. <mlt...@ml...>]

Gmail didn't add the person I clicked "reply all" to for some reason.
(⁠╯⁠°⁠□⁠°⁠）⁠╯⁠︵⁠ ⁠┻⁠━⁠┻

"I don't know the answer your question, but if you end up finding that
MLton does not meet your needs, you could try using HaMLet instead:
https://github.com/rossberg/hamlet . It's meant to be more amenable to
"hacking" than compilers like MLton are. You could modify the source code
to have more control over type instantiation to match your use case (or
just use it for parsing and do type instantiation in your OCaml code). You
would use this to replace the role of MLton in your current code, so you'd
compile this modified HaMLet (with MLton or any SML compiler) and invoke
the binary from your OCaml code."


> On Friday, July 25, 2025, Arnav Sabharwal <arn...@an...>
> wrote:
>>
>> Hello Prof. Matthew, Yawar,
>>
>> Thank you for your response and advice! Apologies, I miscommunicated
>> earlier: my OCaml "generator" (not generator - generator) takes in an SML
>> type and the user specified target sizes for each involved inductive type
>> and yields an SML term of said type, which meets the size constraints.
>>
>> I was considering the approach of stopping MLton at **some** point since:
>>
>>    1. I was hoping I could get MLton to unique-ify type variables for me
>>    2. MLton could simplify the grammar of type and datatype declarations
>>    for me, making parsing easier (as compared to say, parsing SML from source)
>>
>> Seemingly, the Core-ML IR seems to have these properties? Please correct
>> me if I'm wrong!
>>
>> Thanks,
>> Arnav.
>>
>> On Thu, Jul 24, 2025 at 9:21 PM Matthew Fluet <mat...@gm...>
>> wrote:
>>
>>> Aranav isn’t subscribed, so I needed to moderate/accept the email before
>>> it was sent to the whole list.
>>>
>>> On Thu, Jul 24, 2025 at 8:03 PM 'Yawar Raza (RIT Student)' via
>>> MLton-user <mlt...@ml...> wrote:
>>>
>>>> Nevermind to my first paragraph. I just received the original email.
>>>> Apparently they can get sent to me out of order...
>>>>
>>>> On Thursday, July 24, 2025, Yawar Raza (RIT Student) <ys...@ri...>
>>>> wrote:
>>>>
>>>>> Arnav, I think you might need to use "Reply-All" for the reply to
>>>>> remain on the mailing list, as only Prof. Fluet got your second email (I
>>>>> didn't get it, at least).
>>>>>
>>>>> Anyway, I don't think "stopping the MLton compiler part way through"
>>>>> is the best way to do the sort of thing you're trying to do.
>>>>>
>>>>> Something you _could_ look into is this one family of SML tricks
>>>>> centered around http://mlton.org/Fold, possibly more specifically
>>>>> http://mlton.org/VariableArityPolymorphism. I don't really understand
>>>>> these libraries though, and I'm personally very averse to this sort of code.
>>>>>
>>>>> I don't really get what you're trying to do. Why do you have a
>>>>> generator-generator? Is the generator (output by the generator-generator)
>>>>> in SML itself or does it just output SML? Does it output just datatype
>>>>> declarations or complete programs? I think saying what each level inputs
>>>>> and outputs would be helpful.
>>>>>
>>>>> In general, you should probably end up doing one of the following:
>>>>> - Push arity-polymorphism or similarly un-simple stuff up one
>>>>> generator level, generating different SML source code text for each (rather
>>>>> than trying to extract MLton compiler output).
>>>>> - Give up on perfect type safety relating to arities, and just have
>>>>> the different arities of some things share a single general type.
>>>>> - Use a different language that either has dependent types (e.g.
>>>>> Idris) or has more featureful metaprogramming (e.g. F# with its type
>>>>> providers).
>>>>>
>>>>> But maybe I'm just misunderstanding something. Feel free to ignore
>>>>> those last two paragraph if so, but I hope those two MLton links above were
>>>>> useful to learn exist, at least.
>>>>>
>>>>>
>>>>> On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...>
>>>>> wrote:
>>>>>>
>>>>>> Well, if you just want a somewhat normalized representation of the
>>>>>> types, then you might just use the CoreML representation immediately after
>>>>>> elaboration (`-keep-pass parseAndElaborate`).
>>>>>>
>>>>>> For example:
>>>>>> ```
>>>>>> $ cat z.sml
>>>>>> datatype zero = Zero
>>>>>> datatype 'n succ = Succ
>>>>>>
>>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>>> 'index) my_list
>>>>>> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
>>>>>> $ mlton -keep-pass parseAndElaborate z.sml
>>>>>> $ tail z.parseAndElaborate.post.core-ml
>>>>>> (* deadCode: true *)
>>>>>> (* deadCode: true *)
>>>>>> (* deadCode: false *)
>>>>>> datatype zero_21 = Zero_0
>>>>>> datatype 'a_4547 succ_2 = Succ_0
>>>>>> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>>>>>>                                         | Cons_0 of 'a_4549
>>>>>>                                                     * ('a_4549,
>>>>>> 'a_4548) my_list_0
>>>>>> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>>>>>>    raise (Fail_0 "todo")
>>>>>> ```
>>>>>>
>>>>>> But, note, you'll still need to see through the uniquification of all
>>>>>> identifiers.
>>>>>>
>>>>>> -Matthew
>>>>>>
>>>>>> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <
>>>>>> arn...@an...> wrote:
>>>>>>
>>>>>>> Hello Matthew,
>>>>>>>
>>>>>>> Thank you for your response! My larger goal here is to make a random
>>>>>>> generator for (regular) SML inductive types that allows the user to
>>>>>>> configure "target sizes" for every inductive structure within their type.
>>>>>>> The type labels are meant to be a way for the user and the tool to agree on
>>>>>>> a common language for referring to said inductive types.
>>>>>>>
>>>>>>> For example, say the user wants to generate 2-d lists where the
>>>>>>> outer list has length 3 and each inner list has length 2. Then, they'd
>>>>>>> define their list type like so, building towards their monomorphic "final"
>>>>>>> type:
>>>>>>> ```
>>>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>>>> 'index) my_list
>>>>>>> type final = ((int, zero) my_list, zero succ) my_list
>>>>>>> ```
>>>>>>> This way, the user could later provide the lengths [2, 3] and the
>>>>>>> tool would unambiguously be able to generate the type with the
>>>>>>> specified constraints.
>>>>>>>
>>>>>>> Oh, and I'm writing the "random generator"-generator tool in OCaml.
>>>>>>> So, I suppose one way could be to parse out the data-type and type
>>>>>>> declarations from source, while these tags still hang around. But then I'd
>>>>>>> have to "evaluate" type applications to bring them into a normal form, due
>>>>>>> to the lingering type variables...which is why I was considering delaying
>>>>>>> the point at which I "parse into an OCaml representation" as much as
>>>>>>> possible.
>>>>>>>
>>>>>>> Happy to clarify more if necessary, would greatly appreciate your
>>>>>>> advice!
>>>>>>>
>>>>>>> Arnav.
>>>>>>>
>>>>>>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <
>>>>>>> mat...@gm...> wrote:
>>>>>>>
>>>>>>>> Arnav,
>>>>>>>>
>>>>>>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism
>>>>>>>> whatsoever (for functions or datatypes) and type parameters that do not
>>>>>>>> contribute to the representation of a datatype will have been eliminated.
>>>>>>>>
>>>>>>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>>>>>>> optimization will have already eliminated these unused type parameters,
>>>>>>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>>>>>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>>>>>>> that may be present for high-level API reasons, but do not affect the
>>>>>>>> dynamics because they do not influence the data representation.
>>>>>>>>
>>>>>>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>>>>>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>>>>>>> of your tagged datatypes to be separately monmorphised, though with the
>>>>>>>> current heuristics for naming monomorphised variants, you probably won't
>>>>>>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>>>>>>> SXML program.
>>>>>>>>
>>>>>>>> Could you say a bit more about your goals?  That might help to
>>>>>>>> inform whether there is a better way to accomplish what you are trying to
>>>>>>>> do.
>>>>>>>>
>>>>>>>> -Matthew
>>>>>>>>
>>>>>>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <
>>>>>>>> arn...@an...> wrote:
>>>>>>>>
>>>>>>>>> Hello,
>>>>>>>>>
>>>>>>>>> I'm trying to tag every instance of a recursive type in a type
>>>>>>>>> definition with a tag. This tag is essentially a "type-level natural
>>>>>>>>> number". By way of example, here's what I mean:
>>>>>>>>>
>>>>>>>>> datatype zero = Zero
>>>>>>>>> datatype 'n succ = Succ
>>>>>>>>>
>>>>>>>>> (* example: rose tree *)
>>>>>>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>>>>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>>>>>>
>>>>>>>>> (* example: tree with int list data *)
>>>>>>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>>>>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>>>>>>
>>>>>>>>> As seen, each type is given as many type parameters as is
>>>>>>>>> necessary to instantiate its own tag as well as the tags of its "recursive
>>>>>>>>> sub-structures". The first type argument is meant for the tag of the
>>>>>>>>> recursive type currently being defined.
>>>>>>>>>
>>>>>>>>> Now, when I use MLton to compile this, the tag types seem to be
>>>>>>>>> removed during monomorphization. Thus,
>>>>>>>>>
>>>>>>>>> (zero, zero succ) rose_tree
>>>>>>>>> and
>>>>>>>>>
>>>>>>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>>>>>>> appear to be the same type in SXML. What are my options here, if
>>>>>>>>> I'd like to maintain such a type level distinction? Is XML necessarily the
>>>>>>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>>>>>>> some advice here!
>>>>>>>>>
>>>>>>>>> Thank you,
>>>>>>>>> Arnav.
>>>>>>>>> ,
>>>>>>>>>
>>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>>> send an email to mlt...@ml....
>>>>>>>>> _______________________________________________
>>>>>>>>> MLton-user mailing list
>>>>>>>>> MLt...@li...; mlt...@ml...
>>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>>>>>>
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to mlt...@ml....
>>>>>>
>>>>>
>>>>>
>>>>> --
>>>>> -- Yawar Raza
>>>>>
>>>>>
>>>>
>>>> --
>>>> -- Yawar Raza
>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to mlt...@ml....
>>>> _______________________________________________
>>>> MLton-user mailing list
>>>> MLt...@li...; mlt...@ml...
>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to mlt...@ml....
>>
>
>
> --
> -- Yawar Raza
>
>

-- 
-- Yawar Raza

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

['Yawar R. (R. Student)' v. MLton-u. <mlt...@ml...>]

I don't know the answer your question, but if you end up finding that MLton
does not meet your needs, you could try using HaMLet instead:
https://github.com/rossberg/hamlet . It's meant to be more amenable to
"hacking" than compilers like MLton are. You could modify the source code
to have more control over type instantiation to match your use case (or
just use it for parsing and do type instantiation in your OCaml code). You
would use this to replace the role of MLton in your current code, so you'd
compile this modified HaMLet (with MLton or any SML compiler) and invoke
the binary from your OCaml code.

On Friday, July 25, 2025, Arnav Sabharwal <arn...@an...> wrote:
>
> Hello Prof. Matthew, Yawar,
>
> Thank you for your response and advice! Apologies, I miscommunicated
> earlier: my OCaml "generator" (not generator - generator) takes in an SML
> type and the user specified target sizes for each involved inductive type
> and yields an SML term of said type, which meets the size constraints.
>
> I was considering the approach of stopping MLton at **some** point since:
>
>    1. I was hoping I could get MLton to unique-ify type variables for me
>    2. MLton could simplify the grammar of type and datatype declarations
>    for me, making parsing easier (as compared to say, parsing SML from source)
>
> Seemingly, the Core-ML IR seems to have these properties? Please correct
> me if I'm wrong!
>
> Thanks,
> Arnav.
>
> On Thu, Jul 24, 2025 at 9:21 PM Matthew Fluet <mat...@gm...>
> wrote:
>
>> Aranav isn’t subscribed, so I needed to moderate/accept the email before
>> it was sent to the whole list.
>>
>> On Thu, Jul 24, 2025 at 8:03 PM 'Yawar Raza (RIT Student)' via MLton-user
>> <mlt...@ml...> wrote:
>>
>>> Nevermind to my first paragraph. I just received the original email.
>>> Apparently they can get sent to me out of order...
>>>
>>> On Thursday, July 24, 2025, Yawar Raza (RIT Student) <ys...@ri...>
>>> wrote:
>>>
>>>> Arnav, I think you might need to use "Reply-All" for the reply to
>>>> remain on the mailing list, as only Prof. Fluet got your second email (I
>>>> didn't get it, at least).
>>>>
>>>> Anyway, I don't think "stopping the MLton compiler part way through" is
>>>> the best way to do the sort of thing you're trying to do.
>>>>
>>>> Something you _could_ look into is this one family of SML tricks
>>>> centered around http://mlton.org/Fold, possibly more specifically
>>>> http://mlton.org/VariableArityPolymorphism. I don't really understand
>>>> these libraries though, and I'm personally very averse to this sort of code.
>>>>
>>>> I don't really get what you're trying to do. Why do you have a
>>>> generator-generator? Is the generator (output by the generator-generator)
>>>> in SML itself or does it just output SML? Does it output just datatype
>>>> declarations or complete programs? I think saying what each level inputs
>>>> and outputs would be helpful.
>>>>
>>>> In general, you should probably end up doing one of the following:
>>>> - Push arity-polymorphism or similarly un-simple stuff up one generator
>>>> level, generating different SML source code text for each (rather than
>>>> trying to extract MLton compiler output).
>>>> - Give up on perfect type safety relating to arities, and just have the
>>>> different arities of some things share a single general type.
>>>> - Use a different language that either has dependent types (e.g. Idris)
>>>> or has more featureful metaprogramming (e.g. F# with its type providers).
>>>>
>>>> But maybe I'm just misunderstanding something. Feel free to ignore
>>>> those last two paragraph if so, but I hope those two MLton links above were
>>>> useful to learn exist, at least.
>>>>
>>>>
>>>> On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...>
>>>> wrote:
>>>>>
>>>>> Well, if you just want a somewhat normalized representation of the
>>>>> types, then you might just use the CoreML representation immediately after
>>>>> elaboration (`-keep-pass parseAndElaborate`).
>>>>>
>>>>> For example:
>>>>> ```
>>>>> $ cat z.sml
>>>>> datatype zero = Zero
>>>>> datatype 'n succ = Succ
>>>>>
>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>> 'index) my_list
>>>>> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
>>>>> $ mlton -keep-pass parseAndElaborate z.sml
>>>>> $ tail z.parseAndElaborate.post.core-ml
>>>>> (* deadCode: true *)
>>>>> (* deadCode: true *)
>>>>> (* deadCode: false *)
>>>>> datatype zero_21 = Zero_0
>>>>> datatype 'a_4547 succ_2 = Succ_0
>>>>> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>>>>>                                         | Cons_0 of 'a_4549
>>>>>                                                     * ('a_4549,
>>>>> 'a_4548) my_list_0
>>>>> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>>>>>    raise (Fail_0 "todo")
>>>>> ```
>>>>>
>>>>> But, note, you'll still need to see through the uniquification of all
>>>>> identifiers.
>>>>>
>>>>> -Matthew
>>>>>
>>>>> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <
>>>>> arn...@an...> wrote:
>>>>>
>>>>>> Hello Matthew,
>>>>>>
>>>>>> Thank you for your response! My larger goal here is to make a random
>>>>>> generator for (regular) SML inductive types that allows the user to
>>>>>> configure "target sizes" for every inductive structure within their type.
>>>>>> The type labels are meant to be a way for the user and the tool to agree on
>>>>>> a common language for referring to said inductive types.
>>>>>>
>>>>>> For example, say the user wants to generate 2-d lists where the outer
>>>>>> list has length 3 and each inner list has length 2. Then, they'd define
>>>>>> their list type like so, building towards their monomorphic "final" type:
>>>>>> ```
>>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>>> 'index) my_list
>>>>>> type final = ((int, zero) my_list, zero succ) my_list
>>>>>> ```
>>>>>> This way, the user could later provide the lengths [2, 3] and the
>>>>>> tool would unambiguously be able to generate the type with the
>>>>>> specified constraints.
>>>>>>
>>>>>> Oh, and I'm writing the "random generator"-generator tool in OCaml.
>>>>>> So, I suppose one way could be to parse out the data-type and type
>>>>>> declarations from source, while these tags still hang around. But then I'd
>>>>>> have to "evaluate" type applications to bring them into a normal form, due
>>>>>> to the lingering type variables...which is why I was considering delaying
>>>>>> the point at which I "parse into an OCaml representation" as much as
>>>>>> possible.
>>>>>>
>>>>>> Happy to clarify more if necessary, would greatly appreciate your
>>>>>> advice!
>>>>>>
>>>>>> Arnav.
>>>>>>
>>>>>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <
>>>>>> mat...@gm...> wrote:
>>>>>>
>>>>>>> Arnav,
>>>>>>>
>>>>>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism
>>>>>>> whatsoever (for functions or datatypes) and type parameters that do not
>>>>>>> contribute to the representation of a datatype will have been eliminated.
>>>>>>>
>>>>>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>>>>>> optimization will have already eliminated these unused type parameters,
>>>>>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>>>>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>>>>>> that may be present for high-level API reasons, but do not affect the
>>>>>>> dynamics because they do not influence the data representation.
>>>>>>>
>>>>>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>>>>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>>>>>> of your tagged datatypes to be separately monmorphised, though with the
>>>>>>> current heuristics for naming monomorphised variants, you probably won't
>>>>>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>>>>>> SXML program.
>>>>>>>
>>>>>>> Could you say a bit more about your goals?  That might help to
>>>>>>> inform whether there is a better way to accomplish what you are trying to
>>>>>>> do.
>>>>>>>
>>>>>>> -Matthew
>>>>>>>
>>>>>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <
>>>>>>> arn...@an...> wrote:
>>>>>>>
>>>>>>>> Hello,
>>>>>>>>
>>>>>>>> I'm trying to tag every instance of a recursive type in a type
>>>>>>>> definition with a tag. This tag is essentially a "type-level natural
>>>>>>>> number". By way of example, here's what I mean:
>>>>>>>>
>>>>>>>> datatype zero = Zero
>>>>>>>> datatype 'n succ = Succ
>>>>>>>>
>>>>>>>> (* example: rose tree *)
>>>>>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>>>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>>>>>
>>>>>>>> (* example: tree with int list data *)
>>>>>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>>>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>>>>>
>>>>>>>> As seen, each type is given as many type parameters as is necessary
>>>>>>>> to instantiate its own tag as well as the tags of its "recursive
>>>>>>>> sub-structures". The first type argument is meant for the tag of the
>>>>>>>> recursive type currently being defined.
>>>>>>>>
>>>>>>>> Now, when I use MLton to compile this, the tag types seem to be
>>>>>>>> removed during monomorphization. Thus,
>>>>>>>>
>>>>>>>> (zero, zero succ) rose_tree
>>>>>>>> and
>>>>>>>>
>>>>>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>>>>>> appear to be the same type in SXML. What are my options here, if
>>>>>>>> I'd like to maintain such a type level distinction? Is XML necessarily the
>>>>>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>>>>>> some advice here!
>>>>>>>>
>>>>>>>> Thank you,
>>>>>>>> Arnav.
>>>>>>>> ,
>>>>>>>>
>>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>>> send an email to mlt...@ml....
>>>>>>>> _______________________________________________
>>>>>>>> MLton-user mailing list
>>>>>>>> MLt...@li...; mlt...@ml...
>>>>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>>>>>
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>> send an email to mlt...@ml....
>>>>>
>>>>
>>>>
>>>> --
>>>> -- Yawar Raza
>>>>
>>>>
>>>
>>> --
>>> -- Yawar Raza
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mlt...@ml....
>>> _______________________________________________
>>> MLton-user mailing list
>>> MLt...@li...; mlt...@ml...
>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>
>> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
>


-- 
-- Yawar Raza

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

[Arnav S. <arn...@an...>]

Hello Prof. Matthew, Yawar,

Thank you for your response and advice! Apologies, I miscommunicated
earlier: my OCaml "generator" (not generator - generator) takes in an SML
type and the user specified target sizes for each involved inductive type
and yields an SML term of said type, which meets the size constraints.

I was considering the approach of stopping MLton at **some** point since:

   1. I was hoping I could get MLton to unique-ify type variables for me
   2. MLton could simplify the grammar of type and datatype declarations
   for me, making parsing easier (as compared to say, parsing SML from source)

Seemingly, the Core-ML IR seems to have these properties? Please correct
me if I'm wrong!

Thanks,
Arnav.

On Thu, Jul 24, 2025 at 9:21 PM Matthew Fluet <mat...@gm...>
wrote:

> Aranav isn’t subscribed, so I needed to moderate/accept the email before
> it was sent to the whole list.
>
> On Thu, Jul 24, 2025 at 8:03 PM 'Yawar Raza (RIT Student)' via MLton-user <
> mlt...@ml...> wrote:
>
>> Nevermind to my first paragraph. I just received the original email.
>> Apparently they can get sent to me out of order...
>>
>> On Thursday, July 24, 2025, Yawar Raza (RIT Student) <ys...@ri...>
>> wrote:
>>
>>> Arnav, I think you might need to use "Reply-All" for the reply to remain
>>> on the mailing list, as only Prof. Fluet got your second email (I didn't
>>> get it, at least).
>>>
>>> Anyway, I don't think "stopping the MLton compiler part way through" is
>>> the best way to do the sort of thing you're trying to do.
>>>
>>> Something you _could_ look into is this one family of SML tricks
>>> centered around http://mlton.org/Fold, possibly more specifically
>>> http://mlton.org/VariableArityPolymorphism. I don't really understand
>>> these libraries though, and I'm personally very averse to this sort of code.
>>>
>>> I don't really get what you're trying to do. Why do you have a
>>> generator-generator? Is the generator (output by the generator-generator)
>>> in SML itself or does it just output SML? Does it output just datatype
>>> declarations or complete programs? I think saying what each level inputs
>>> and outputs would be helpful.
>>>
>>> In general, you should probably end up doing one of the following:
>>> - Push arity-polymorphism or similarly un-simple stuff up one generator
>>> level, generating different SML source code text for each (rather than
>>> trying to extract MLton compiler output).
>>> - Give up on perfect type safety relating to arities, and just have the
>>> different arities of some things share a single general type.
>>> - Use a different language that either has dependent types (e.g. Idris)
>>> or has more featureful metaprogramming (e.g. F# with its type providers).
>>>
>>> But maybe I'm just misunderstanding something. Feel free to ignore those
>>> last two paragraph if so, but I hope those two MLton links above were
>>> useful to learn exist, at least.
>>>
>>>
>>> On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...>
>>> wrote:
>>>>
>>>> Well, if you just want a somewhat normalized representation of the
>>>> types, then you might just use the CoreML representation immediately after
>>>> elaboration (`-keep-pass parseAndElaborate`).
>>>>
>>>> For example:
>>>> ```
>>>> $ cat z.sml
>>>> datatype zero = Zero
>>>> datatype 'n succ = Succ
>>>>
>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>> 'index) my_list
>>>> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
>>>> $ mlton -keep-pass parseAndElaborate z.sml
>>>> $ tail z.parseAndElaborate.post.core-ml
>>>> (* deadCode: true *)
>>>> (* deadCode: true *)
>>>> (* deadCode: false *)
>>>> datatype zero_21 = Zero_0
>>>> datatype 'a_4547 succ_2 = Succ_0
>>>> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>>>>                                         | Cons_0 of 'a_4549
>>>>                                                     * ('a_4549,
>>>> 'a_4548) my_list_0
>>>> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>>>>    raise (Fail_0 "todo")
>>>> ```
>>>>
>>>> But, note, you'll still need to see through the uniquification of all
>>>> identifiers.
>>>>
>>>> -Matthew
>>>>
>>>> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <
>>>> arn...@an...> wrote:
>>>>
>>>>> Hello Matthew,
>>>>>
>>>>> Thank you for your response! My larger goal here is to make a random
>>>>> generator for (regular) SML inductive types that allows the user to
>>>>> configure "target sizes" for every inductive structure within their type.
>>>>> The type labels are meant to be a way for the user and the tool to agree on
>>>>> a common language for referring to said inductive types.
>>>>>
>>>>> For example, say the user wants to generate 2-d lists where the outer
>>>>> list has length 3 and each inner list has length 2. Then, they'd define
>>>>> their list type like so, building towards their monomorphic "final" type:
>>>>> ```
>>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>>> 'index) my_list
>>>>> type final = ((int, zero) my_list, zero succ) my_list
>>>>> ```
>>>>> This way, the user could later provide the lengths [2, 3] and the tool
>>>>> would unambiguously be able to generate the type with the
>>>>> specified constraints.
>>>>>
>>>>> Oh, and I'm writing the "random generator"-generator tool in OCaml.
>>>>> So, I suppose one way could be to parse out the data-type and type
>>>>> declarations from source, while these tags still hang around. But then I'd
>>>>> have to "evaluate" type applications to bring them into a normal form, due
>>>>> to the lingering type variables...which is why I was considering delaying
>>>>> the point at which I "parse into an OCaml representation" as much as
>>>>> possible.
>>>>>
>>>>> Happy to clarify more if necessary, would greatly appreciate your
>>>>> advice!
>>>>>
>>>>> Arnav.
>>>>>
>>>>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <mat...@gm...>
>>>>> wrote:
>>>>>
>>>>>> Arnav,
>>>>>>
>>>>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism
>>>>>> whatsoever (for functions or datatypes) and type parameters that do not
>>>>>> contribute to the representation of a datatype will have been eliminated.
>>>>>>
>>>>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>>>>> optimization will have already eliminated these unused type parameters,
>>>>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>>>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>>>>> that may be present for high-level API reasons, but do not affect the
>>>>>> dynamics because they do not influence the data representation.
>>>>>>
>>>>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>>>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>>>>> of your tagged datatypes to be separately monmorphised, though with the
>>>>>> current heuristics for naming monomorphised variants, you probably won't
>>>>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>>>>> SXML program.
>>>>>>
>>>>>> Could you say a bit more about your goals?  That might help to inform
>>>>>> whether there is a better way to accomplish what you are trying to do.
>>>>>>
>>>>>> -Matthew
>>>>>>
>>>>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <
>>>>>> arn...@an...> wrote:
>>>>>>
>>>>>>> Hello,
>>>>>>>
>>>>>>> I'm trying to tag every instance of a recursive type in a type
>>>>>>> definition with a tag. This tag is essentially a "type-level natural
>>>>>>> number". By way of example, here's what I mean:
>>>>>>>
>>>>>>> datatype zero = Zero
>>>>>>> datatype 'n succ = Succ
>>>>>>>
>>>>>>> (* example: rose tree *)
>>>>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>>>>
>>>>>>> (* example: tree with int list data *)
>>>>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>>>>
>>>>>>> As seen, each type is given as many type parameters as is necessary
>>>>>>> to instantiate its own tag as well as the tags of its "recursive
>>>>>>> sub-structures". The first type argument is meant for the tag of the
>>>>>>> recursive type currently being defined.
>>>>>>>
>>>>>>> Now, when I use MLton to compile this, the tag types seem to be
>>>>>>> removed during monomorphization. Thus,
>>>>>>>
>>>>>>> (zero, zero succ) rose_tree
>>>>>>> and
>>>>>>>
>>>>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>>>>> appear to be the same type in SXML. What are my options here, if I'd
>>>>>>> like to maintain such a type level distinction? Is XML necessarily the
>>>>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>>>>> some advice here!
>>>>>>>
>>>>>>> Thank you,
>>>>>>> Arnav.
>>>>>>> ,
>>>>>>>
>>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>>> send an email to mlt...@ml....
>>>>>>> _______________________________________________
>>>>>>> MLton-user mailing list
>>>>>>> MLt...@li...; mlt...@ml...
>>>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>>>>
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>> send an email to mlt...@ml....
>>>>
>>>
>>>
>>> --
>>> -- Yawar Raza
>>>
>>>
>>
>> --
>> -- Yawar Raza
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mlt...@ml....
>> _______________________________________________
>> MLton-user mailing list
>> MLt...@li...; mlt...@ml...
>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

[Matthew F. <mat...@gm...>]

Aranav isn’t subscribed, so I needed to moderate/accept the email before it
was sent to the whole list.

On Thu, Jul 24, 2025 at 8:03 PM 'Yawar Raza (RIT Student)' via MLton-user <
mlt...@ml...> wrote:

> Nevermind to my first paragraph. I just received the original email.
> Apparently they can get sent to me out of order...
>
> On Thursday, July 24, 2025, Yawar Raza (RIT Student) <ys...@ri...>
> wrote:
>
>> Arnav, I think you might need to use "Reply-All" for the reply to remain
>> on the mailing list, as only Prof. Fluet got your second email (I didn't
>> get it, at least).
>>
>> Anyway, I don't think "stopping the MLton compiler part way through" is
>> the best way to do the sort of thing you're trying to do.
>>
>> Something you _could_ look into is this one family of SML tricks centered
>> around http://mlton.org/Fold, possibly more specifically
>> http://mlton.org/VariableArityPolymorphism. I don't really understand
>> these libraries though, and I'm personally very averse to this sort of code.
>>
>> I don't really get what you're trying to do. Why do you have a
>> generator-generator? Is the generator (output by the generator-generator)
>> in SML itself or does it just output SML? Does it output just datatype
>> declarations or complete programs? I think saying what each level inputs
>> and outputs would be helpful.
>>
>> In general, you should probably end up doing one of the following:
>> - Push arity-polymorphism or similarly un-simple stuff up one generator
>> level, generating different SML source code text for each (rather than
>> trying to extract MLton compiler output).
>> - Give up on perfect type safety relating to arities, and just have the
>> different arities of some things share a single general type.
>> - Use a different language that either has dependent types (e.g. Idris)
>> or has more featureful metaprogramming (e.g. F# with its type providers).
>>
>> But maybe I'm just misunderstanding something. Feel free to ignore those
>> last two paragraph if so, but I hope those two MLton links above were
>> useful to learn exist, at least.
>>
>>
>> On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...>
>> wrote:
>>>
>>> Well, if you just want a somewhat normalized representation of the
>>> types, then you might just use the CoreML representation immediately after
>>> elaboration (`-keep-pass parseAndElaborate`).
>>>
>>> For example:
>>> ```
>>> $ cat z.sml
>>> datatype zero = Zero
>>> datatype 'n succ = Succ
>>>
>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
>>> my_list
>>> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
>>> $ mlton -keep-pass parseAndElaborate z.sml
>>> $ tail z.parseAndElaborate.post.core-ml
>>> (* deadCode: true *)
>>> (* deadCode: true *)
>>> (* deadCode: false *)
>>> datatype zero_21 = Zero_0
>>> datatype 'a_4547 succ_2 = Succ_0
>>> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>>>                                         | Cons_0 of 'a_4549
>>>                                                     * ('a_4549, 'a_4548)
>>> my_list_0
>>> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>>>    raise (Fail_0 "todo")
>>> ```
>>>
>>> But, note, you'll still need to see through the uniquification of all
>>> identifiers.
>>>
>>> -Matthew
>>>
>>> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <
>>> arn...@an...> wrote:
>>>
>>>> Hello Matthew,
>>>>
>>>> Thank you for your response! My larger goal here is to make a random
>>>> generator for (regular) SML inductive types that allows the user to
>>>> configure "target sizes" for every inductive structure within their type.
>>>> The type labels are meant to be a way for the user and the tool to agree on
>>>> a common language for referring to said inductive types.
>>>>
>>>> For example, say the user wants to generate 2-d lists where the outer
>>>> list has length 3 and each inner list has length 2. Then, they'd define
>>>> their list type like so, building towards their monomorphic "final" type:
>>>> ```
>>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem,
>>>> 'index) my_list
>>>> type final = ((int, zero) my_list, zero succ) my_list
>>>> ```
>>>> This way, the user could later provide the lengths [2, 3] and the tool
>>>> would unambiguously be able to generate the type with the
>>>> specified constraints.
>>>>
>>>> Oh, and I'm writing the "random generator"-generator tool in OCaml. So,
>>>> I suppose one way could be to parse out the data-type and type declarations
>>>> from source, while these tags still hang around. But then I'd have to
>>>> "evaluate" type applications to bring them into a normal form, due to the
>>>> lingering type variables...which is why I was considering delaying the
>>>> point at which I "parse into an OCaml representation" as much as possible.
>>>>
>>>> Happy to clarify more if necessary, would greatly appreciate your
>>>> advice!
>>>>
>>>> Arnav.
>>>>
>>>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <mat...@gm...>
>>>> wrote:
>>>>
>>>>> Arnav,
>>>>>
>>>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism whatsoever
>>>>> (for functions or datatypes) and type parameters that do not contribute to
>>>>> the representation of a datatype will have been eliminated.
>>>>>
>>>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>>>> optimization will have already eliminated these unused type parameters,
>>>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>>>> that may be present for high-level API reasons, but do not affect the
>>>>> dynamics because they do not influence the data representation.
>>>>>
>>>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>>>> of your tagged datatypes to be separately monmorphised, though with the
>>>>> current heuristics for naming monomorphised variants, you probably won't
>>>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>>>> SXML program.
>>>>>
>>>>> Could you say a bit more about your goals?  That might help to inform
>>>>> whether there is a better way to accomplish what you are trying to do.
>>>>>
>>>>> -Matthew
>>>>>
>>>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <
>>>>> arn...@an...> wrote:
>>>>>
>>>>>> Hello,
>>>>>>
>>>>>> I'm trying to tag every instance of a recursive type in a type
>>>>>> definition with a tag. This tag is essentially a "type-level natural
>>>>>> number". By way of example, here's what I mean:
>>>>>>
>>>>>> datatype zero = Zero
>>>>>> datatype 'n succ = Succ
>>>>>>
>>>>>> (* example: rose tree *)
>>>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>>>
>>>>>> (* example: tree with int list data *)
>>>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>>>
>>>>>> As seen, each type is given as many type parameters as is necessary
>>>>>> to instantiate its own tag as well as the tags of its "recursive
>>>>>> sub-structures". The first type argument is meant for the tag of the
>>>>>> recursive type currently being defined.
>>>>>>
>>>>>> Now, when I use MLton to compile this, the tag types seem to be
>>>>>> removed during monomorphization. Thus,
>>>>>>
>>>>>> (zero, zero succ) rose_tree
>>>>>> and
>>>>>>
>>>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>>>> appear to be the same type in SXML. What are my options here, if I'd
>>>>>> like to maintain such a type level distinction? Is XML necessarily the
>>>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>>>> some advice here!
>>>>>>
>>>>>> Thank you,
>>>>>> Arnav.
>>>>>> ,
>>>>>>
>>>>>> To unsubscribe from this group and stop receiving emails from it,
>>>>>> send an email to mlt...@ml....
>>>>>> _______________________________________________
>>>>>> MLton-user mailing list
>>>>>> MLt...@li...; mlt...@ml...
>>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>>>
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mlt...@ml....
>>>
>>
>>
>> --
>> -- Yawar Raza
>>
>>
>
> --
> -- Yawar Raza
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

['Yawar R. (R. Student)' v. MLton-u. <mlt...@ml...>]

Nevermind to my first paragraph. I just received the original email.
Apparently they can get sent to me out of order...

On Thursday, July 24, 2025, Yawar Raza (RIT Student) <ys...@ri...>
wrote:

> Arnav, I think you might need to use "Reply-All" for the reply to remain
> on the mailing list, as only Prof. Fluet got your second email (I didn't
> get it, at least).
>
> Anyway, I don't think "stopping the MLton compiler part way through" is
> the best way to do the sort of thing you're trying to do.
>
> Something you _could_ look into is this one family of SML tricks centered
> around http://mlton.org/Fold, possibly more specifically http://mlton.org/
> VariableArityPolymorphism. I don't really understand these libraries
> though, and I'm personally very averse to this sort of code.
>
> I don't really get what you're trying to do. Why do you have a
> generator-generator? Is the generator (output by the generator-generator)
> in SML itself or does it just output SML? Does it output just datatype
> declarations or complete programs? I think saying what each level inputs
> and outputs would be helpful.
>
> In general, you should probably end up doing one of the following:
> - Push arity-polymorphism or similarly un-simple stuff up one generator
> level, generating different SML source code text for each (rather than
> trying to extract MLton compiler output).
> - Give up on perfect type safety relating to arities, and just have the
> different arities of some things share a single general type.
> - Use a different language that either has dependent types (e.g. Idris) or
> has more featureful metaprogramming (e.g. F# with its type providers).
>
> But maybe I'm just misunderstanding something. Feel free to ignore those
> last two paragraph if so, but I hope those two MLton links above were
> useful to learn exist, at least.
>
>
> On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...> wrote:
>>
>> Well, if you just want a somewhat normalized representation of the types,
>> then you might just use the CoreML representation immediately after
>> elaboration (`-keep-pass parseAndElaborate`).
>>
>> For example:
>> ```
>> $ cat z.sml
>> datatype zero = Zero
>> datatype 'n succ = Succ
>>
>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
>> my_list
>> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
>> $ mlton -keep-pass parseAndElaborate z.sml
>> $ tail z.parseAndElaborate.post.core-ml
>> (* deadCode: true *)
>> (* deadCode: true *)
>> (* deadCode: false *)
>> datatype zero_21 = Zero_0
>> datatype 'a_4547 succ_2 = Succ_0
>> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>>                                         | Cons_0 of 'a_4549
>>                                                     * ('a_4549, 'a_4548)
>> my_list_0
>> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>>    raise (Fail_0 "todo")
>> ```
>>
>> But, note, you'll still need to see through the uniquification of all
>> identifiers.
>>
>> -Matthew
>>
>> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <arn...@an...>
>> wrote:
>>
>>> Hello Matthew,
>>>
>>> Thank you for your response! My larger goal here is to make a random
>>> generator for (regular) SML inductive types that allows the user to
>>> configure "target sizes" for every inductive structure within their type.
>>> The type labels are meant to be a way for the user and the tool to agree on
>>> a common language for referring to said inductive types.
>>>
>>> For example, say the user wants to generate 2-d lists where the outer
>>> list has length 3 and each inner list has length 2. Then, they'd define
>>> their list type like so, building towards their monomorphic "final" type:
>>> ```
>>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
>>> my_list
>>> type final = ((int, zero) my_list, zero succ) my_list
>>> ```
>>> This way, the user could later provide the lengths [2, 3] and the tool
>>> would unambiguously be able to generate the type with the
>>> specified constraints.
>>>
>>> Oh, and I'm writing the "random generator"-generator tool in OCaml. So,
>>> I suppose one way could be to parse out the data-type and type declarations
>>> from source, while these tags still hang around. But then I'd have to
>>> "evaluate" type applications to bring them into a normal form, due to the
>>> lingering type variables...which is why I was considering delaying the
>>> point at which I "parse into an OCaml representation" as much as possible.
>>>
>>> Happy to clarify more if necessary, would greatly appreciate your advice!
>>>
>>> Arnav.
>>>
>>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <mat...@gm...>
>>> wrote:
>>>
>>>> Arnav,
>>>>
>>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism whatsoever
>>>> (for functions or datatypes) and type parameters that do not contribute to
>>>> the representation of a datatype will have been eliminated.
>>>>
>>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>>> optimization will have already eliminated these unused type parameters,
>>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>>> that may be present for high-level API reasons, but do not affect the
>>>> dynamics because they do not influence the data representation.
>>>>
>>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>>> of your tagged datatypes to be separately monmorphised, though with the
>>>> current heuristics for naming monomorphised variants, you probably won't
>>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>>> SXML program.
>>>>
>>>> Could you say a bit more about your goals?  That might help to inform
>>>> whether there is a better way to accomplish what you are trying to do.
>>>>
>>>> -Matthew
>>>>
>>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <
>>>> arn...@an...> wrote:
>>>>
>>>>> Hello,
>>>>>
>>>>> I'm trying to tag every instance of a recursive type in a type
>>>>> definition with a tag. This tag is essentially a "type-level natural
>>>>> number". By way of example, here's what I mean:
>>>>>
>>>>> datatype zero = Zero
>>>>> datatype 'n succ = Succ
>>>>>
>>>>> (* example: rose tree *)
>>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>>
>>>>> (* example: tree with int list data *)
>>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>>
>>>>> As seen, each type is given as many type parameters as is necessary to
>>>>> instantiate its own tag as well as the tags of its "recursive
>>>>> sub-structures". The first type argument is meant for the tag of the
>>>>> recursive type currently being defined.
>>>>>
>>>>> Now, when I use MLton to compile this, the tag types seem to be
>>>>> removed during monomorphization. Thus,
>>>>>
>>>>> (zero, zero succ) rose_tree
>>>>> and
>>>>>
>>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>>> appear to be the same type in SXML. What are my options here, if I'd
>>>>> like to maintain such a type level distinction? Is XML necessarily the
>>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>>> some advice here!
>>>>>
>>>>> Thank you,
>>>>> Arnav.
>>>>> ,
>>>>>
>>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>>> an email to mlt...@ml....
>>>>> _______________________________________________
>>>>> MLton-user mailing list
>>>>> MLt...@li...; mlt...@ml...
>>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>> an email to mlt...@ml....
>>
>
>
> --
> -- Yawar Raza
>
>

-- 
-- Yawar Raza

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

['Yawar R. (R. Student)' v. MLton-u. <mlt...@ml...>]

Arnav, I think you might need to use "Reply-All" for the reply to remain on
the mailing list, as only Prof. Fluet got your second email (I didn't get
it, at least).

Anyway, I don't think "stopping the MLton compiler part way through" is the
best way to do the sort of thing you're trying to do.

Something you _could_ look into is this one family of SML tricks centered
around http://mlton.org/Fold, possibly more specifically
http://mlton.org/VariableArityPolymorphism. I don't really understand these
libraries though, and I'm personally very averse to this sort of code.

I don't really get what you're trying to do. Why do you have a
generator-generator? Is the generator (output by the generator-generator)
in SML itself or does it just output SML? Does it output just datatype
declarations or complete programs? I think saying what each level inputs
and outputs would be helpful.

In general, you should probably end up doing one of the following:
- Push arity-polymorphism or similarly un-simple stuff up one generator
level, generating different SML source code text for each (rather than
trying to extract MLton compiler output).
- Give up on perfect type safety relating to arities, and just have the
different arities of some things share a single general type.
- Use a different language that either has dependent types (e.g. Idris) or
has more featureful metaprogramming (e.g. F# with its type providers).

But maybe I'm just misunderstanding something. Feel free to ignore those
last two paragraph if so, but I hope those two MLton links above were
useful to learn exist, at least.


On Thursday, July 24, 2025, Matthew Fluet <mat...@gm...> wrote:
>
> Well, if you just want a somewhat normalized representation of the types,
> then you might just use the CoreML representation immediately after
> elaboration (`-keep-pass parseAndElaborate`).
>
> For example:
> ```
> $ cat z.sml
> datatype zero = Zero
> datatype 'n succ = Succ
>
> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
> my_list
> val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
> $ mlton -keep-pass parseAndElaborate z.sml
> $ tail z.parseAndElaborate.post.core-ml
> (* deadCode: true *)
> (* deadCode: true *)
> (* deadCode: false *)
> datatype zero_21 = Zero_0
> datatype 'a_4547 succ_2 = Succ_0
> datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
>                                         | Cons_0 of 'a_4549
>                                                     * ('a_4549, 'a_4548)
> my_list_0
> val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
>    raise (Fail_0 "todo")
> ```
>
> But, note, you'll still need to see through the uniquification of all
> identifiers.
>
> -Matthew
>
> On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <arn...@an...>
> wrote:
>
>> Hello Matthew,
>>
>> Thank you for your response! My larger goal here is to make a random
>> generator for (regular) SML inductive types that allows the user to
>> configure "target sizes" for every inductive structure within their type.
>> The type labels are meant to be a way for the user and the tool to agree on
>> a common language for referring to said inductive types.
>>
>> For example, say the user wants to generate 2-d lists where the outer
>> list has length 3 and each inner list has length 2. Then, they'd define
>> their list type like so, building towards their monomorphic "final" type:
>> ```
>> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
>> my_list
>> type final = ((int, zero) my_list, zero succ) my_list
>> ```
>> This way, the user could later provide the lengths [2, 3] and the tool
>> would unambiguously be able to generate the type with the
>> specified constraints.
>>
>> Oh, and I'm writing the "random generator"-generator tool in OCaml. So, I
>> suppose one way could be to parse out the data-type and type declarations
>> from source, while these tags still hang around. But then I'd have to
>> "evaluate" type applications to bring them into a normal form, due to the
>> lingering type variables...which is why I was considering delaying the
>> point at which I "parse into an OCaml representation" as much as possible.
>>
>> Happy to clarify more if necessary, would greatly appreciate your advice!
>>
>> Arnav.
>>
>> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <mat...@gm...>
>> wrote:
>>
>>> Arnav,
>>>
>>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism whatsoever
>>> (for functions or datatypes) and type parameters that do not contribute to
>>> the representation of a datatype will have been eliminated.
>>>
>>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>>> optimization will have already eliminated these unused type parameters,
>>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>>> duplication by monomorphisation that is unnecessary, due to type parameters
>>> that may be present for high-level API reasons, but do not affect the
>>> dynamics because they do not influence the data representation.
>>>
>>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>>> of your tagged datatypes to be separately monmorphised, though with the
>>> current heuristics for naming monomorphised variants, you probably won't
>>> get any evidence of the `zero` or `succ` type parameters remaining in the
>>> SXML program.
>>>
>>> Could you say a bit more about your goals?  That might help to inform
>>> whether there is a better way to accomplish what you are trying to do.
>>>
>>> -Matthew
>>>
>>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <arn...@an...>
>>> wrote:
>>>
>>>> Hello,
>>>>
>>>> I'm trying to tag every instance of a recursive type in a type
>>>> definition with a tag. This tag is essentially a "type-level natural
>>>> number". By way of example, here's what I mean:
>>>>
>>>> datatype zero = Zero
>>>> datatype 'n succ = Succ
>>>>
>>>> (* example: rose tree *)
>>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>>
>>>> (* example: tree with int list data *)
>>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>>
>>>> As seen, each type is given as many type parameters as is necessary to
>>>> instantiate its own tag as well as the tags of its "recursive
>>>> sub-structures". The first type argument is meant for the tag of the
>>>> recursive type currently being defined.
>>>>
>>>> Now, when I use MLton to compile this, the tag types seem to be removed
>>>> during monomorphization. Thus,
>>>>
>>>> (zero, zero succ) rose_tree
>>>> and
>>>>
>>>> (zero succ succ, zero succ succ succ) rose_tree)
>>>> appear to be the same type in SXML. What are my options here, if I'd
>>>> like to maintain such a type level distinction? Is XML necessarily the
>>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>>> some advice here!
>>>>
>>>> Thank you,
>>>> Arnav.
>>>> ,
>>>>
>>>> To unsubscribe from this group and stop receiving emails from it, send
>>>> an email to mlt...@ml....
>>>> _______________________________________________
>>>> MLton-user mailing list
>>>> MLt...@li...; mlt...@ml...
>>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
> an email to mlt...@ml....
>


-- 
-- Yawar Raza

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

[Matthew F. <mat...@gm...>]

Well, if you just want a somewhat normalized representation of the types,
then you might just use the CoreML representation immediately after
elaboration (`-keep-pass parseAndElaborate`).

For example:
```
$ cat z.sml
datatype zero = Zero
datatype 'n succ = Succ

datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
my_list
val z : ((int, zero) my_list, zero succ) my_list = raise Fail "todo"
$ mlton -keep-pass parseAndElaborate z.sml
$ tail z.parseAndElaborate.post.core-ml
(* deadCode: true *)
(* deadCode: true *)
(* deadCode: false *)
datatype zero_21 = Zero_0
datatype 'a_4547 succ_2 = Succ_0
datatype ('a_4549, 'a_4548) my_list_0 = Nil_0
                                        | Cons_0 of 'a_4549
                                                    * ('a_4549, 'a_4548)
my_list_0
val z_26: ((int32, zero_21) my_list_0, zero_21 succ_2) my_list_0 =
   raise (Fail_0 "todo")
```

But, note, you'll still need to see through the uniquification of all
identifiers.

-Matthew

On Thu, Jul 24, 2025 at 10:48 AM Arnav Sabharwal <arn...@an...>
wrote:

> Hello Matthew,
>
> Thank you for your response! My larger goal here is to make a random
> generator for (regular) SML inductive types that allows the user to
> configure "target sizes" for every inductive structure within their type.
> The type labels are meant to be a way for the user and the tool to agree on
> a common language for referring to said inductive types.
>
> For example, say the user wants to generate 2-d lists where the outer list
> has length 3 and each inner list has length 2. Then, they'd define their
> list type like so, building towards their monomorphic "final" type:
> ```
> datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
> my_list
> type final = ((int, zero) my_list, zero succ) my_list
> ```
> This way, the user could later provide the lengths [2, 3] and the tool
> would unambiguously be able to generate the type with the
> specified constraints.
>
> Oh, and I'm writing the "random generator"-generator tool in OCaml. So, I
> suppose one way could be to parse out the data-type and type declarations
> from source, while these tags still hang around. But then I'd have to
> "evaluate" type applications to bring them into a normal form, due to the
> lingering type variables...which is why I was considering delaying the
> point at which I "parse into an OCaml representation" as much as possible.
>
> Happy to clarify more if necessary, would greatly appreciate your advice!
>
> Arnav.
>
> On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <mat...@gm...>
> wrote:
>
>> Arnav,
>>
>> Yes, in SXML ("Simply-typed" XML), there is no polymorphism whatsoever
>> (for functions or datatypes) and type parameters that do not contribute to
>> the representation of a datatype will have been eliminated.
>>
>> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
>> optimization will have already eliminated these unused type parameters,
>> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
>> duplication by monomorphisation that is unnecessary, due to type parameters
>> that may be present for high-level API reasons, but do not affect the
>> dynamics because they do not influence the data representation.
>>
>> It may be that if you drop SimplifyTypes (compile with `-drop-pass
>> xmlSimplifyTypes`), then monomorphisation will force different "versions"
>> of your tagged datatypes to be separately monmorphised, though with the
>> current heuristics for naming monomorphised variants, you probably won't
>> get any evidence of the `zero` or `succ` type parameters remaining in the
>> SXML program.
>>
>> Could you say a bit more about your goals?  That might help to inform
>> whether there is a better way to accomplish what you are trying to do.
>>
>> -Matthew
>>
>> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <arn...@an...>
>> wrote:
>>
>>> Hello,
>>>
>>> I'm trying to tag every instance of a recursive type in a type
>>> definition with a tag. This tag is essentially a "type-level natural
>>> number". By way of example, here's what I mean:
>>>
>>> datatype zero = Zero
>>> datatype 'n succ = Succ
>>>
>>> (* example: rose tree *)
>>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>>
>>> (* example: tree with int list data *)
>>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>>
>>> As seen, each type is given as many type parameters as is necessary to
>>> instantiate its own tag as well as the tags of its "recursive
>>> sub-structures". The first type argument is meant for the tag of the
>>> recursive type currently being defined.
>>>
>>> Now, when I use MLton to compile this, the tag types seem to be removed
>>> during monomorphization. Thus,
>>>
>>> (zero, zero succ) rose_tree
>>> and
>>>
>>> (zero succ succ, zero succ succ succ) rose_tree)
>>> appear to be the same type in SXML. What are my options here, if I'd
>>> like to maintain such a type level distinction? Is XML necessarily the
>>> furthest down I can go in the compiler pipeline? I'd greatly appreciate
>>> some advice here!
>>>
>>> Thank you,
>>> Arnav.
>>> ,
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mlt...@ml....
>>> _______________________________________________
>>> MLton-user mailing list
>>> MLt...@li...; mlt...@ml...
>>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>>
>>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

[Arnav S. <arn...@an...>]

Hello Matthew,

Thank you for your response! My larger goal here is to make a random
generator for (regular) SML inductive types that allows the user to
configure "target sizes" for every inductive structure within their type.
The type labels are meant to be a way for the user and the tool to agree on
a common language for referring to said inductive types.

For example, say the user wants to generate 2-d lists where the outer list
has length 3 and each inner list has length 2. Then, they'd define their
list type like so, building towards their monomorphic "final" type:
```
datatype ('elem, 'index) my_list = Nil | Cons of 'elem * ('elem, 'index)
my_list
type final = ((int, zero) my_list, zero succ) my_list
```
This way, the user could later provide the lengths [2, 3] and the tool
would unambiguously be able to generate the type with the
specified constraints.

Oh, and I'm writing the "random generator"-generator tool in OCaml. So, I
suppose one way could be to parse out the data-type and type declarations
from source, while these tags still hang around. But then I'd have to
"evaluate" type applications to bring them into a normal form, due to the
lingering type variables...which is why I was considering delaying the
point at which I "parse into an OCaml representation" as much as possible.

Happy to clarify more if necessary, would greatly appreciate your advice!

Arnav.

On Thu, Jul 24, 2025 at 8:57 AM Matthew Fluet <mat...@gm...>
wrote:

> Arnav,
>
> Yes, in SXML ("Simply-typed" XML), there is no polymorphism whatsoever
> (for functions or datatypes) and type parameters that do not contribute to
> the representation of a datatype will have been eliminated.
>
> Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
> optimization will have already eliminated these unused type parameters,
> before monomorphisation.  The motivation for SimplifyTypes is to avoid code
> duplication by monomorphisation that is unnecessary, due to type parameters
> that may be present for high-level API reasons, but do not affect the
> dynamics because they do not influence the data representation.
>
> It may be that if you drop SimplifyTypes (compile with `-drop-pass
> xmlSimplifyTypes`), then monomorphisation will force different "versions"
> of your tagged datatypes to be separately monmorphised, though with the
> current heuristics for naming monomorphised variants, you probably won't
> get any evidence of the `zero` or `succ` type parameters remaining in the
> SXML program.
>
> Could you say a bit more about your goals?  That might help to inform
> whether there is a better way to accomplish what you are trying to do.
>
> -Matthew
>
> On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <arn...@an...>
> wrote:
>
>> Hello,
>>
>> I'm trying to tag every instance of a recursive type in a type definition
>> with a tag. This tag is essentially a "type-level natural number". By way
>> of example, here's what I mean:
>>
>> datatype zero = Zero
>> datatype 'n succ = Succ
>>
>> (* example: rose tree *)
>> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
>> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>>
>> (* example: tree with int list data *)
>> datatype 'list my_list = Nil | Cons of int * 'list my_list
>> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>>
>> As seen, each type is given as many type parameters as is necessary to
>> instantiate its own tag as well as the tags of its "recursive
>> sub-structures". The first type argument is meant for the tag of the
>> recursive type currently being defined.
>>
>> Now, when I use MLton to compile this, the tag types seem to be removed
>> during monomorphization. Thus,
>>
>> (zero, zero succ) rose_tree
>> and
>>
>> (zero succ succ, zero succ succ succ) rose_tree)
>> appear to be the same type in SXML. What are my options here, if I'd like
>> to maintain such a type level distinction? Is XML necessarily the furthest
>> down I can go in the compiler pipeline? I'd greatly appreciate some advice
>> here!
>>
>> Thank you,
>> Arnav.
>> ,
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mlt...@ml....
>> _______________________________________________
>> MLton-user mailing list
>> MLt...@li...; mlt...@ml...
>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>
>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Interplay between empty datatypes and monomorphisation

[Matthew F. <mat...@gm...>]

Arnav,

Yes, in SXML ("Simply-typed" XML), there is no polymorphism whatsoever (for
functions or datatypes) and type parameters that do not contribute to the
representation of a datatype will have been eliminated.

Actually, the SimplfyTypes (http://mlton.org/XMLSimplifyTypes) XML
optimization will have already eliminated these unused type parameters,
before monomorphisation.  The motivation for SimplifyTypes is to avoid code
duplication by monomorphisation that is unnecessary, due to type parameters
that may be present for high-level API reasons, but do not affect the
dynamics because they do not influence the data representation.

It may be that if you drop SimplifyTypes (compile with `-drop-pass
xmlSimplifyTypes`), then monomorphisation will force different "versions"
of your tagged datatypes to be separately monmorphised, though with the
current heuristics for naming monomorphised variants, you probably won't
get any evidence of the `zero` or `succ` type parameters remaining in the
SXML program.

Could you say a bit more about your goals?  That might help to inform
whether there is a better way to accomplish what you are trying to do.

-Matthew

On Thu, Jul 24, 2025 at 5:24 AM Arnav Sabharwal <arn...@an...>
wrote:

> Hello,
>
> I'm trying to tag every instance of a recursive type in a type definition
> with a tag. This tag is essentially a "type-level natural number". By way
> of example, here's what I mean:
>
> datatype zero = Zero
> datatype 'n succ = Succ
>
> (* example: rose tree *)
> datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
> and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list
>
> (* example: tree with int list data *)
> datatype 'list my_list = Nil | Cons of int * 'list my_list
> and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree * 'list my_list * ('tree, 'list) my_tree
>
> As seen, each type is given as many type parameters as is necessary to
> instantiate its own tag as well as the tags of its "recursive
> sub-structures". The first type argument is meant for the tag of the
> recursive type currently being defined.
>
> Now, when I use MLton to compile this, the tag types seem to be removed
> during monomorphization. Thus,
>
> (zero, zero succ) rose_tree
> and
>
> (zero succ succ, zero succ succ succ) rose_tree)
> appear to be the same type in SXML. What are my options here, if I'd like
> to maintain such a type level distinction? Is XML necessarily the furthest
> down I can go in the compiler pipeline? I'd greatly appreciate some advice
> here!
>
> Thank you,
> Arnav.
> ,
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] Interplay between empty datatypes and monomorphisation

[Arnav S. <arn...@an...>]

Hello,

I'm trying to tag every instance of a recursive type in a type definition
with a tag. This tag is essentially a "type-level natural number". By way
of example, here's what I mean:

datatype zero = Zero
datatype 'n succ = Succ

(* example: rose tree *)
datatype ('tree, 'list) rose_tree = Node of int * ('list, 'tree) rose_list
and ('list, 'tree) rose_list = Nil | Cons of int * ('tree, 'list) rose_list

(* example: tree with int list data *)
datatype 'list my_list = Nil | Cons of int * 'list my_list
and ('tree, 'list) my_tree = Leaf | Node of ('tree, 'list) my_tree *
'list my_list * ('tree, 'list) my_tree

As seen, each type is given as many type parameters as is necessary to
instantiate its own tag as well as the tags of its "recursive
sub-structures". The first type argument is meant for the tag of the
recursive type currently being defined.

Now, when I use MLton to compile this, the tag types seem to be removed
during monomorphization. Thus,

(zero, zero succ) rose_tree
and

(zero succ succ, zero succ succ succ) rose_tree)
appear to be the same type in SXML. What are my options here, if I'd like
to maintain such a type level distinction? Is XML necessarily the furthest
down I can go in the compiler pipeline? I'd greatly appreciate some advice
here!

Thank you,
Arnav.
,

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ICFP/SPLASH 2025: call for volunteers

['ICFP P. v. MLton-u. <mlt...@ml...>]

ICFP/SPLASH 2025 are looking for volunteers to help with the organization
and smooth running of the conference. In exchange, volunteers receive:

   - Free conference registration (including banquet)
   - Free lunches and refreshments during breaks
   - Volunteer shirt
   - Admission to all social events

*Note: Travel and accommodation are not covered.*

*Who can apply? *Anyone can apply. Priority will be given to junior members
of the community, such as students in computer science or related fields.

*Availability. *Volunteers must be available for at least five (5) full
days between October 12–18, 2025, and should be ready to help with various
tasks during that period. Some pre-conference coordination and training may
be required. We welcome both virtual and in-person volunteers from all time
zones.

*Apply here: *https://tinyurl.com/splashifcp25-sv-application

*More details: *
https://conf.researchr.org/track/icfp-splash-2025/icfp-splash-2025-volunteers

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ML Family Workshop 2025: extended deadline: July 3

[Samuel W. <sh...@ny...>]

We’ve extended the deadline for the ML Family Workshop! The new deadline is July 3.

If you (or someone you know) is planning to attend ICFP/SPLASH, we encourage you to consider submitting! The submission requirements are small (only a couple pages), and the scope of the workshop is broad: language design, implementation, memory management, type systems, semantics, applications, tooling, debugging, program analysis -- it's all fair game. This is a great opportunity to discuss works-in-progress, or demo something you've been building, or discuss an interesting take on language design.

Full CFP below, with updated deadline. We hope you will consider submitting!


# Higher-order, Typed, Inferred, Strict:
# ML Family Workshop 2025

October 16, 2025, Singapore
(Co-located with ICFP/SPLASH)

Website:
https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025

Submission Link:
https://ml2025.hotcrp.com/

Submission Deadline (extended!):
July 3, 2025, AoE


## Call for Presentations

ML (originally, "Meta Language") is a family of programming languages that includes dialects known as Standard ML, OCaml, and F#, among others. The development of these languages has inspired a large amount of computer science research, both practical and theoretical.

The ML 2025 workshop will continue the informal approach followed since 2010. Presentations are selected by the program committee from submitted proposals. There are no published proceedings, so contributions may be submitted for publication elsewhere. The main criterion is promoting and informing the development of the entire extended ML family and delivering a lively workshop atmosphere. We particularly encourage talks about works in progress, presentations of negative results (things that were expected to but did not quite work out) and informed positions.

Each presentation should take 20-25 minutes. The exact time will be decided based on scheduling constraints.

We plan the workshop to an be in-person event with remote participation (streamed live). We hope that speakers are able to present in person. If a speaker is unable to attend, they may instead present remotely.

The 2025 ML Family Workshop is co-located with ICFP/SPLASH 2025 and will take place on **October 16, 2025** in Singapore.

## Scope

We seek presentations on topics including (but not limited to):

Language design: abstraction, higher forms of polymorphism, concurrency and parallelism, distribution and mobility, staging, extensions for semi-structured data, generic programming, object systems, etc.

Implementation: compilers, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, foreign function interfaces, etc.

Type systems: inference, effects, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc.

Applications: case studies, experience reports, pearls, etc.

Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc.

Semantics of ML-family languages: operational and denotational semantics, program equivalence, parametricity, mechanization, etc.

We specifically encourage reporting what did not meet expectations or
what, despite all efforts, did not work to satisfaction.

Four kinds of submissions are solicited: Research Presentations,
Experience Reports, Demos, and Informed Positions.

Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users.

Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve.

Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML and related languages. (You will need to provide all the hardware and software required for your demo; the workshop organizers are only able to provide a projector.)

Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g., by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples.


## Submission details

Submissions must be in the PDF format and have a short summary (abstract) at the beginning. Submissions in the categories of Experience Reports, Demos, or Informed Positions should indicate so in the title or subtitle. The point of the submission should be clear from its two first pages (PC members are not obligated to read any further.)

Submissions must be uploaded to the workshop submission website before the submission deadline.

Only the short summary/abstract of accepted submissions will be published on the conference website. After acceptance, authors will have the opportunity to attach or link to that summary any relevant material (such as the updated submission, slides, etc.)

**Submission Website**:
https://ml2025.hotcrp.com/

**Workshop Website**:
https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025


## Dates and Deadlines

**Submission Deadline (extended!)**:
Thursday, July 3, AoE

**Initial Author Notification** (most cases):
Thursday, July 31

**Final Author Notification** (if needed):
Thursday, Aug 7

**Workshop Date**:
Thursday, Oct 16


## Program Committee

Sam Westrick (New York University, USA) (Chair)
Michael D. Adams (National University of Singapore, Singapore)
Jonathan Brachthäuser (University of Tübingen, Germany)
Chris Casinghino (Jane Street, USA)
Arthur Charguéraud (INRIA, France)
Kiran Gopinathan (University of Illinois Urbana-Champaign, USA)
Mirai Ikebuchi (Kyoto University, Japan)
Keigo Imai (DeNA Co., Ltd., Japan)
Anton Lorenzen (University of Edinburgh, UK)
Cyrus Omar (University of Michigan, USA)
Zoe Paraskevopoulou (National Technical University of Athens, Greece)
Filip Sieczkowski (Heriot-Watt University, UK)
Yong Kiam Tan (A*STAR Institute for Infocomm Research, Singapore)
Yuting Wang (Shanghai Jiao Tong University, China)

## Past Iterations

2024: https://icfp24.sigplan.org/home/mlworkshop-2024
2023: https://icfp23.sigplan.org/home/mlworkshop-2023
2022: https://icfp22.sigplan.org/home/mlfamilyworkshop-2022
2021: https://icfp21.sigplan.org/home/mlfamilyworkshop-2021

More info: https://www.mlworkshop.org/home

## Coordination with the OCaml Users and Developers Workshop

The OCaml workshop is seen as more practical and is dedicated in significant part to OCaml community building and the development of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research-oriented, and deals with general issues of ML-style programming and type systems. There is some overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the program chairs.

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ML Family Workshop 2025: 2nd CFP: deadline June 19!

[Samuel W. <sh...@ny...>]

# Higher-order, Typed, Inferred, Strict:
# ML Family Workshop 2025

October 16, 2025, Singapore
(Co-located with ICFP/SPLASH)

Website:
https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025

Submission Link:
https://ml2025.hotcrp.com/

Submission Deadline:
June 19, 2025, AoE


## Call for Presentations

ML (originally, "Meta Language") is a family of programming languages that includes dialects known as Standard ML, OCaml, and F#, among others. The development of these languages has inspired a large amount of computer science research, both practical and theoretical.

The ML 2025 workshop will continue the informal approach followed since 2010. Presentations are selected by the program committee from submitted proposals. There are no published proceedings, so contributions may be submitted for publication elsewhere. The main criterion is promoting and informing the development of the entire extended ML family and delivering a lively workshop atmosphere. We particularly encourage talks about works in progress, presentations of negative results (things that were expected to but did not quite work out) and informed positions.

Each presentation should take 20-25 minutes. The exact time will be decided based on scheduling constraints.

We plan the workshop to an be in-person event with remote participation (streamed live). We hope that speakers are able to present in person. If a speaker is unable to attend, they may instead present remotely.

The 2025 ML Family Workshop is co-located with ICFP/SPLASH 2025 and will take place on **October 16, 2025** in Singapore.

## Scope

We seek presentations on topics including (but not limited to):

Language design: abstraction, higher forms of polymorphism, concurrency and parallelism, distribution and mobility, staging, extensions for semi-structured data, generic programming, object systems, etc.

Implementation: compilers, interpreters, type checkers, partial evaluators, runtime systems, garbage collectors, foreign function interfaces, etc.

Type systems: inference, effects, modules, contracts, specifications and assertions, dynamic typing, error reporting, etc.

Applications: case studies, experience reports, pearls, etc.

Environments: libraries, tools, editors, debuggers, cross-language interoperability, functional data structures, etc.

Semantics of ML-family languages: operational and denotational semantics, program equivalence, parametricity, mechanization, etc.

We specifically encourage reporting what did not meet expectations or
what, despite all efforts, did not work to satisfaction.

Four kinds of submissions are solicited: Research Presentations,
Experience Reports, Demos, and Informed Positions.

Research Presentations: Research presentations should describe new ideas, experimental results, or significant advances in ML-related projects. We especially encourage presentations that describe work in progress, that outline a future research agenda, or that encourage lively discussion. These presentations should be structured in a way which can be, at least in part, of interest to (advanced) users.

Experience Reports: Users are invited to submit Experience Reports about their use of ML and related languages. These presentations do not need to contain original research but they should tell an interesting story to researchers or other advanced users, such as an innovative or unexpected use of advanced features or a description of the challenges they are facing or attempting to solve.

Demos: Live demonstrations or short tutorials should show new developments, interesting prototypes, or work in progress, in the form of tools, libraries, or applications built on or related to ML and related languages. (You will need to provide all the hardware and software required for your demo; the workshop organizers are only able to provide a projector.)

Informed Positions: A justified argument for or against a language feature. The argument must be substantiated, either theoretically (e.g., by a demonstration of (un)soundness, an inference algorithm, a complexity analysis), empirically or by substantial experience. Personal experience is accepted as justification so long as it is extensive and illustrated with concrete examples.


## Submission details

Submissions must be in the PDF format and have a short summary (abstract) at the beginning. Submissions in the categories of Experience Reports, Demos, or Informed Positions should indicate so in the title or subtitle. The point of the submission should be clear from its two first pages (PC members are not obligated to read any further.)

Submissions must be uploaded to the workshop submission website before the submission deadline.

Only the short summary/abstract of accepted submissions will be published on the conference website. After acceptance, authors will have the opportunity to attach or link to that summary any relevant material (such as the updated submission, slides, etc.)

**Submission Website**:
https://ml2025.hotcrp.com/

**Workshop Website**:
https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025


## Dates and Deadlines

**Submission Deadline**:
Thursday, June 19 AoE

**Initial Author Notification** (most cases):
Thursday, July 31

**Final Author Notification** (if needed):
Thursday, Aug 7

**Workshop Date**:
Thursday, Oct 16


## Program Committee

Sam Westrick (New York University, USA) (Chair)
Michael D. Adams (National University of Singapore, Singapore)
Jonathan Brachthäuser (University of Tübingen, Germany)
Chris Casinghino (Jane Street, USA)
Arthur Charguéraud (INRIA, France)
Kiran Gopinathan (University of Illinois Urbana-Champaign, USA)
Mirai Ikebuchi (Kyoto University, Japan)
Keigo Imai (DeNA Co., Ltd., Japan)
Anton Lorenzen (University of Edinburgh, UK)
Cyrus Omar (University of Michigan, USA)
Zoe Paraskevopoulou (National Technical University of Athens, Greece)
Filip Sieczkowski (Heriot-Watt University, UK)
Yong Kiam Tan (A*STAR Institute for Infocomm Research, Singapore)
Yuting Wang (Shanghai Jiao Tong University, China)

## Past Iterations

2024: https://icfp24.sigplan.org/home/mlworkshop-2024
2023: https://icfp23.sigplan.org/home/mlworkshop-2023
2022: https://icfp22.sigplan.org/home/mlfamilyworkshop-2022
2021: https://icfp21.sigplan.org/home/mlfamilyworkshop-2021

More info: https://www.mlworkshop.org/home

## Coordination with the OCaml Users and Developers Workshop

The OCaml workshop is seen as more practical and is dedicated in significant part to OCaml community building and the development of the OCaml system. In contrast, the ML family workshop is not focused on any language in particular, is more research-oriented, and deals with general issues of ML-style programming and type systems. There is some overlap, which we are keen to explore in various ways. The authors who feel their submission fits both workshops are encouraged to mention it at submission time or contact the program chairs.

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] [Suspected Spam] Tyvarseq in function?

[Humza <hum...@gm...>]

Thanks for your explanation Yawar. I appreciate it, and I think I
understand your explanation (hopefully), after experimenting with the
examples on the page you linked and going through the mentioned part of the
Definition.

I can see how that feature can be useful in ensuring that the same generic
type is used throughout.

On Thu, May 22, 2025, 07:04 'Yawar Raza (RIT Student)' via MLton-user <
mlt...@ml...> wrote:

> Typo: "run" and "wrap" are supposed to be the same. (I didn't know what to
> call it. 🤷‍♂️) The final code (with the fixed scoping as well) should be:
>
> fun 'a example i = let
>   val cell = ref i
>   val _ = cell : 'a ref
>
>   fun run f = (cell := f (!cell); !cell)
>   val _ = run : ('a -> 'a) -> 'a
>
>   in run
> end
>
> On Wednesday, May 21, 2025, Yawar Raza (RIT Student) <ys...@ri...>
> wrote:
>
>> You correctly notice that this feature is seldom used, but it can be
>> useful for when you want to annotate types for declarations nested in
>> functions. For example, suppose I wrote this function:
>>
>> fun example i = let
>>   val cell = ref i
>>   fun run f = (cell := f (!cell); !cell)
>>   in run
>> end
>>
>> But my code isn't working, so I need to debug it. I decide to make sure
>> these variables have the types I expect them to have with the following
>> technique:
>>
>> fun example i = let
>>   val cell = ref i
>>   val _ = cell : 'a ref
>>
>>   fun run f = (cell := f (!cell); !cell)
>>   val _ = wrap : ('a -> 'a) -> 'a
>>
>>   in run
>> end
>>
>> This doesn't compile because the 'a in cell's annotation isn't connected
>> to the 'a in wrap's annotation: SML is trying to make the annotations more
>> polymorphic than I want. Changing "fun example i" to "fun 'a example i"
>> fixes this to make both annotations refer to the same 'a.
>>
>> You can read more about this construct here:
>> http://mlton.org/TypeVariableScope
>>
>> On Wednesday, May 21, 2025, Humza <hum...@gm...> wrote:
>>
>>> RIT's anti-spam gateway has determined this message may be  spam
>>>
>>> If you have questions about this message, please contact the RIT Service
>>> Center at 585-475-5000, or help.rit.edu
>>>
>>> The original message as composed by the sender
>>> mlt...@li... is below
>>> -------------------------
>>>
>>> Hi all.
>>>
>>> This isn't strictly a question about MLton specifically, but I hoped to
>>> ask the clarification of something that confused me about SML's grammar.
>>>
>>> I can see in the Definition (and from my testing in PolyML's REPL) that
>>> value and function declarations like the following are accepted:
>>>
>>> $ val 'a myBook = true
>>> $ fun ('a, 'b) id x = x
>>>
>>> The reason is that the grammar in the Definition specifies:
>>>
>>> dec ::=
>>>   val tyvarseq valbind
>>>   fun tyvarseq fvalbind
>>>
>>> I don't understand the point of allowing tyvarseq here though, as these
>>> aren't type constraints, so I hoped to ask here. ,(Unlike type variables in
>>> a data type, they seem to be unused?)
>>>
>>> I was wondering as I hoped to create a small interpreter for a pure
>>> subset of SML, to help with compile times and maybe to allow scripting in
>>> an SML program.
>>>
>>> https://github.com/hummy123/sml-parser
>>>
>>> Thanks in advance,
>>> Humza
>>>
>>> PS: Appreciation note here for Phil Clayton who pointed me to the
>>> Definition a few months ago on this mailing list, which has been
>>> indispensable for understanding the grammar of SML and parsing it
>>>
>>> To unsubscribe from this group and stop receiving emails from it, send
>>> an email to mlt...@ml....
>>>
>>
>>
>> --
>> -- Yawar Raza
>>
>>
>
> --
> -- Yawar Raza
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] [Suspected Spam] Tyvarseq in function?

['Yawar R. (R. Student)' v. MLton-u. <mlt...@ml...>]

Typo: "run" and "wrap" are supposed to be the same. (I didn't know what to
call it. 🤷‍♂️) The final code (with the fixed scoping as well) should be:

fun 'a example i = let
  val cell = ref i
  val _ = cell : 'a ref

  fun run f = (cell := f (!cell); !cell)
  val _ = run : ('a -> 'a) -> 'a

  in run
end

On Wednesday, May 21, 2025, Yawar Raza (RIT Student) <ys...@ri...>
wrote:

> You correctly notice that this feature is seldom used, but it can be
> useful for when you want to annotate types for declarations nested in
> functions. For example, suppose I wrote this function:
>
> fun example i = let
>   val cell = ref i
>   fun run f = (cell := f (!cell); !cell)
>   in run
> end
>
> But my code isn't working, so I need to debug it. I decide to make sure
> these variables have the types I expect them to have with the following
> technique:
>
> fun example i = let
>   val cell = ref i
>   val _ = cell : 'a ref
>
>   fun run f = (cell := f (!cell); !cell)
>   val _ = wrap : ('a -> 'a) -> 'a
>
>   in run
> end
>
> This doesn't compile because the 'a in cell's annotation isn't connected
> to the 'a in wrap's annotation: SML is trying to make the annotations more
> polymorphic than I want. Changing "fun example i" to "fun 'a example i"
> fixes this to make both annotations refer to the same 'a.
>
> You can read more about this construct here: http://mlton.org/
> TypeVariableScope
>
> On Wednesday, May 21, 2025, Humza <hum...@gm...> wrote:
>
>> RIT's anti-spam gateway has determined this message may be  spam
>>
>> If you have questions about this message, please contact the RIT Service
>> Center at 585-475-5000, or help.rit.edu
>>
>> The original message as composed by the sender
>> mlt...@li... is below
>> -------------------------
>>
>> Hi all.
>>
>> This isn't strictly a question about MLton specifically, but I hoped to
>> ask the clarification of something that confused me about SML's grammar.
>>
>> I can see in the Definition (and from my testing in PolyML's REPL) that
>> value and function declarations like the following are accepted:
>>
>> $ val 'a myBook = true
>> $ fun ('a, 'b) id x = x
>>
>> The reason is that the grammar in the Definition specifies:
>>
>> dec ::=
>>   val tyvarseq valbind
>>   fun tyvarseq fvalbind
>>
>> I don't understand the point of allowing tyvarseq here though, as these
>> aren't type constraints, so I hoped to ask here. ,(Unlike type variables in
>> a data type, they seem to be unused?)
>>
>> I was wondering as I hoped to create a small interpreter for a pure
>> subset of SML, to help with compile times and maybe to allow scripting in
>> an SML program.
>>
>> https://github.com/hummy123/sml-parser
>>
>> Thanks in advance,
>> Humza
>>
>> PS: Appreciation note here for Phil Clayton who pointed me to the
>> Definition a few months ago on this mailing list, which has been
>> indispensable for understanding the grammar of SML and parsing it
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mlt...@ml....
>>
>
>
> --
> -- Yawar Raza
>
>

-- 
-- Yawar Raza

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] [Suspected Spam] Tyvarseq in function?

['Yawar R. (R. Student)' v. MLton-u. <mlt...@ml...>]

You correctly notice that this feature is seldom used, but it can be useful
for when you want to annotate types for declarations nested in functions.
For example, suppose I wrote this function:

fun example i = let
  val cell = ref i
  fun run f = (cell := f (!cell); !cell)
  in run
end

But my code isn't working, so I need to debug it. I decide to make sure
these variables have the types I expect them to have with the following
technique:

fun example i = let
  val cell = ref i
  val _ = cell : 'a ref

  fun run f = (cell := f (!cell); !cell)
  val _ = wrap : ('a -> 'a) -> 'a

  in run
end

This doesn't compile because the 'a in cell's annotation isn't connected to
the 'a in wrap's annotation: SML is trying to make the annotations more
polymorphic than I want. Changing "fun example i" to "fun 'a example i"
fixes this to make both annotations refer to the same 'a.

You can read more about this construct here:
http://mlton.org/TypeVariableScope

On Wednesday, May 21, 2025, Humza <hum...@gm...> wrote:

> RIT's anti-spam gateway has determined this message may be  spam
>
> If you have questions about this message, please contact the RIT Service
> Center at 585-475-5000, or help.rit.edu
>
> The original message as composed by the sender mlton-user-bounces@lists.
> sourceforge.net is below
> -------------------------
>
> Hi all.
>
> This isn't strictly a question about MLton specifically, but I hoped to
> ask the clarification of something that confused me about SML's grammar.
>
> I can see in the Definition (and from my testing in PolyML's REPL) that
> value and function declarations like the following are accepted:
>
> $ val 'a myBook = true
> $ fun ('a, 'b) id x = x
>
> The reason is that the grammar in the Definition specifies:
>
> dec ::=
>   val tyvarseq valbind
>   fun tyvarseq fvalbind
>
> I don't understand the point of allowing tyvarseq here though, as these
> aren't type constraints, so I hoped to ask here. ,(Unlike type variables in
> a data type, they seem to be unused?)
>
> I was wondering as I hoped to create a small interpreter for a pure subset
> of SML, to help with compile times and maybe to allow scripting in an SML
> program.
>
> https://github.com/hummy123/sml-parser
>
> Thanks in advance,
> Humza
>
> PS: Appreciation note here for Phil Clayton who pointed me to the
> Definition a few months ago on this mailing list, which has been
> indispensable for understanding the grammar of SML and parsing it
>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
>


-- 
-- Yawar Raza

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] Tyvarseq in function?

[Humza <hum...@gm...>]

Hi all.

This isn't strictly a question about MLton specifically, but I hoped to ask
the clarification of something that confused me about SML's grammar.

I can see in the Definition (and from my testing in PolyML's REPL) that
value and function declarations like the following are accepted:

$ val 'a myBook = true
$ fun ('a, 'b) id x = x

The reason is that the grammar in the Definition specifies:

dec ::=
  val tyvarseq valbind
  fun tyvarseq fvalbind

I don't understand the point of allowing tyvarseq here though, as these
aren't type constraints, so I hoped to ask here. ,(Unlike type variables in
a data type, they seem to be unused?)

I was wondering as I hoped to create a small interpreter for a pure subset
of SML, to help with compile times and maybe to allow scripting in an SML
program.

https://github.com/hummy123/sml-parser

Thanks in advance,
Humza

PS: Appreciation note here for Phil Clayton who pointed me to the
Definition a few months ago on this mailing list, which has been
indispensable for understanding the grammar of SML and parsing it

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

[MLton-user] ML Family Workshop 2025: Call for Presentations

[Samuel W. <sh...@ny...>]

              Higher-order, Typed, Inferred, Strict:
                    ML Family Workshop 2025
                  October 16, 2025, Singapore
                 (Co-located with ICFP/SPLASH)

                           Website:
  https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025 <https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025>

                       Submission Link:
                  https://ml2025.hotcrp.com/ <https://ml2025.hotcrp.com/>

                     Submission Deadline:
                      June 19, 2025, AoE


## Call for Presentations

ML (originally, "Meta Language") is a family of programming languages
that includes dialects known as Standard ML, OCaml, and F#, among
others. The development of these languages has inspired a large amount
of computer science research, both practical and theoretical.

The ML 2025 workshop will continue the informal approach followed
since 2010. Presentations are selected by the program committee from
submitted proposals. There are no published proceedings, so
contributions may be submitted for publication elsewhere. The main
criterion is promoting and informing the development of the entire
extended ML family and delivering a lively workshop atmosphere. We
particularly encourage talks about works in progress, presentations of
negative results (things that were expected to but did not quite work
out) and informed positions.

Each presentation should take 20-25 minutes. The exact time will be
decided based on scheduling constraints.

We plan the workshop to an be in-person event with remote
participation (streamed live). We hope that speakers are able to
present in person. If a speaker is unable to attend, they may
instead present remotely.

The 2025 ML Family Workshop is co-located with ICFP/SPLASH 2025
and will take place on **October 16, 2025** in Singapore.

## Scope

We seek presentations on topics including (but not limited to):

  * Language design: abstraction, higher forms of polymorphism,
    concurrency and parallelism, distribution and mobility, staging,
    extensions for semi-structured data, generic programming,
    object systems, etc.

  * Implementation: compilers, interpreters, type checkers, partial
    evaluators, runtime systems, garbage collectors, foreign function
    interfaces, etc.

  * Type systems: inference, effects, modules, contracts, specifications
    and assertions, dynamic typing, error reporting, etc.

  * Applications: case studies, experience reports, pearls, etc.

  * Environments: libraries, tools, editors, debuggers, cross-language
    interoperability, functional data structures, etc.

  * Semantics of ML-family languages: operational and denotational
    semantics, program equivalence, parametricity, mechanization, etc.

We specifically encourage reporting what did not meet expectations or
what, despite all efforts, did not work to satisfaction.

Four kinds of submissions are solicited: Research Presentations,
Experience Reports, Demos, and Informed Positions.

  * Research Presentations: Research presentations should describe new
    ideas, experimental results, or significant advances in ML-related
    projects. We especially encourage presentations that describe work
    in progress, that outline a future research agenda, or that
    encourage lively discussion. These presentations should be
    structured in a way which can be, at least in part, of interest to
    (advanced) users.

  * Experience Reports: Users are invited to submit Experience Reports
    about their use of ML and related languages. These presentations do
    not need to contain original research but they should tell an
    interesting story to researchers or other advanced users, such as an
    innovative or unexpected use of advanced features or a description
    of the challenges they are facing or attempting to solve.

  * Demos: Live demonstrations or short tutorials should show new
    developments, interesting prototypes, or work in progress, in the
    form of tools, libraries, or applications built on or related to ML
    and related languages. (You will need to provide all the hardware
    and software required for your demo; the workshop organizers are
    only able to provide a projector.)

  * Informed Positions: A justified argument for or against a language
    feature. The argument must be substantiated, either theoretically
    (e.g., by a demonstration of (un)soundness, an inference algorithm,
    a complexity analysis), empirically or by substantial experience.
    Personal experience is accepted as justification so long as it is
    extensive and illustrated with concrete examples.


## Submission details

Submissions must be in the PDF format and have a short summary
(abstract) at the beginning. Submissions in the categories of
Experience Reports, Demos, or Informed Positions should indicate so in
the title or subtitle. The point of the submission should be clear
from its two first pages (PC members are not obligated to read any
further.)

Submissions must be uploaded to the workshop submission website before
the submission deadline.

Only the short summary/abstract of accepted submissions will be
published on the conference website. After acceptance, authors will
have the opportunity to attach or link to that summary any relevant
material (such as the updated submission, slides, etc.)

**Submission Website**:
https://ml2025.hotcrp.com/ <https://ml2025.hotcrp.com/>

**Workshop Website**:
https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025 <https://conf.researchr.org/home/icfp-splash-2025/mlsymposium-2025>


## Dates and Deadlines

**Submission Deadline**:
Thursday, June 19 AoE

**Initial Author Notification** (most cases):
Thursday, July 31

**Final Author Notification** (if needed):
Thursday, Aug 7

**Workshop Date**:
Thursday, Oct 16


## Program Committee

  * Sam Westrick (New York University, USA) (Chair)
  * Michael D. Adams (National University of Singapore, Singapore)
  * Jonathan Brachthäuser (University of Tübingen, Germany)
  * Chris Casinghino (Jane Street, USA)
  * Arthur Charguéraud (INRIA, France)
  * Kiran Gopinathan (University of Illinois Urbana-Champaign, USA)
  * Mirai Ikebuchi (Kyoto University, Japan)
  * Keigo Imai (DeNA Co., Ltd., Japan)
  * Anton Lorenzen (University of Edinburgh, UK)
  * Cyrus Omar (University of Michigan, USA)
  * Zoe Paraskevopoulou (National Technical University of Athens, Greece)
  * Filip Sieczkowski (Heriot-Watt University, UK)
  * Yong Kiam Tan (A*STAR Institute for Infocomm Research, Singapore)
  * Yuting Wang (Shanghai Jiao Tong University, China)

## Past Iterations

2024: https://icfp24.sigplan.org/home/mlworkshop-2024 <https://icfp24.sigplan.org/home/mlworkshop-2024>
2023: https://icfp23.sigplan.org/home/mlworkshop-2023 <https://icfp23.sigplan.org/home/mlworkshop-2023>
2022: https://icfp22.sigplan.org/home/mlfamilyworkshop-2022 <https://icfp22.sigplan.org/home/mlfamilyworkshop-2022>
2021: https://icfp21.sigplan.org/home/mlfamilyworkshop-2021 <https://icfp21.sigplan.org/home/mlfamilyworkshop-2021>

More info: https://www.mlworkshop.org/home <https://www.mlworkshop.org/home>

## Coordination with the OCaml Users and Developers Workshop

The OCaml workshop is seen as more practical and is dedicated in
significant part to OCaml community building and the development of
the OCaml system. In contrast, the ML family workshop is not focused
on any language in particular, is more research-oriented, and deals
with general issues of ML-style programming and type systems. There
is some overlap, which we are keen to explore in various ways. The
authors who feel their submission fits both workshops are encouraged
to mention it at submission time or contact the program chairs.


To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] SML multiline strings

[Phil C. <phi...@ve...>]

On 04/03/2025 11:29, Humza wrote:
> I did find an online copy of the definition at the following link for 
> reference: https://smlfamily.github.io/sml97-defn.pdf 
> <https://smlfamily.github.io/sml97-defn.pdf> .

Ah yes, I should have read https://smlfamily.github.io/ more carefully, 
where the PDF is linked.  Good to know, thanks!

Re: [MLton-user] SML multiline strings

[Humza <hum...@gm...>]

Thanks! I appreciate the answer. It looks like Tiger was inspired by SML in
this respect, in that case.

I did find an online copy of the definition at the following link for
reference: https://smlfamily.github.io/sml97-defn.pdf .

On Tue, 4 Mar 2025 at 10:32, Phil Clayton <phi...@ve...> wrote:

> Hi,
>
> This is part of the language so is described in the Definition, formally
> known as "The Definition of Standard ML (Revised)", in Section 2.2.
>
> I don't know of an online copy (ideally this would be available on
> https://smlfamily.github.io/) but there is no need to order the physical
> book unless you want to collect autographs: it is straightforward to clone
> https://github.com/SMLFamily/The-Definition-of-Standard-ML-Revised
> and build the PDF version (given suitable LaTeX packages, which are
> easily added via package management on a Linux distribution).
>
> The text you quote is almost an exact transcript of the Definition.
>
> Phil
>
>
> On 04/03/2025 05:53, Humza wrote:
> > Hi all,
> >
> > I've been reading Andrew Appel's "Modern Compiler in ML" book (hoping to
> > eventually implement a simple interpreter running on top of MLton).
> >
> > The Tiger language implemented over the course of the book has an
> > unusual "escape sequence" with regards to its strings, which I have only
> > seen in Standard ML before.
> >
> > Quoting from the book:
> > "
> > \f ___ f\
> > This sequence is ignored, where f___f stands for a sequence of one or
> > more formatting characters (a subset of the non-printable characters
> > including at least space, tab, newline, formfeed). This allows one to
> > write long strings on more than one line, by writing \ at the end of one
> > line and at the start of the next.
> > "
> >
> > SML has a similar feature enabling multiline strings, of course. I
> > wanted to refresh my memory about the exact semantics of SML's \f___f\
> > feature, which I think differs from Tiger (Tiger seems to allow only
> > formatting characters in there while I think SML allows any character,
> > maybe?) but my searches didn't bring up any information.
> >
> > I was hoping someone here might be able to point me to a reference or
> > provide a description of how SML's feature works.
> >
> > I did look at the Basis library page for the STRING signature
> > (https://smlfamily.github.io/Basis/string.html
> > <https://smlfamily.github.io/Basis/string.html>) as I thought I might
> > find the information there, but I didn't manage to find it so would
> > appreciate any help.
> >
> > To unsubscribe from this group and stop receiving emails from it, send
> > an email to mlt...@ml...
> > <mailto:mlt...@ml...>.
> >
> >
> > _______________________________________________
> > MLton-user mailing list
> > MLt...@li...; mlt...@ml...
> > https://lists.sourceforge.net/lists/listinfo/mlton-user
>
>
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

Re: [MLton-user] SML multiline strings

[Phil C. <phi...@ve...>]

Hi,

This is part of the language so is described in the Definition, formally 
known as "The Definition of Standard ML (Revised)", in Section 2.2.

I don't know of an online copy (ideally this would be available on 
https://smlfamily.github.io/) but there is no need to order the physical 
book unless you want to collect autographs: it is straightforward to clone
https://github.com/SMLFamily/The-Definition-of-Standard-ML-Revised
and build the PDF version (given suitable LaTeX packages, which are 
easily added via package management on a Linux distribution).

The text you quote is almost an exact transcript of the Definition.

Phil


On 04/03/2025 05:53, Humza wrote:
> Hi all,
> 
> I've been reading Andrew Appel's "Modern Compiler in ML" book (hoping to 
> eventually implement a simple interpreter running on top of MLton).
> 
> The Tiger language implemented over the course of the book has an 
> unusual "escape sequence" with regards to its strings, which I have only 
> seen in Standard ML before.
> 
> Quoting from the book:
> "
> \f ___ f\
> This sequence is ignored, where f___f stands for a sequence of one or 
> more formatting characters (a subset of the non-printable characters 
> including at least space, tab, newline, formfeed). This allows one to 
> write long strings on more than one line, by writing \ at the end of one 
> line and at the start of the next.
> "
> 
> SML has a similar feature enabling multiline strings, of course. I 
> wanted to refresh my memory about the exact semantics of SML's \f___f\ 
> feature, which I think differs from Tiger (Tiger seems to allow only 
> formatting characters in there while I think SML allows any character, 
> maybe?) but my searches didn't bring up any information.
> 
> I was hoping someone here might be able to point me to a reference or 
> provide a description of how SML's feature works.
> 
> I did look at the Basis library page for the STRING signature 
> (https://smlfamily.github.io/Basis/string.html 
> <https://smlfamily.github.io/Basis/string.html>) as I thought I might 
> find the information there, but I didn't manage to find it so would 
> appreciate any help.
> 
> To unsubscribe from this group and stop receiving emails from it, send 
> an email to mlt...@ml... 
> <mailto:mlt...@ml...>.
> 
> 
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user

[MLton-user] SML multiline strings

[Humza <hum...@gm...>]

Hi all,

I've been reading Andrew Appel's "Modern Compiler in ML" book (hoping to
eventually implement a simple interpreter running on top of MLton).

The Tiger language implemented over the course of the book has an unusual
"escape sequence" with regards to its strings, which I have only seen in
Standard ML before.

Quoting from the book:
"
\f ___ f\
This sequence is ignored, where f___f stands for a sequence of one or more
formatting characters (a subset of the non-printable characters including
at least space, tab, newline, formfeed). This allows one to write long
strings on more than one line, by writing \ at the end of one line and at
the start of the next.
"

SML has a similar feature enabling multiline strings, of course. I wanted
to refresh my memory about the exact semantics of SML's \f___f\ feature,
which I think differs from Tiger (Tiger seems to allow only formatting
characters in there while I think SML allows any character, maybe?) but my
searches didn't bring up any information.

I was hoping someone here might be able to point me to a reference or
provide a description of how SML's feature works.

I did look at the Basis library page for the STRING signature (
https://smlfamily.github.io/Basis/string.html) as I thought I might find
the information there, but I didn't manage to find it so would appreciate
any help.

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....

Re: [MLton-user] Boolean FFI type size

[Humza <hum...@gm...>]

Thanks for the answer. The pieces I've encountered on the history of MLton
(like the mailing list discussion from 19 years ago) has been a bit of a
gold mine to learn from. I'm glad it's all preserved.

On Wed, 15 Jan 2025 at 02:45, Matthew Fluet <mat...@gm...> wrote:

> I'm not entirely sure.
>
> On possibility is that development of MLton began in 1997 (see
> http://mlton.org/History), which predated the C `bool` type.  The first
> codegen was the C codegen, where we expected C to do much of the "heavy
> lifting" of computation.  Pre C99, I think that it was common for the
> result of C comparisons to have the `int` type, so that was the natural
> choice for SML's `bool`, so as to avoid extra conversions.
>
>
> On Mon, Jan 13, 2025 at 2:27 PM Humza <hum...@gm...> wrote:
>
>> Hi there,
>>
>> I was reviewing the different FFI types at the following link and was a
>> little surprised to see that it states the FFI type for bools is an int32_t
>> in C.
>> http://www.mlton.org/guide/20241230/ForeignFunctionInterfaceTypes
>>
>> It was surprising to me because a boolean logically only needs a single
>> bit (although there might be metadata I don't know like how some compilers
>> provide 63-bit integers instead of 64, using a bit for garbage collection).
>>
>> I do see some smaller types provided, like char which is represented as a
>> uint8_t in C.
>>
>> So I was just curious about the reason for the decision to use an int32_t
>> for booleans, which isn't what I would expect, if anyone still remembers.
>>
>> I did read (and learn quite a bit from) this mailing list thread from 19
>> years ago about bools and the MLton FFI, but most of the discussion there
>> was about whether an SML bool should have the same representation as a C
>> bool, which is a different topic from what the size of a bool should be.
>> http://www.mlton.org/pipermail/mlton-devel/2006-June/028927.html
>>
>> To unsubscribe from this group and stop receiving emails from it, send an
>> email to mlt...@ml....
>> _______________________________________________
>> MLton-user mailing list
>> MLt...@li...; mlt...@ml...
>> https://lists.sourceforge.net/lists/listinfo/mlton-user
>>
> To unsubscribe from this group and stop receiving emails from it, send an
> email to mlt...@ml....
> _______________________________________________
> MLton-user mailing list
> MLt...@li...; mlt...@ml...
> https://lists.sourceforge.net/lists/listinfo/mlton-user
>

To unsubscribe from this group and stop receiving emails from it, send an email to mlt...@ml....