Programming With Datasorts

Hello, I've been experimenting with datasorts as a means to compose / configure programs in ATS2. To demonstrate, I put together a small example of a static S-expression eDSL here . The general approach is to a) encode a small language as a

Re: Read IO and Write IO

This seems very versatile and flexible. I like the idea of I/O tracking being opt-in and very specific. I often find that only one type of effect is of interest, and tracking the rest can get in the way. I recently used a similar technique to track drawing to the screen (using an absview,

Re: Issue with call-by-reference and template dispatch

types as template parameters. > > On Wed, Jun 26, 2019 at 12:16 PM M88 > > wrote: > >> >> This is how I get around the issue: >> >> >> typedef Foo = @{ >>f = () -> void >> } >> >> abstflt foo = Foo >> extern cast

Re: Issue with call-by-reference and template dispatch

with at-views and template dispatch, specifically. On Wednesday, June 26, 2019 at 8:13:41 AM UTC-4, Richard wrote: > > On Tuesday, June 25, 2019 at 9:47:50 AM UTC-4, M88 wrote: > > I noticed this a while ago in ATS2 (just verified in Temptory). > > > > > > > >

Issue with call-by-reference and template dispatch

I noticed this a while ago in ATS2 (just verified in Temptory). It seems that call-by-reference functions in record definitions cause issues with template dispatch. The following will fail to compile ( no match for `do_something` ) -- changing the signature of `foo.f` to `(int) -> void` will

Re: libatscc: packaging

AM UTC+3, M88 wrote: >> >> >> Somewhat related: maybe it would be good to have some character-sequence >> that represents a module accessor in the host language? >> >> > Yes, it makes sense to support some form of qualified identifiers in the > sou

Re: libatscc: packaging

Somewhat related: maybe it would be good to have some character-sequence that represents a module accessor in the host language? For example, something like "mac#Math**sqrt" could be translated to "Math.sqrt" by atscc2[x], depending on what the module system uses for namespaces. >From an

Re: Call-by-value assignment

castfn vt_take( !VT(x) >> VT0(x) ) -> VT(x) prfn vt_put( !VT0(x) >> VT(x), VT(x) ): void . var env = vt_take(x) val _ = some_template(env) prval () = vt_put( x, env ) Version b seems pretty good for this case. > On Sun, Feb 24, 20

Call-by-value assignment

Hello, I have a viewtype and I am using it in a call-by-value function. I want to temporarily assign it to a variable for use in a template that uses call-by-reference. Is there a way to assert that the variable has not been consumed? Right now I am doing this, which typechecks and compiles

Re: Linking with abstract types

> #include xyz.hats > > in > > [Some code that needs the content of xyz.hats] > > end > > The generated code often contains a lot of templates and usually cannot > be typechecked separately; it needs to be put into a context to pass > typechecking. > > On Fri, Oc

Re: Linking with abstract types

r 17, 2018 at 12:53:53 AM UTC-4, M88 wrote: > Hello, > > This doesn't seem to affect compilation, but I often get this warning when > attempting to link .dats files into mylibies_link.hats: > "warning(3): the static constant [] is not abstract at this point" > > This

Linking with abstract types

Hello, This doesn't seem to affect compilation, but I often get this warning when attempting to link .dats files into mylibies_link.hats: "warning(3): the static constant [] is not abstract at this point" This happens when I want to link a .dats file that implements abstract types. //

Re: ATS3: ATS/Xanadu

; > 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 s

Re: ATS3: ATS/Xanadu

I'd agree in general that documentation, errors and usability improvements are very important in ATS3 -- ATS2 is a feature-rich language as it is, but exceedingly difficult to navigate. I will go on to propose a feature, but the former aspect should get more of the focus. Recently I was

Re: Initializing statically-allocated arrays within templates

Scoped includes and constants areawesome. On Tuesday, September 25, 2018 at 3:28:05 PM UTC-4, M88 wrote: > > Hello, > > I was wondering if it's possible to use a template to define the size of a > statically allocated array in a template. > > An exampl

Re: Initializing statically-allocated arrays within templates

I get an error during C compilation, ATSERRORarrdim_unknown, when I try to use a template function. Thanks Julian -- that's a decent solution. On Tuesday, September 25, 2018 at 3:28:05 PM UTC-4, M88 wrote: > > Hello, > > I was wondering if it's possible to use a template to def

Initializing statically-allocated arrays within templates

Hello, I was wondering if it's possible to use a template to define the size of a statically allocated array in a template. An example (that won't compile) is: extern fun {a:t@ype} example () : void extern val {} example$bufsz : [n:pos] size_t n implement {a} example () = let

Re: ATS3: ATS/Xanadu

I suppose there has been a fair bit of talk about syntax already. I had been thinking a whitespace-significant label-block structure (a-la Nim) might suit the language well, and some recent code sample inspired me to demonstrate. Original: datasort tlist = tnil | tcons of (t0ype, tlist)

Re: Defining constraints -- datasorts and stacst

eCA1 {cb:catB}() : [sa:sortA | isCA1(sa) ] typeA(sa) What tripped me up at first is that the return value of each constructor should specify the constraint "isCA1" if I use this approach, whereas the former let me invoke the proofs globally. On Saturday, April 7, 2018 at 12:25:05 AM UT

Defining constraints -- datasorts and stacst

I was looking into the rock-paper-scissors example (here and here ) and I found it very useful for learning how to define predicates

staload, paths, and infix operators

I have two questions... The first is that path resolution seems to have changed from ATS2 0.3.7 and 0.3.9. I used to be able to write 'staload "sats/foo.sats"' in "dats/foo.dats" and running patscc from the project root would find the file. Now it seems I need to write 'staload

Re: ATS3: ATS/Xanadu

> I thought about this issue as well. One idea I had is to > use overloading aggressively. > A thought I had recently -- I'm almost wondering if certain proofs (eg, linear proofs) could behave more like value constraints. That is, they could be invoked optionally, and would only be checked

ATS3: ATS/Xanadu

Not sure if it's feasible or theoretically sound, but it would be nice to see a less stark divide between datatypes and dataviewtypes in ATS3. It would be great to be able to declare a data structure once and use either linear or gc'd versions. Maybe this could extend to other types that have

Re: ATS3: ATS/Xanadu

I have accrued a bit of a wishlist while working with ATS. Maybe some of it is useful or feasible. Things I would keep the same: - I think dependent type / proof syntax is well done, and it feels a bit more natural than Idris. I'd keep this the same - The '~' to free an unfolded

Re: Controlling the allocation / deallocation rates when using datatypes

Thank you -- the rewrite was informative, and the most efficient so far. I overlooked the fact that a datatype is a pointer to an unboxed tuple. It should make it possible to statically allocate them, if I wanted to. It looks like there are several options here. -- You received this message

Re: Controlling the allocation / deallocation rates when using datatypes

> It is unclear what you translated. Could you show? I was just saying that I didn't expect the compiler to treat stream-fusion the same way in ATS as it does in Haskell. To your point, I expected different algorithms. I found the tutorial useful -- implementing a custom allocation routine

Controlling the allocation / deallocation rates when using datatypes

Hello, I just started dabbling with ATS, so bear with me. I really like using datatypes / datavtypes as a control structure, but the allocation / deallocation rates seem fairly high when there are a fair number created in sequence. I suppose I've gotten used to the stream-fusion motif in