Re: What is the best way to turn a file into a lazy linear stream?

2021-12-07 Thread d4v3y_5c0n3s
No worries, I understand sometimes people get busy. :)
  I eventually decided against using linear streams to process files in my 
code, at least in the way I was using it.  My code would result in being 
relatively slow, due to only retrieving one character from the file at a 
time instead of getting a large chunk of text (which is faster because we 
are making fewer requests to the system.)  Also, I found myself essentially 
needing to either rewrite regular expressions to using character streams, 
or to turn my streams into strings, which struck me as being too roundabout 
to be practical.  The only positive of using streams in the way that I 
originally planned to was that the memory footprint would be reduced, a 
tradeoff I didn't see the value of in my case.
  A better way to use streams in my case is to have a stream of strings 
rather than a stream of characters.  This way, my code will run fast while 
still benefiting from laziness by only reading the file when needed.

On Wednesday, December 1, 2021 at 12:56:16 AM UTC-5 gmhwxi wrote:

> Sorry, I didn't get a chance to read this post until now.
>
> If you use a (linear) FILEptr to create a linear stream (of chars), then 
> the FILEptr is "buried" inside
> the stream and thus it can no longer be accessed.
>
> >>My solution was to essentially combine the view for the file pointer and 
> the stream into a single type, and thus requiring both to be freed at once.
>
> To me, this seems to be the only type-safe solution (as the alternative 
> you mentioned above must make use of some unsafe features).
>
> --Hongwei
>
>
> On Sunday, October 17, 2021 at 9:14:04 AM UTC-4 d4v3y_5c0n3s wrote:
>
>> Okay, so looking back I should have provided more details in the last 
>> post, as it does not explain the issues I was encountering etc.  I posted 
>> it right before I went to bed, and that's why I rushed it.
>> Anyways, I wanted to explain how I solved my problem so that others 
>> could learn.  Basically, I was using ATS' built-in libc binding to open and 
>> read a file.  The pointer for the file was a linear type, I wasn't using 
>> the prelude's non-linear file type.  What my code did is read characters to 
>> a 'stream_vt' with the 'getc' function until it reached the end of the 
>> file.  I also planned to have other functions that would discard parts of 
>> the stream I didn't need so that I could turn the values I needed into 
>> other values (AKA, typical file-parsing stuff.)  The problem came when I 
>> needed to close the file.  Despite the use of linear types, freeing the 
>> file pointer would not prevent the stream from being access due to its 
>> laziness.  My solution was to essentially combine the view for the file 
>> pointer and the stream into a single type, and thus requiring both to be 
>> freed at once.
>> Moral of the story?  Linear types are amazing, one of the reasons I 
>> love ATS, but they are *not* a silver bullet.  They too are limited by 
>> what can be statically inferred by the compiler, and effects such as lazy 
>> values cannot be predicted by the compiler.  I hope someone was able to 
>> learn something from my post, and let me know if you have any questions.
>>
>> On Monday, October 4, 2021 at 9:17:38 PM UTC-4 d4v3y_5c0n3s wrote:
>>
>>>
>>> What the title says.  Basically, I want to use a solution that:
>>>  - does not require GC
>>>  - uses the type system to prevent the user from freeing the file before 
>>> they are done with the lazy evaluation
>>>  - is not too inconvenient for the user to use
>>> Let me know if you need an example of what I'm talking about.
>>>
>>

-- 
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 view this discussion on the web visit 
https://groups.google.com/d/msgid/ats-lang-users/882b580c-0d25-4d5b-a2b2-f0a71567feabn%40googlegroups.com.


Re: Help with Templates, cannot find missing implementation somewhere...

2021-12-07 Thread d4v3y_5c0n3s
Thanks, I tried something similar with the "dict" type, but completely 
overlooked the "bucket" type.  I'll test this to see if it resolves the 
issue.

On Wednesday, December 1, 2021 at 12:28:15 AM UTC-5 gmhwxi wrote:

> After taking a quick look at dict.sats, I spotted the following line:
>
> absvtype bucket(a:vt@ype)
>
> which should be change to the following one:
>
> absvtype bucket(a:vt@ype) = ptr // ptr takes the compiler the size of 
> bucket
>
> The simple reason is that the compiler needs to know the size of an 
> abstract type in order to compile it to a type in C.
>
>
> On Wednesday, December 1, 2021 at 12:16:34 AM UTC-5 gmhwxi wrote:
>
>> I don't quite understand.
>> Templates in ATS2 are supposed to be working with abstract types.
>>
>> If I could try precisely what you did on your machine, then I may be able 
>> to suggest something.
>>
>>
>>
>> On Tue, Nov 30, 2021 at 8:27 PM d4v3y_5c0n3s  wrote:
>>
>>> Update 2:
>>> After investigating the prelude, I've determined that templates in ATS2 
>>> just conflict with abstract types in some instances.  For this reason, it 
>>> seems that in many parts of the prelude avoided the use of the "assume" 
>>> keyword with template-heavy code.
>>>
>>> On Tuesday, November 30, 2021 at 7:08:48 PM UTC-5 d4v3y_5c0n3s wrote:
>>>
 Update:
 I was able to get the code I provided above running by staloading the 
 dict.dats file from the dict_test.dats file using " staload _ = 
 "./dict.dats" ".  Now, my only problem is that if I make the "dict" & 
 bucket types abstract, the templates stop working.

 On Tuesday, November 30, 2021 at 1:39:39 PM UTC-5 d4v3y_5c0n3s wrote:

> You are right, including " share/atspre_staload.hats" causes the code 
> to compile.  However, I'm still having issues.  You see, the code I 
> provided I had taken from a static (.sats) and dynamic (.dats) file in 
> order to make it more presentable when asking for help.  Your fix only 
> fixes the issue in the single-file version, and when including the 
> external 
> static file it doesn't work.  Do you know what might be going wrong?  
> I'll 
> provide the (simplified) contents of each of these files below.
>
> *dict.sats*:
> #include "share/atspre_staload.hats"
>
>
> datavtype BUCKET (a:vt@ype) =
> | bucket_empty of ()
> | bucket_filled of (Strptr1, a, BUCKET(a))
>
> vtypedef bucket(a:vt@ype) = BUCKET(a)
>
> fn{a:vt@ype} bucket_item$delete ( x: a ): void
>
> fun{a:vt@ype} bucket_delete_recursive ( b: bucket(a) ) : void
>
> sortdef dsz = {s:int | s > 0}
>
> vtypedef dict(a:vt@ype, n:int) =
> @{
> size=int n,
> buckets=arrayptr(bucket(a), n)
> }
>
> fn{a:vt@ype} dict_new {s:dsz} ( int s ) : dict(a, s)
> fn{a:t@ype} dict_delete {s:dsz} ( d: dict(a, s) ) : void
> fn{a:vt@ype} dict_delete_lin {s:dsz} ( d: dict(a, s) ) : void
>
>
> *dict.dats*:
> #include "share/atspre_staload.hats"
>
> staload "./dict.sats"
>
> local
> in
>
>
> implement{a} dict_new {s} ( size ) = let
> val size_st = size_of_int(size)
> val bucket_arr = arrayptr_make_uninitized(size_st)
> implmnt array_initize$init (i, x) = x := bucket_empty()
> val () = arrayptr_initize(bucket_arr, size_st)
> in
> @{size=size, buckets=bucket_arr}:dict(a, s)
> end
>
> implmnt{a} dict_delete ( d ) = let
>   implmnt(a2:t@ype) bucket_item$delete ( x ) = ()
> in
>   dict_delete_lin(d)
> end
>
> implmnt{a} bucket_delete_recursive ( b ) =
> case+ b of
> | ~bucket_empty() => ()
> | ~bucket_filled(str, x, next_bucket) => let
> val () = strptr_free(str)
> val () = bucket_item$delete(x)
> in
> bucket_delete_recursive(next_bucket)
> end
>
> implmnt{a} dict_delete_lin ( d ) = let
>   implmnt array_uninitize$clear (i, x) = 
> bucket_delete_recursive(x)
> in
>   arrayptr_freelin(d.buckets, size_of_int(d.size))
> end
> end
>
> *dict_test.dats*, where main is:
> #include "share/atspre_staload.hats"
>
> staload "./dict.sats"
>
>
> implmnt main0 () = let
>   var d = dict_new(13)
> in
>   dict_delete(d)
> end
>
> *My output*:
> $ patscc --gline -DATS_MEMALLOC_LIBC dict_test.dats
>
> In file included from dict_test_dats.c:15:
> /home/tmj90/Goldelish-Engine/source/data/dict_test.dats: In function 
> ‘mainats_0_void’:
> /home/tmj90/Goldelish-Engine/source/data/dict_test.dats:58:21: error: 
> ‘PMVtmpltcstmat’ undeclared (first use in this function)
>58 |   var d = dict_new(13)
>   | ^~~   
>
> /usr/local/lib/ats2-postiats-0.4.2/ccomp/runtime/pats_ccomp_instrset.h:276:37:
>  
> note: in definition of macro ‘ATSINSmove’