Standard library design discussion

[qdbplang]

This issue will be used for discussion for the standard library. Questions include:

• How big should it be?
• How much do we care about performance vs ease of use
• How should it be packaged/where should it be located
• Semantics for including it, especially when there are user libraries with identical names
• Should string and list literals be part of the standard library

[qdbplang]

Perhaps use https://github.com/vurtun/nuklear for graphics?

[qdbplang]

abort should be a library function not a language primitive

[dghosef]

Concurrency with unbuffered csp

[dghosef]

Introduce a parallel map w/ the same type as List Map. Maybe also parallel reduce? Maybe the parallel reduce should also check to see that the function has a IsAssociative field.

[dghosef]

If we are doing CSP, gotta figure out syntax for channels. Maybe at the beginning of the program, declare all the channel names like: [channelname1, channelname2, ...] rest-of-program-here

[dghosef]

Need file I/O

[dghosef]

As far as standard library files are located, we could just have them such that they are located in ~/.qdbpstdlib or something. And when the user imports something, it first checks locally. If we don't find it, then we look at qdbpstdlib.

[dghosef]

Need some sort of list class with

• Append
• Sort
• Map
• Fold right
• Fold left

[dghosef]

The stdlib should be the only place where external call is allowed

[dghosef]

Perhaps the stdlib should just be a bunch of predefined variables sorta like Haskell's prelude. And keep it minimal. Then we don't need two import directories, etc

[dghosef]

A way to run bash commands

[dghosef]

If we made linked lists instead have head be the whole front end of the list and tail be the last element, we could do:

(node! 1) + 2. + 3. + 4. + 5.

I like this. It would, however, depart from standard functional programming practice of having head be the first element and tail being the remainder of the list.

We could keep that syntax but reverse the list. Or we could pick a new syntax that is probably pretty clunky. Not quite sure yet

[dghosef]

zipper style functional datastrucures

[dghosef]

Finger tree for everything