Conditional based Macros

[antfu]

Describe your issue/suggestions

There are conditional inclusions in C++ looks like this

#if defined(CREDIT)
    credit();
#elif defined(DEBIT)
    debit();
#else
    printerror();
#endif

I think this is extremely helpful for Wenyan when it comes to stdlib. For example, we can have (I keep the same syntax in C++ for better demonstration, we may discuss the syntax later)

今有一術。名之曰「左移」。欲行是術。必先得二數。曰「甲」。曰「乙」。乃行是術曰。
#if TARGET_LANG = py
	施「(lambda x: lambda y : x<<y)」於「甲」。於「乙」。名之曰「丙」。乃得「丙」。
#elif TARGET_LANG = js
	施「(x=>y=>(x<<y))」於「甲」。於「乙」。名之曰「丙」。乃得「丙」。
#else
	吾有一言。曰「「NOT SUPPORTED」」。書之。
#endif
是謂「左移」之術也。

This makes the stdlib more maintainable and also opens more possibilities for different use cases.

Checklist

Before you create this issue, Please make sure ALL the following items are checked

• If this is a feature request, it's NOT listed Here
• If this is a bug report, it's NOT listed Here

[LingDong-]

@antfu, thanks for bringing this up! I think this is a very useful feature to have.

I was thinking about the same thing when adding the platform-specific stdlibs. However I'm wondering if it would be better to use magical comments instead.

In C/C++, the preprocessors simply throw out the parts marked unreachable by #if, so the most valuable thing is that, even if the unreachable code is full of compile-time problems, it compiles. In our stdlib, the same behaviour is very desirable because e.g. we don't want python to error out when it reads JavaScript code. However, for users, it might be too advanced of a usage to put it into the official syntax, and it could be confusing to have two different ifs. In C/C++, things are clear because the #... have their own line and the hash symbol is quite unique; for wenyan-lang, everything is Chinese characters and these preprocessor directives might blend in "too well". Moreover, I think most of them time, regular if-else statements would do the job, like in most languages that does not have #if macros. If the user is particularly hacky, he/she could use the same magical comments used by stdlib.

As a side note, when implementing features, it is easy to think about what other languages have and just copy all that. For macros, one would often relate to C/C++ #define, #if, #ifdef etc. However I think it would be better to rethink each piece and what it does to the language. Though both preprocessed, syntactic sugars with #defines are somewhat a different concept than #ifs. They're more lisp-like macros that extend the syntax. I'm not saying that #if are out, but instead I'm saying it is not like "it goes without saying that we should have #if because we had #define", and that we should carefully consider each piece.

Thanks for reading :) What do you think? Also would love to hear more opinions from everyone.

[lymslive]

I also feel the conditional macros concept is too complex for current version of wenyan-lang.

[antfu]

@LingDong- Very thoughtful. Thanks for the detailed reply. I would say I totally agree with you.

But after a few thoughts, I came up with this for discussion.

As for now, we can do language-specific stdlib by using the current approach or magic comments. I agree this might be too complex for most of the users. But in the future, we might have 3-rd party libraries. And they may want to support multiple target languages as well. This remains me back in the time I was developing python packages, developers are trying their best to write code that works for both python2 and 3. But the difference from it is that Wenyan is still a compiler not a line by line interpreter as Python or Javascript at this time. That means py and js can totally ignore the unreached blocks without any errors. But the basic if in Wenyan might not be capable for this.

I am not trying to say we should have #if etc. I feel the same we should treat tradeoff and decisions carefully. Just open this case for discussion. 😄

[antfu]

Could we access some environment information in script or macros?

I am happy to wrapping some js/pip modules to wyg to make wenyan having more applications and also inspire developers for wenyan packages. (We didn't expose the language-specify features from stdlib to packages, maybe we could extract the logic and unify them)

This is some useful information comes up to my mind

name	value	desc
TargetLang	'js', 'py', 'rb'	Target language that compiles to
Env	'process', 'browser', etc	To identify if can access fs or some other logic

In macro ways, are just like the proposal introduced in this issue.

Or maybe we could expose them as global variables for the script, something like window object in the browser and process object in Node.js. We could name it 天地 or something.

What do you think?

[antfu]

This is a wyg package I imaged as an example

文言檢索 (wyfs)

File system access for wenyan-lang

This package supports Javascript and Python runtime. Ruby support is coming soon.

Install

wyg i wyfs

balabalaabalaba....

Usage

吾嘗觀「「檢索」」之書。方悟「讀」「寫」之義。

施「讀」於「「山海經」」。名之曰「文」。
施「寫」於「「山海經盜刻」」於「文」。

---

Source code

今有一術。名之曰「讀」。欲行是術。必先得一數。曰「名」。乃行是術曰。

	若「天地之境」等於「沙箱」者。
		嗚呼。「「檢索無能也」」之禍。
	也。
    
    
	若「天地之言」等於「犀」者。
		施「x=>require('fs').readFileSync(x, 'utf-8')」於「名」。名之曰「文」。
		乃得「文」。
	也。
	若「天地之言」等於「蟒」者。
		施「lambda x: open(x, 'r').readlines()」於「名」。名之曰「文」。
		乃得「文」。
	也。
    
	嗚呼。「「不解所言也」」之禍。
    
是謂「讀」之術也。

[LingDong-]

@antfu

Could we access some environment information in script or macros? Or maybe we could expose them as global variables for the script

I think it is a great idea. I've been thinking about this too. The transpiler can stick a global var to the front of compiled script. But what would be really cool is to use a polygot to detect platform. Next level of browser sniffing :P

https://en.wikipedia.org/wiki/Polyglot_(computing)

This is a wyg package I imaged as an example

I think this should go into standard lib. IO / Read write is very fundamental :)
But I'm still thinking how to name it. It's basically 讀寫, but I wonder if there is a more classical name for it.

Some related thoughts about wrapping native APIs:

I'm also thinking about a DOM wrapper, (which includes setTimeout etc.). It will map to python's tkinter. Another is mapping 畫譜 to python (either PIL or tkinter) and adding SVG backend.

[antfu]

But what would be really cool is to use a polygot to detect platform

Holy s***. What the heck is that 😂. I am not very familiar with linux bash/perl or so kinda stuff but this looks very cool! Not sure how could we do that.

I think this should go into standard lib. IO / Read write is very fundamental :)

Yes. My point here is to demonstrate that platform-specific code should also be available for modules and not only for stdlib. These can open more possibilities for packages to explorer. (wrappers for axios, fetch and even express or vue so kind of things)

I'm also thinking about a DOM wrapper, (which includes setTimeout etc.). It will map to python's tkinter. Another is mapping 畫譜 to python (either PIL or tkinter) and adding SVG backend.

Sounds like a lot of efforts 😂 (but very promising). Looking forward to that!

[LingDong-]

@antfu Polygot is just some code that compiles in two or more languages.
For example, I just had an idea:

eval("3//2");

This is valid in BOTH python and Javascript! But! In python it returns 1. In Javascript it returns 3. ;)

[LingDong-]

Ha!
Just found a way to tell between Ruby and JavaScript

[].to_s==[][0]

So:

若「eval("3//2")==1」者
	吾有一言。曰「「蟒也」」書之。
或若「[].to_s==[][0]」者
	吾有一言。曰「「犀也」」書之。
若非
	吾有一言。曰「「鑽也」」書之。
也。

Is all we need

I'm so good at this XD. But I know there are some real code golfers out there who would think this is just everyday stuff :P

[antfu]

@LingDong- No word to say... You are indeed talented on this 👍

[LingDong-]

@antfu, Just realized I was wrong, eval("3//2")==1 would not compile in ruby as // is for regex

But don't worry, I found a polygot that would compile in all three languages:

' '.split == ' '.split()

In python & JS, this would evaluate to false, because a function is not equal to an array. For Ruby however, simply saying the name of a function calls it (!?)

But wait, there is more! Adding a parenthesis to the first split can cause JS to disagree with Python/Ruby:

' '.split() == ' '.split()

Python/Ruby thinks ' '.split() is []. JS thinks it should be [' ']. What's more, for JS, [' '] != [' '], while for Python/Ruby, []==[] (!?)

So

若「' '.split == ' '.split()」者
	吾有一言。曰「「鑽也」」書之。
或若「' '.split() == ' '.split()」者
	吾有一言。曰「「蟒也」」書之。
若非
	吾有一言。曰「「犀也」」書之。
也。

I call this: The split between three languages summarized in the split function.

But more seriously, I think an environment global variable is a better idea, otherwise I'll need to come up with more polygots as we support more backends (not to say I don't enjoy making them) XD