Thanks Julian,
I could see this as a possible implementation of the original templates.
Ultimately, I would see the parser parameterized over different input /
output types, and stack allocated variables could be different sizes,
depending on what is being parsed. I think templates would be necessary
for that (or at least, convenient).
My original suggestion has caveats (eg, binary size could explode, *maybe*).
While I'm not sure macros are the right answer ( I chose them because it's
syntactically valid ATS2 ), I could see the ability to compose template
instantiations on a high level being rather useful.
More broadly, I've been toying with the observation that, in many cases,
implicit closure arguments are actually constants. Perhaps there are ways
to exploit this for high-level programming. I'm getting ahead of myself
(it's probably frivolous just to save on a few cloref allocations), but my
idea went something like this:
In this contrived example, let's say we wanted to curry an envless cfun,
returning an envless cfun. We could do this in ATS2 like so:
extern
fun {a,b,c:t@ype} curry$fopr(a,b) : c
extern
fun {a:t@ype} curry$arg() : a
extern
fun {a,b,c:t@ype} curry() : b -> c
implement {a,b,c}
curry () =
let
fun f1 (b) : c =
curry$fopr<a,b,c>(curry$arg<a>(),b)
in f1
end
This would be difficult to actually use, in practice.
What if it could be transformed into something like this, where cst() is a
type specifier, requiring the value to be a top-level declaration or a
constant literal:
extern
fun {a,b,c:t@ype} curry( cst( (a,b) -> c ) ) : cst( cst(a) -> b -> c )
implement {a,b,c}
curry ( f ) =
lam( x ) => lam (y) => f(x,y) // no error about this not being envless,
because f and x are cst()
This is more limited than closures, but still useful. For instance, all
envless lambda literals would be cst. Then it'd be possible to do things
like:
val f = curry<int,int,int>( lam ( x: int, y : int ) : int => x + y )
val y = f(5)(2) // returns 7
I would think that any function that accepted or returned a cst(...) value
would need to be a template for it to work.
I suppose implementing this idea may not be worth it, but I thought the
ability to instantiate templates in macros might still be nice to have.
On Friday, October 5, 2018 at 3:17:55 AM UTC-4, Julian Fondren wrote:
>
> 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/0ae93684-52e6-4b23-afe5-650fd5c938cf%40googlegroups.com.
