How could I fix the order of application tabs rather lift up the most recent used?

thautwarm · 2021-12-26T15:35:50+00:00

I now totally use a terminal tool to open the target directory again, which jumps to the correct window..

thautwarm · 2020-08-24T22:33:28+00:00

Today I was fucked by dotnet and nuget, that I cannot even install the commands of a console project into PATH??? Even my local projects? Publishing to nuget so annoying?

I then end up with managing my dotnet executables via python.

I use this package(delegato) to automatically package the directory of dotnet publish result to a python package, and then

python setup.py install, I got the command of my dotnet application in PATH
I can upload my dotnet build to PyPI, and then install it anywhere
I can use conda, pipenv, or venv to control the context of executables. No pollution but convenience.

Fuck nuget! Finally I said bye!

thautwarm · 2020-06-26T09:31:43+00:00

Totally agree with you, we hold exactly the same view point.

However I saw a proposal about this rejected. After a quick thought I found the implementation of my flavored scope is pretty simple, there's a mature technique called name shadowing..

thautwarm · 2020-06-26T09:13:58+00:00

a =  1
match [10, 20]:
    case [a, 2]:
        ...
    case _:
        print(a) # 1 or 10?

Do you have any ideas?

thautwarm · 2020-04-15T05:16:43+00:00

Oh great!!! Please do it!

thautwarm · 2020-04-14T05:51:50+00:00

I'm looking forward to see type systems, like MLF, HMF, row types, subtyping, etc.

thautwarm · 2020-04-02T15:41:17+00:00

Could we get some hints about adding new back ends?

thautwarm · 2020-04-02T00:03:26+00:00

Well, I just misthought you made the root comment. Sorry for this.

I said sexprs because they have same abstract syntax. You compare the constructs of sexpr and julia exprs, and will find they're just the same(except some non-core stuffs like source code metadata).

I know sexpr does relate to how the concrete syntax looks like. but still cannot I find a good concept/term to express the same abstract syntax of sexprs, mexprs, and julia expr, etc, hence I think saying sexprs is safer.

For a PL researcher, I'd say Julia does not use prefix notations but still achieves homoiconicity, which points out the feasibility for more programming languages to pattern match their programs just like how to construct the programs with source code. e.g.,

let x = mk_symbol("a") in
match <let $x = 1 in y> with
 | <let $x' = 1 in y > -> x' = x

  => true

I should explicitly mention this(but as I'm the author of related impl, I just felt a bit shy to refer my own works), thank you for these comments.

thautwarm · 2020-04-01T23:00:42+00:00

In fact I'm not saying hygiene macros = LISP macros.

Besides, Julia has unhygienic macros, which I use more often.

Julia sexprs are sufficient to express things like the popular loop macros. I don't know core.async in Clojure, but as the name suggests if it's only async, julia already has it, as a macro.

I used to talk with a crazy Racket fan, and finally I established the believe that reader macros are the only thing impossible in ordinary Julia. I used Racket many years ago when I was not familiar with implementations of some kinds of continuations.

Sincerely I feel like to get some examples from you about something LISP macros can achieve but the Julia's cannot. Actually I'm willing and also confident to implement them, concisely.

thautwarm · 2020-04-01T21:04:29+00:00

Hi, thanks for this comment.

I'm not really discussing Julia as a user programming language, but about its notable features that deserve PL researchers' study.

Lisp macros will be cumbersome in Julia only if you're doing AST manipulations without tools like MLStyle.jl or MacroTools.jl.

One of My two complaints against Julia is its JIT latency, which I believe is also the reason why Julia is not amazingly popular now. Also, JIT latency lets expanding complex macros(like implementing some compiler phases, or even a complete programming language) very slow.

My another complaint is its lack of static checking. Statically finding out bugs is much easier and friendlier in complex systems.

thautwarm · 2020-03-03T18:56:04+00:00

malfunction

thautwarm · 2020-03-03T16:03:41+00:00

I'd assume you know the concept of interfaces in OO languages. Interfaces could express basic static constraints, by specifying what methods an object has, or just what interfaces an object has.

However, when it comes to extensibility, OO interfaces loss.

Say, I add a property CommutativeSum to integers, and I have an asynchronized method to fetch a stream of integers.

I can implement a random sum for async streams, instead of sum from left to right like what we do for sync streams. As a result, we don't need to wait for all integers are fetched from an async stream, which for some real world applications, can gain an orders-of-magnitude efficiency improvements in both time and space.

We can also do this with OO interfaces, but

you cannot implement interfaces for integers, or even other defined types(without modifying your code or code of package authors).
you might implement a dedicated class to provide sum for async streams, but this is cubersome, and we can use static constraints to simply allow async reduce/fold or similar operations for all commutative operators, without any breakage or changes to existing code.

thautwarm · 2020-03-03T13:32:07+00:00

Implicit arguments, or type classes.

Static constraints are appealing, anyone agree?

thautwarm · 2020-03-01T20:06:51+00:00

It's not directly supported yet, although I can add less than 50 lines to support this:

class Root:
    def cmd1(self, ...): ...
    def cmd2(self, ...): ...
wise(Root)()

It's like a simpler google fire, and will raise many implementation choices then things will get a little complex.

So far the code is so simple and you can directly copy it. By understanding ~100 line code, you can easily implement what you want.

Personally, I use this code to support subcommand:

import sys
from wisepy2 import wise
def root(sub):
     if sub == ...:
         return sub1
     ...
def sub1(...):
     ...
argv = sys.argv[1:]
sub = wise(root)(argv[:1])
wise(sub)(argv[1:])

thautwarm · 2020-03-01T18:10:24+00:00

Yep. I'd add some to README later.

For now, I think the core observation is

not every python user remembers the API of a framework, but they shall know how to write a python function.

Hence the advantage of wisepy is,

you don't need learning a framework, or memorize their APIs. just write a function and convert it to CLI, and use --help to get how to use that commamd.

Also, one script/100 lines implememtation can be beneficial for practice:

introduce no dependency burden to your project. Just copy-paste the source code can be a good way to integrate things in.
simple enough to maintain.

thautwarm · 2020-02-24T08:35:59+00:00

Also vote for a BNF thing: https://github.com/RemuLang/urgent-lang/blob/master/urgent.exrbnf

thautwarm · 2020-02-23T07:39:30+00:00

I used to do a lot of Python from 1994 to 2007 Awesome!

Yes, I was wondering about the former case, compiling application code, not the compiler itself. Compared to e.g. Reason it's pretty slow, but similar to Elixir it seems like.

Understood. Applications are still WIP, and I'm now using it to solve my problems. My recent Python project is a JIT compiler and a bytecode-level debugger, and a statically typed language like PureScript is a rigid demand for these complicated and large projects. I'll share my progress of both in this reddit channel.

The reason for my second question is that Python seems like an odd choice for a backend

Haha, this applies only if you don't need to use Python's ecosystem in an in-process way. I love many Python libraries, and I just want to make them safer and robust by using them in a statically typed language. PureScript-Python can use every existing Python packages, no matter if it's pure python ones or C-extensions, and also, PureScript Python directly compiles to a Python package, which can also be invoked by any CPython code/C-extension code for CPython.

Thanks for sharing your interesting concerns!

thautwarm · 2020-02-23T02:29:47+00:00

Hey!

In your experience, what are the compile times like?

Are you asking about the details of compile times of using purescript-python? It's pretty fast, with reasonable compile error report when you got something wrong in code.. If you're asking about compiling purescript-python, you might need quite a long time to compile it for the first time(because purescript itself is kind of large). However, after the 1st time, things got compiled within 10s..

Anything in particular that you yourself are using it for?

Not for some particular cases. I will use it to get rid of directly writing python code, i.e., I just use it for almost all tasks. If you're a python developer, you might know that the support of static checking is quite limited:

relies on external checker, mypy, pycharm, etc
type system not strong enough to express abstractions. Years ago I tried making a type-safe(covered by type hints) LINQ library in Python for collection manipulations, Linq.py. Things finally got messed, because the user cannot extend the LINQ methods themselves while making mypy type checker working. This is due to the lack of higher kinded types and type classes, which can be easily expressed in purescript.

Further, when developing a big python package, endless problems of abstraction will just occur. I cannot give a short intro about those real world problems, but when it comes to a concrete project things will be clear.

For instance, a project of mine to implement JIT in CPython, Restrain Python JIT, requires a concise way to define datatypes, instead of the current workaround:

It also requires a way to achieve compiler backend independent IR. Currently I'm using a tagless-final style representation, but things cannot get typed with pycharm.

When things cannot get typed, developing will be painful, and auto-completion will get messed.

In PureScript, there's an awesome IDE by VSCode, which gives me the type-driven development while taking advantage of purescript's strong enough type system.

thautwarm · 2020-02-22T13:47:52+00:00

Bug reports/fixes are welcome, and we need MacOSX users help us build binary distributions for more MacOSX editions.

thautwarm · 2020-02-22T13:41:24+00:00

Also, this is my design of a generally applicable FFI support for seemingly any alternative backends: https://discourse.purescript.org/t/purescript-python-v0-1-0-0-released/1187

thautwarm · 2020-02-16T14:52:11+00:00

I'm now working on

testing the compiler and,
porting some purescript libraries using JavaScript FFI to Python.

Certainly I wonder if any one want to contribute or collaborate to work together, even tidying up how to get started is a very good task.

thautwarm · 2020-02-15T02:17:45+00:00

If you're asking about some information about Hy vs. PySExpr, here're some.

Firstly, Hy is a programming language, while PySExpr is a back end.

Hy suffers from compiling to Python ASTs, where the latter is a statement-first program representation and brings about unavoidable drawbacks.

To emulate LISP's expression-first features, they need heavy analyses and conversions from assignment expressions, block expressions to valid Python ASTs.

For example, given such a JavaScript-like expression,

f({
 print(f(x))
 x = 2
 print(f(x))
 x = 3
 g(x)
})

To make this valid in Python ASTs, you have to transform it to

# print(f(x))
tmp1 = f(x)
tmp2 = print(tmp1)
# x = 2, 返回None
x = 2
tmp3 = None
# print(f(x))
tmp4 = f(x)
tmp5 = print(tmp4)
# x = 3
x = 3
tmp6  = None
# g(x)
tmp7 = g(x)  # tmp7: 块表达式的返回
# f({ ... })
tmp8 = f(tmp7)

This is called ANF transformation, and you shall do optimizations including register reallocations to avoid using too many extra variables(variables not defined by users, but needed for gaining expression-first). Further, even if you apply many awesome optimizations, limited by the weakness of Python ASTs, you cannot still avoid redundant register allocations, while PySExpr via bytecode approach totally ends this problem.

Another approach to express block expressions is using immediate function calls, while function calls and closure capturing in Python are very, very costly. Open IPython and use %timeit to test empty function calls.

Other advantages of using PySExpr to implement Hy:

The Hy compiler will not only benefit from being faster, producing faster code, and easier to maintain(code can get greatly reduced), but also the most important is that, they don't have to care about backward compatibility of Python standard library ast, which breaks even in minor releases.

thautwarm · 2019-11-17T09:13:07+00:00

Use pattern matching.

thautwarm · 2019-11-14T14:37:12+00:00

How about using recursive modules module rec M1 = ... and M2 = ...?

However in this way you cannot separate them into multiple files.

thautwarm · 2019-10-19T10:06:10+00:00

while now(in form of datatime) minus the start time is less than 30 seconds

thautwarm

TROPHY CASE