What are the options to extending ATS2 in a disciplined way?
I have two extensions in mind:
support for relational algebra operations
support for Smalltalk-style OOP (as was done in ATS/Proto)
For (2), I plan to follow the approach of Objective-C (Objective-ATS, if
you prefer). A new type is introduced for objects, id, and for message
selectors, SEL. Message selectors are formed at run-time, and a built-in
"dispatch" function takes an object reference, a message selector, and some
unspecified arguments and does the message send (the idea is to use the
Objective-C runtime for this).
For (1), I don’t really know, but since relation headers are essentially
finite mappings from field labels to types, then it makes stuff quite
complicated for type-checking. For (1), the idea is to basically
re-implement Dataphor (dataphor.org) in ATS2 (we only need a new type for
forming relation types, and then some built-in operations for dealing with
terms of relation types, e.g. join, restrict, etc.).
What are the options to implement the two proposed extensions? I think that
in contrast to ATS-parse-emit, here the source language needs to be
extended (to be fair, target output may have to be tweaked a bit as well).
(As you can see, I have an abundance of ideas and no time to finish any of
them, sigh.)
What part of nix would that be out of curiosity, and how is it going?
On Mon, Dec 8, 2014 at 4:03 PM, Shea Levy <sh...@shealevy.commailto:sh...@shealevy.com> wrote:
Oh hey, I didn’t know there were more of us I actually started using ATS in order to replace a key component of nix.
Lots of promise, but not necessarily the easiest to use. Actually, it is not too bad, but takes some getting used to, sort of like gentoo but slightly more so.
Lots of promise, but not necessarily the easiest to use. Actually, it is
not too bad, but takes some getting used to, sort of like gentoo but
slightly more so.On Mon, Dec 8, 2014 at 12:19 PM, Raoul Duke rao...@gmail.com wrote:
Just an aside, I now know of at least 4 people in the ATS community
using or
working on NixOS. That seems like a strong endorsement.
For (1), my suggestion would be that you first pick an interesting problem
involving relational algebra and then write some pseudo code to implement
a solution to this problem. It is essential to get a clear idea about
what you
really want to implement before attempting any actual implementation.
Thanks for the advice.
I have a working application (implemented in D4, a Tutorial D dialect)
that I want to re-write in ATS (in the future).
For (2), I would say it makes a great sense to first do some serious
co-programming with
ATS and Objective-C. Here is such an example:
I feel it is essential for you to work out some examples before your
attempting any implementation.
Please feel free to post to this forum your questions, comments, learning
experience, etc.
I’ve been doing some work towards this. Currently, I’m busy packaging
GNUstep (an Objective-C environment for NixOS), a Linux distribution that
simplifies the management of separate software environments (and I’ll make
a similar environment for ATS2 as well, so that new language users can
quickly get started). After that is done, I’ll try to come up with a
motivating example.
Just an aside, I now know of at least 4 people in the ATS community using
or working on NixOS. That seems like a strong endorsement.> On Wednesday, December 3, 2014 10:45:09 PM UTC-5, Artyom Shalkhakov wrote:
Hi all,
What are the options to extending ATS2 in a disciplined way?
I have two extensions in mind:
support for relational algebra operations
support for Smalltalk-style OOP (as was done in ATS/Proto)
For (2), I plan to follow the approach of Objective-C (Objective-ATS, if
you prefer). A new type is introduced for objects, id, and for message
selectors, SEL. Message selectors are formed at run-time, and a built-in
“dispatch” function takes an object reference, a message selector, and some
unspecified arguments and does the message send (the idea is to use the
Objective-C runtime for this).
For (1), I don’t really know, but since relation headers are essentially
finite mappings from field labels to types, then it makes stuff quite
complicated for type-checking. For (1), the idea is to basically
re-implement Dataphor (dataphor.org) in ATS2 (we only need a new type
for forming relation types, and then some built-in operations for dealing
with terms of relation types, e.g. join, restrict, etc.).
What are the options to implement the two proposed extensions? I think
that in contrast to ATS-parse-emit, here the source language needs to be
extended (to be fair, target output may have to be tweaked a bit as well).
(As you can see, I have an abundance of ideas and no time to finish any
of them, sigh.)
For (1), my suggestion would be that you first pick an interesting problem
involving relational algebra and then write some pseudo code to implement
a solution to this problem. It is essential to get a clear idea about what
you
really want to implement before attempting any actual implementation.
Thanks for the advice.
I have a working application (implemented in D4, a Tutorial D dialect) that
I want to re-write in ATS (in the future).
For (2), I would say it makes a great sense to first do some serious
co-programming with
ATS and Objective-C. Here is such an example:
I feel it is essential for you to work out some examples before your
attempting any implementation.
Please feel free to post to this forum your questions, comments, learning
experience, etc.
I’ve been doing some work towards this. Currently, I’m busy packaging
GNUstep (an Objective-C environment for NixOS), a Linux distribution that
simplifies the management of separate software environments (and I’ll make
a similar environment for ATS2 as well, so that new language users can
quickly get started). After that is done, I’ll try to come up with a
motivating example.> On Wednesday, December 3, 2014 10:45:09 PM UTC-5, Artyom Shalkhakov wrote:
Hi all,
What are the options to extending ATS2 in a disciplined way?
I have two extensions in mind:
support for relational algebra operations
support for Smalltalk-style OOP (as was done in ATS/Proto)
For (2), I plan to follow the approach of Objective-C (Objective-ATS, if
you prefer). A new type is introduced for objects, id, and for message
selectors, SEL. Message selectors are formed at run-time, and a built-in
“dispatch” function takes an object reference, a message selector, and some
unspecified arguments and does the message send (the idea is to use the
Objective-C runtime for this).
For (1), I don’t really know, but since relation headers are essentially
finite mappings from field labels to types, then it makes stuff quite
complicated for type-checking. For (1), the idea is to basically
re-implement Dataphor (dataphor.org) in ATS2 (we only need a new type
for forming relation types, and then some built-in operations for dealing
with terms of relation types, e.g. join, restrict, etc.).
What are the options to implement the two proposed extensions? I think
that in contrast to ATS-parse-emit, here the source language needs to be
extended (to be fair, target output may have to be tweaked a bit as well).
(As you can see, I have an abundance of ideas and no time to finish any
of them, sigh.)
I’m a highly recent user. Aside from downloading the VM image a few months
ago, I’ve only been using it for a few days. I think Chris Double also uses
it.On Mon, Dec 8, 2014 at 4:03 PM, Shea Levy sh...@shealevy.com wrote:
Oh hey, I didn’t know there were more of us I actually started using
ATS in order to replace a key component of nix.
Lots of promise, but not necessarily the easiest to use. Actually, it is
not too bad, but takes some getting used to, sort of like gentoo but
slightly more so.
On Mon, Dec 8, 2014 at 12:19 PM, Raoul Duke rao...@gmail.com wrote:
Just an aside, I now know of at least 4 people in the ATS community
using or
working on NixOS. That seems like a strong endorsement.
Lots of promise, but not necessarily the easiest to use. Actually, it is
not too bad, but takes some getting used to, sort of like gentoo but
slightly more so.
On Mon, Dec 8, 2014 at 12:19 PM, Raoul Duke rao...@gmail.com wrote:
Just an aside, I now know of at least 4 people in the ATS community
using or
working on NixOS. That seems like a strong endorsement.
I have noticed that doing a nix rebuild (forget the command exactly), takes
quite some memory. It does sound like a big project.On Fri, Dec 12, 2014 at 1:12 PM, Shea Levy sh...@shealevy.com wrote:
Essentially it will replace libnixstore https://github.com/NixOS/nix/tree/master/src/libstore: The
“lower-level” half of nix that handles the store invariants, coordinates
builds and substitutions, etc. Currently it has a lot of deficiencies,
including being single-threaded, loading huge paths entirely into memory,
being written in C++, etc. (See nix-store replacement · Issue #16 · zalora/deployix · GitHub for
a grab bag of improvements I’d like to make). Currently it’s still in the
“when will I find some time to really start the damn thing” stage,
unfortunately
Lots of promise, but not necessarily the easiest to use. Actually, it is
not too bad, but takes some getting used to, sort of like gentoo but
slightly more so.
On Mon, Dec 8, 2014 at 12:19 PM, Raoul Duke rao...@gmail.com wrote:
Just an aside, I now know of at least 4 people in the ATS community
using or
working on NixOS. That seems like a strong endorsement.
for (1) if it is going to be something “relational” then pretty please
do something actually relational and algebraic rather than
something that is about hellacious sql. http://lambda-the-ultimate.org/node/5089
For (1), my suggestion would be that you first pick an interesting problem
involving relational algebra and then write some pseudo code to implement
a solution to this problem. It is essential to get a clear idea about what
you
really want to implement before attempting any actual implementation.
For (2), I would say it makes a great sense to first do some serious
co-programming with
ATS and Objective-C. Here is such an example:
I feel it is essential for you to work out some examples before your
attempting any implementation.
Please feel free to post to this forum your questions, comments, learning
experience, etc.On Wednesday, December 3, 2014 10:45:09 PM UTC-5, Artyom Shalkhakov wrote:
Hi all,
What are the options to extending ATS2 in a disciplined way?
I have two extensions in mind:
support for relational algebra operations
support for Smalltalk-style OOP (as was done in ATS/Proto)
For (2), I plan to follow the approach of Objective-C (Objective-ATS, if
you prefer). A new type is introduced for objects, id, and for message
selectors, SEL. Message selectors are formed at run-time, and a built-in
“dispatch” function takes an object reference, a message selector, and some
unspecified arguments and does the message send (the idea is to use the
Objective-C runtime for this).
For (1), I don’t really know, but since relation headers are essentially
finite mappings from field labels to types, then it makes stuff quite
complicated for type-checking. For (1), the idea is to basically
re-implement Dataphor (dataphor.org) in ATS2 (we only need a new type for
forming relation types, and then some built-in operations for dealing with
terms of relation types, e.g. join, restrict, etc.).
What are the options to implement the two proposed extensions? I think
that in contrast to ATS-parse-emit, here the source language needs to be
extended (to be fair, target output may have to be tweaked a bit as well).
(As you can see, I have an abundance of ideas and no time to finish any of
them, sigh.)
Oh hey, I didn’t know there were more of us I actually started using ATS in order to replace a key component of nix.> On Dec 8, 2014, at 5:33 PM, Brandon Barker brandon...@gmail.com wrote:
Probably both ways
Lots of promise, but not necessarily the easiest to use. Actually, it is not too bad, but takes some getting used to, sort of like gentoo but slightly more so.
I actually started using ATS in order to replace a key component of nix.
