On Thursday, October 4, 2018 at 8:47:31 PM UTC-5, M88 wrote:
>
> Recently I was attempting to write parser combinators without
> heap-allocated closures (or any sort of allocation). It was a bit
> difficult because stack-allocated closures are of varying size and must be
> affixed to a `var`. I did find a successful approach using templates.
>
With a linear object that includes a stack (which can avoid allocation if
you implement that with a fixed array) you can have code like
let
val p = new_parser(argv[1])
fun parseHello(p: !parser_vt): void = parse(p, "hello")
fun parseQuery(p: !parser_vt): void = parse(p, "what day of the month is
it?")
fun parseAcceptable(p: !parser_vt): void = (
push(p); parseHello(p);
if failed(p) then (
pop(p); parseQuery(p);
) else commit(p)
)
in
parseAcceptable(p);
if isdone(p) then
println!("Hi, it's the first of the month.");
free_parser(p);
end
In general, think of linear objects when you're looking at some pretty
do-notation, from how purely functional languages with uniqueness types do
I/O.
The local-function-:<cloref1> transformation (turning apparently
closed-over variables into implicit parameters) will try to consume your
linear variables, so you can't easily do without those p arguments. That
same transformation could be used though if you kept your state in mutable
local variables, which might not be so bad if you #include the :<cloref1>
functions into your let-declaration from a .hats file with stuff like:
fun parse(str: string):<cloref1> void = (
if !reading then (
if is_prefix(str, input, !input$at) then
!input$at := !input$at + strlen(str)
else
!reading := false
)
)
It went a little something like:
>
> implement parse_token$tok<>() = "this"
> val THIS = parse_token<>
> implement parse_token$tok<>() = "that"
> val THAT = parse_token<>
>
> implement parse_or$p1<string,string>(str,tup) = THIS(str,tup)
> implement parse_or$p2<string,string>(str,tup) = THAT(str,tup)
> val THIS_or_THAT = parse_or<string,string>
>
> It would be nice if something like this were possible:
>
> macdef token(str) = let
> implement parse_token$tok<>() = ,(str)
> in parse_token<>
> end
>
> macdef ||(p1,p2) = let
> implement parse_or$p1<string,string>(str,tup) = ,(p1)(str,tup)
> implement parse_or$p2<string,string>(str,tup) = ,(p2)(str,tup)
> in parse_or<string,string>
> end
>
> val this_or_that = token("this") || token("that") // returns a constant
> cfun.
>
> This probably only makes sense in the domain of embedded programming
> (otherwise closures could be used).
>
>
>
> On Friday, February 9, 2018 at 1:15:22 PM UTC-5, gmhwxi wrote:
>>
>> For the moment, I just want to open a thread for ATS3.
>>
>> I decided to pick ATS/Xanadu for the full project name. I like the name
>> Xanadu
>> because it is poetic and brings a feel of exoticness.
>>
>> ATS3 is supposed to be compiled to ATS2. At least at the beginning. I
>> will try to
>> write more about what I have in mind regarding ATS3.
>>
>> I know that a lot of people have been complaining about the syntax of
>> ATS2. So
>> we can start the effort of designing some "nice" syntax for ATS3. Please
>> feel free
>> to post here if you would like share your opinions and ideas.
>>
>> I will be happy to take the lead but we definitely need to have some form
>> of community
>> effort on this project given its size and scope.
>>
>> Cheers!
>>
>> --Hongwei
>>
>> PS: I felt rushed every time up to now when implementing ATS. This time I
>> am hoping
>> to have the luxury of thinking about implementation a bit before actually
>> doing it :)
>>
>>
--
You received this message because you are subscribed to the Google Groups
"ats-lang-users" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to ats-lang-users+unsubscr...@googlegroups.com.
To post to this group, send email to ats-lang-users@googlegroups.com.
Visit this group at https://groups.google.com/group/ats-lang-users.
To view this discussion on the web visit
https://groups.google.com/d/msgid/ats-lang-users/cd8f9825-c7bd-462e-9120-87a99f867a23%40googlegroups.com.
