Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

[ANNOUNCEMENT] Import stmt added; Recruiting Std lib implementers! #290

Open
LingDong- opened this issue Dec 21, 2019 · 9 comments
Open
Labels
announcement Announcement from maintainers help wanted Extra attention is needed stdlib Issues related to standard library

Comments

@LingDong-
Copy link
Member

LingDong- commented Dec 21, 2019

Hello everybody! I just implemented the import statement, which allows standard library to be added for the language. You think you can write wenyan? Help build the standard library for wenyan! See below for details:

1. Import statement (experimental)

Below is the new import syntax. Thanks everyone for the inspiration!

吾嘗觀「「算經」」之書。方悟「正弦」「餘弦」「圓周率」之義。
from math import sin, cos, pi

New usage of 今有. 今有 is now used for exported/public variables, while 吾有 is private/scoped. Think of 今有 like module.exports.x=. Think of 吾有 like var x=

Example:

易經.wy(a.k.a. Random)

吾有一數。曰四十二。名之曰「運數」。

今有一術。名之曰「運」。欲行是術。必先得一數。曰「甲」。乃行是術曰。
	注曰「「運者。隨機種子也」」
	昔之「運數」者。今「甲」是矣。
是謂「運」之術也。

今有一術。名之曰「占」。是術曰。
	注曰「「線性同餘方法所得隨機數也」」
	有數四十二億九千四百九十六萬七千二百九十六。名之曰「模」。
	有數二千二百六十九萬五千四百七十七。名之曰「倍」。
	有數一。名之曰「增」。
	乘「倍」以「運數」。加其以「增」。除其以「模」。所餘幾何。昔之「運數」者。今其是矣。
	除「運數」以「模」。名之曰「卦」。
	乃得「卦」。
是謂「占」之術也。

some_example.wy(where you import random)

吾嘗觀「「易經」」之書。方悟「占」之義。
施「占」。書之。

Notice that in 易經.wy the random seed (運數) is not exported. while its setter (運) is exported, but not imported by some_example.wy. Only the generator is exported and imported, and can be used directly.

JS implementation details

(Python, Ruby are not implemented yet)

JS Implementation uses var MODULE_NAME = new function(){ ... } trick to wrap imported modules. 今有 maps to this. So they can be accessed using MOUDLE_NAME.identifier. The import statements specifies which identifiers are actually required, and those that are are extracted from its scope using var identifier = MODULE_NAME.identifier. Therefore, some_example.wy compiles to this:

var 易經 = new function() {
    var 運數 = 42;
    this.運 = () => 0;
    this.運 = function(甲) {
        /*"運者。隨機種子也"*/
        運數 = 甲;
    };
    this.占 = () => 0;
    this.占 = function() {
        /*"線性同餘方法所得隨機數也"*/
        var 模 = 4294967296;
        var 倍 = 22695477;
        var 增 = 1;
        var _ans49 = 倍 * 運數;
        var _ans50 = _ans49 + 增;
        var _ans51 = _ans50 % 模;
        運數 = _ans51;
        var _ans52 = 運數 / 模;
        var 卦 = _ans52;
        return 卦
    };
};
var 占 = 易經.占;
var _ans48 = 占();
console.log(_ans48);

You can check out a more sophisticated example on the online IDE. In the IDE, you can import an example from another example, or the a module from standard lib.

parser.compiler has a new option called reader, which is a function you can provide to tell compiler how to read a module. The default for node.js is to look in current directory plus one directory down. For browser-side you might give it something fancy like AJAX calls or something.

When you build the CLI compiler, the source of the standard libraries are included, so you can still use it without having the ./lib folder.

Please let me know if found any issue or have any suggestion!

2. Standard Library implementers needed!

You think you can write wenyan? Please join us!

Currently in the ./lib folder there are a couple of "stubs" such as 算經(math) 位經(bit ops) 易經(random).

They contain many functions to be implemented in wenyan. e.g. The sin() function currently contains this HACK:

今有一術。名之曰「正弦」。欲行是術。必先得一數。曰「甲」。乃行是術曰。
	施「Math.sin」於「甲」。名之曰「乙」。乃得「乙」。
是謂「正弦」之術也。

What we need to do is to replace Math.sin hack to a proper implementation (Taylor series?).

Our goal is to implement the most commonly used library functions. If you are familiar with one or two of them, please submit a pull request!

3. Thanks!!

As you might have noticed, much of the syntax and many ideas are inspired by / borrowed from numerous posts and feature requests. Therefore, a thank you to everyone!

@statementreply
Copy link
Contributor

statementreply commented Dec 21, 2019

I can help with 算經 (and fixing hanzi2num, perhaps also somehow implement #231 (positional notation and scientific notation), to make it possible to write any numeric constant as intended in wenyan).

That would be non-trivial amount of work though, as doing floating point math right is hard. (Even the current implementation of 取頂, 取底 and 取整 fails for some input values)

@LingDong-
Copy link
Member Author

Hi @statementreply That would be very much appreciated! Take your time, we all know it's hard ;)
Could you please let me know which cases fails for 取頂, 取底 and 取整, so that I can fix them?
Thank you very much!

@statementreply
Copy link
Contributor

@LingDong- 取頂 looks correct. For 取底 and 取整:

施「取底」於負二又七分。書之。
施「取整」於負二又七分。書之。
施「取整」於五千兆。書之。

Btw, 取整 sounds more like trunc than round to me.

@LingDong-
Copy link
Member Author

LingDong- commented Dec 21, 2019

@statementreply Oops. Didn't think carefully about negative numbers. Should be an easy fix.
However, the 五千兆 problem is due to floating point precision.
Current algorithm is

x=>(x<(floor(x)+0.5))?(floor(x)):(floor(x)+1)

But apparently
5000000000000000+0.5>5000000000000000 returns false

Therefore a more robust algorithm is needed, at least for very large numbers.
Thank you very much for pointing out these issues.

@liaocm
Copy link
Contributor

liaocm commented Dec 22, 2019

I can help with list operation ("列經"?). Having array slicing and collection operations would be nice. Also, having some built in data structures would be awesome.

As I mentioned in #326 , I have general concern on how much we introduce Javascript dependencies in Std implementations. Would love to have more input on this issue from folks.

@LingDong-
Copy link
Member Author

Hi @liaocm, thanks so much for your interest!

For ndarrays, I'm planning to port (rewrite) one of my own libraries, 洛書 https://github.com/LingDong-/Loshu.js to wenyan-lang. It is a JS linear algebra library (complete with matrix decompositions and other advanced stuff).

Since it is purely written in plain JavaScript. It should be easy to rewrite in wenyan. If you would like to help, please feel free to take a look at that repo and start translating some of the functions. Thank you very much!

Regarding #326, I think there is a big misunderstanding. The goal IS to implement everything in WENYAN, not in JavaScript. The current code in these standard library files are temporary. They're there just so that an implementer know what the function is supposed to do, and if another function they're implementing depends on this function, they can use it assuming it works, facilitating testing and modularity.

Thanks!

@liaocm
Copy link
Contributor

liaocm commented Dec 22, 2019

@LingDong- - thanks for the clarification. It makes sense that we shouldn't have dependencies on a specific trans-piled language. For bitwise ops I think it makes more sense to support those as built in operators though - simulating them with math tricks seems to be awful inefficient.

@statementreply
Copy link
Contributor

For bitwise ops I think it makes more sense to support those as built in operators though - simulating them with math tricks seems to be awful inefficient.

Alternatively, we could define compiler intrinsic functions or platform API functions for things like bit-wise operations (low-level) and getting current date & time (impossible to implement). When the code says 吾嘗觀「「曆書」」之書。方悟「報時」之義。, it imports lib/platform/javascript/曆書.js when compiled to JavaScript, lib/platform/python/曆書.py when compiled to Python.

@LingDong-
Copy link
Member Author

@statementreply sounds neat! I've been pondering how to integrate platform specific stuff like time/GUI/bits, and yours sounds like a good solution. Thanks!

@liaocm Please feel free to add 列經 as you see fit. Sorry I was still thinking about the ndarrays mentioned in another thread yesterday, and now it comes to my realization that you're talking about Arrays, like slice, find, join, pop etc. So yeah that would be very much appreciated. Thanks!

@LingDong- LingDong- added announcement Announcement from maintainers stdlib Issues related to standard library labels Dec 24, 2019
This was referenced Dec 28, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
announcement Announcement from maintainers help wanted Extra attention is needed stdlib Issues related to standard library
Projects
None yet
Development

No branches or pull requests

3 participants