proj-oot-old-150618-ootModuleNotes1

http://skilpat.tumblr.com/post/9411500320/a-modular-package-language-for-haskell

--

"

nadaviv 1 day ago

ES6's generators and the `yield` keyword plays very nicely with callback-based code, doesn't require any changes to the underlying libraries and gives you a much nicer syntax to work with.

See https://github.com/visionmedia/co

reply

JoshGlazebrook? 1 day ago

I've been looking at another library like the one you linked. Essentially the "yield" keyword can be compared to "await" in C#.

https://github.com/bjouhier/galaxy

reply "

"

CyruzDraxs? 1 day ago

It was easier until we discovered even cleaner ways, and most of the Javascript community began to adopt them. But node chose to stick to the "old" ways. (Not really old, but not as shiny and new as the alternatives)

I feel like promises don't need to be part of core though. It's easy enough to wrap the standard library in userland and just have other things depend on the wrappers.

reply "

--

"

e12e 1 day ago

This seems to parallel some of the work VPRI is doing, eg from:

http://www.vpri.org/pdf/tr2010004_steps10.pdf

STEPS Toward Expressive Programming Systems, 2010 Progress Report Submitted to the National Science Foundation (NSF) October 2010 Alan Kay et al

"If computing is important—for daily life, learning, business, national defense, jobs, and more — then qualitatively advancing computing is extremely important. For example, many software systems today are made from millions to hundreds of millions of lines of program code that is too large, complex and fragile to be improved, fixed, or integrated. (One hundred million lines of code at 50 lines per page is 5000 books of 400 pages each! This is beyond human scale.) What if this could be made literally 1000 times smaller — or more? And made more powerful, clear, simple, and robust? This would bring one of the most important technologies of our time from a state that is almost out of human reach—and dangerously close to being out of control—back into human scale.

(...)

Previous STEPS Results

The first three years were devoted to making much smaller, simpler, and more readable versions of many of the prime parts of personal computing, including: graphics and sound, viewing/windowing, UIs, text, composition, cells, TCP/IP, etc. These have turned out well (they are chronicled in previous NSF reports and in our papers and memos). For example, essentially all of standard personal computing graphics can be created from scratch in the Nile language in a little more than 300 lines of code. Nile itself can be made in a little over 100 lines of code in the OMeta metalanguage, and optimized to run acceptably in real‐time (also in OMeta) in another 700 lines. OMeta can be made in itself and optimized in about 100 lines of code."

More:

http://www.vpri.org/html/writings.php "

---

http://existentialtype.wordpress.com/2011/04/16/modules-matter-most/

"Modules are about name control and only secondarily, if at all, about types." -- http://existentialtype.wordpress.com/2011/04/16/modules-matter-most/#comment-733

---

(copied from ootTypesNotes2:)

Implementation dependencies are like dependencies in a package management system. Implementations can depend on types (all that is required is any implementation of the desired type), or 'concretely' on other implementations (we demand a specific implementation of a type, because we are going to break into its internals). For example, the Rational implementation can depend on the type Int (meaning that it makes use of Ints internally), or it could be eg a FFI binary containing optimized x86 code which calls subroutines from another binary package containing an implementation of Ints. Outside of FFI, a concrete implentation dependency is one which breaks encapsulation by accessing private variables in another implementation.

does Oot support concrete implementation dependencies aside from FFI at all? If so, does it force you to specify a specific version of the concrete dependency, to prevent the upstream author of the dependency from worrying about breaking code by changing Private variables? Perhaps it only supports concrete dependencies within the same module?

note that, as with the class Ord which can be generated from == and <, or == and >, or <= and <, etc, which implementations are 'primitive' can vary. The module system should do this dependency resolution.

---

i think everything in a module can access the privates of everything else in the same module, and otherwise privates cannot be accessed (except by debuggers and profilers, in debug mode)

---

perhaps all multi-file modules must be have version numbers? This is to prevent someone from extending someone else's module by adding another file to it, and then complaining when the 'parent' code changes private stuff and breaks the extension code. This way the parent code can increment their version number and then the 'child' code simply won't compile unless they keep around the source to the old module code and use that. This implies that a project might have multiple internal implementations of the same module. In this case, Oot should transparently translate values from one version to a later version by serializing and deserializing them; yes, this is slow (perhaps a facility could be provided for implementations to specify fast ways to do this between particular versions?).

---

note that, although the distinction between oot types (hasell typeclasses/java interfaces) and implementations is like C .h files and C .c files, that (a) we can mix both kinds of declarations in the same source code file, and (b) you only have to write the implementation; Oot will autogenerate a type for an implementation. So eg if you write a String implementation that is internally a linked list, and then someone else writes a String implementation that is a packed array of bytes (like Haskell Bytestrings), neither of you need to have a place in your source code that explicitly defines the String interface (type); this will be inferred (provided it matches). You CAN explicitly declare the type, though, and the compiler API has an option to generate the source code for the inferred type declaration.

You might have to explicitly declare types that have pattern matching views, eg if you want a List to be defined with two constructors, EmptyList? or cons(list, item), then you might have to declare that. But i'm not sure. When i speak of inferred type declarations, i'm thinking of things like https://docs.python.org/2/library/threading.html#semaphore-objects which are have a single constructor, have no 'algebraic'ish data type stuff (multiple constructors but also AADTs), and are just basically a list of supported methods with their signatures.

---