So, I am developing (spend a half of year or so) a new Haxe compiler and a language dialect. I think it must be NOT a problem at all. People always invent new dialects and compilers for favourite tools. Please, dont react on it like "NOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOOO".
(sorry, I dont know how to write in English with less "I" words)
I am trying to follow the best practices and listen to the community.
Language is getting more and more shape. Lexer is almost complete (it was patched many times, in evolution), parser is partially works too. I had an experience writing target generators in JSApi and OCaml for Haxe, so they can be easily ported.
Of course, implementing Hindley-Milner, some cool macro tricks and toolkit is a bunch of work. But writing everything in Haxe is a joy!
Some words about a language. It looks more like a much different dialect, but the basics are same. I am strictly following Nicolas vision, but combining with my own and improving. And... more mainstream. O_o
The list is long and changing. You may ask me a specific questions about feature or syntax changes.
Toolkit is also fully redesigned. The compilation-server is enforced, but hidden. So no user will even know about it.
Two cents about me. I spent a hell crazy big amount of time to all this shit and want to finish it.
LLVM, virtual machines, garbage collectors, .....
But..but I just wanted to create games! :D But it seems like am a tool-developer at heart.
At a job (freelancer + startuper) I am making a crossplatform apps. Mobile and desktop.
Haxe is a best language/tool I ever used. But it lacks some... production-readytivity.
Shortly: I want to make it more relevant for wide production use. (addressing Daniel`s issue)
Why not improve existing OCaml compiler: you know... Nicolas wont accept... anyway, I dont like it. It event not documented/commented. No no no. Not that! HF will not accept SO much breaking language/toolkit changes. 10 years of work! Easier just to start from scratch.
I must write spec, manual, overview or something.
The repo is here - https://github.com/PeyTy/Alternative-Haxe
Rarely updated (dont like to push unfinished code).
Js, C++ and LLVM targets are in most priority.
Other targets will be attachable as a macro-plugins.
So no waiting about core compiler updates!
Just plug-and-play.
Sorry, there is so inadequately hot (in terms of weather). Looks like I just wrote down a bunch of random text. But the message is here :)
Have a good day!
Thanks! Yeah, a bit crazy.
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.
I really don't see the point to use Ocaml (for writing compilers) at all. Haxe's ADTs and matching system makes such task stupidly simple.
Simn even has a lexer-parser framework for Haxe written in Haxe + some macro magic. But I want the most optimal way of doing things here, expessially because of new lexeme-level macro system ;)
I do have a suggestion, even crazier. If you can, make it 100% haxe compatible, such that classes written in haxe will be compiled along with classes written in tng (or whatever you call it). This way you will not loose all the libraries written in hx syntax. That would make the haxe language GROW instead of Split.
Anyway, I would be happy to hear updates.
I already spent half a year. The hardest part is in past. Writing compiler (from scratch) in Haxe IS simple. I really was very surprised. Ocaml was mindblowing for me. Lexer and parser a fully handwrittend and its totally okay. Yeah, of course I'm using Ocaml sources as references :) The complete testing suite makes me happy too!
I really don't see the point to use Ocaml (for writing compilers) at all.
Haxe's ADTs and matching system makes such task stupidly simple.
Simn even has a lexer-parser framework for Haxe written in Haxe + some macro magic. But I want the most optimal way of doing things here, expessially because of new lexeme-level macro system ;)
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.
I have so much thoughts so I can write a book. Please, just wait for updates. Repo contains only finished solutions, not a prototype or experimental code.
I must first finish an AS3-like simple Haxe-JS compiler/transpiler, and only then improve it feature wise AND WRITE POSTS ABOUT FEATURES.
| if you want to be serious about having something running, you could put up an open source side project to "test" it
Of course! I am NOT making a language. But a complete solutions for production use. I have my own (production) codebase to test it. And, there will be some new tools on top of Alt Haxe in open source (for free commercial an real production use).
One of the core ideas - implement only production-proven features.
| It is fast.
If you write "ocamlish" code in Ocaml, it of course will be fast. But Im not writing Ocamlish. I know how CPUs cache system work, to optimize it. Suddenly, I can say that it probably will be as fast as Ocaml even written in Neko. Im making benchmarking in Neko, to be sure that my design decisions about performance is correct. Further compiling to HXCPP just be fast "as is".
| However I think you are fighting too many wars at once
I spend most of the time to simplify existing Haxe things. It was a real "war". But the result must be even simpler than writing code in Lua/JS/AS3.
The feature list is very strict, most of the flexibility was moved to macro system. Macro system, even AST, was reinvented to be very friendly for feature implementers.
So there will no "short-lambda-wars".
Its fun... but I think that there will be no sense to increase language complexity at all. Just use macro and done.
Compiler will become just more stable, and toolkit will be richer. Backwards compatibility is a must, so no breaking changes. But what to break if nothing to add? :)
(there is anyway many "hidden" features to implement in compiler. again, to make it simpler to use)
| I'm not really sure OCaml is all that hard
| I'm not really sure become a millionaire is all that hard
| I'm not really sure learning piano is all that hard
I'm not really sure leaning a language THAT _IS_ HARD FOR MY MIND AND FOR 90% OF PROGRAMMERS just makes any sense.
Go team rewrote compiler from C to Go EXACTLY because there is NO C-programmers there. Everyone uses Go. Many came from Ruby, Js, Python.
Why to use some crazy C, while they can just use Go and be happy with it.
Same decision here.
P.S. I learnt some basics of Ocaml to read Haxe compiler src, but anyway, it looks just like a bunch of random code, not maintainable in any sense for me
| If you can, make it 100% haxe compatible
It is possible to write a converters like in AS3. Haxe has many quirks, my dialect is not compatible
Woaw It sounds very ambigious what you are trying to accomplice; building and maintaining compilers for me looks quite "hardcore" :) I feel your enthousiasm! What is your drive when you are working on this already for so long!?
I already asked something on twitter, but I have some questions:
- why not bundle your enthousiasm+code powersss with the current team and just join them? I think we can use all help!?!
- what does "more productivity-ready" exactly means? If i can work faster Im very interested (!!) :)
Enjoy
Hello, Mark! I was to emotional that day. So, more unrolled answer:
| What is your drive when you are working on this already for so long!?
This is just a small part of big plan :D
/* Haxe will become a SkyNet and kill humans...hah...joking! */
Just enjoy improving things, and need a solid fundament for future.
| just join them?
To early to say. This project is very different from what HF are doing.
| what does "more productivity-ready" exactly means?
I wrote "production-ready". Not loosing productivity of course :)
- backwards compatibility, no breaking changes (after 2015, I think). Like in Java and AS3
- more updates, continuously, just-in-time
- mainstream simpler syntax+features, so more recruiters will be in future
- more solid, highly maintained built-in targets, and less built-it targets overall
- better flexibility
- 100% enforced documentation
- compiler written in Haxe is easy to maintain for other companies
- complete toolkit (re-factoring as an in-compiler tool, so IDE agnostic)
- etc etc etc
You can read Daniel Glazman`s messages in WWX 2015 Videos. His words made my vision of problem complete.
(Its not meant, that I fully agree with him, and depend on him - I started project long before all these community misunderstandings)
| "Language comparisons"
Its only a diff of Haxe and Alt Haxe. No any global meaning.
| Long features list
I'm proud of Nicholas. His vision and temperament will make (original) Haxe even better. His rejection of the extra features is not nonsense. Any feature should be included in the natural way, as in the minds of the people.
Everything, you wrote, was investigated by me. And is possible without breaking the language.
There will NO 999999+ syntax features.
"more than just rewriting a lexer or changing the syntax a little bit"
Changing a syntax? Nah. Iam a different beast.
Even a built-in macro collection is somewhat useless. You can add any (solid) feature with macro by yourself, or include a lib.
Language by itself must stay limited. Each company would add any syntax sugar they wish to be useful and natural for them.
The best thing about macro system, is that it dont break anything.
You can include any lib, event written in a very Haskell-like dialect (emulated with macro), but macro will not change code of YOUR app.
THIS IS FUCKING GENIUS! Praise Nicolas and team!
P.S. Imagine: Take ANSI C. Add macro system. Have this http://libcello.org/
ANSI C + MACRO = C+++
HAXE + MACRO = ABC+++
I dont meant that there will be a "pure Haxe that do nothing".
Vice versa. Its hard task to implement at least partially those features, and Im in process of researching HOW.
Adding nullability is possible with "automated proof technology" (like Nim uses for safe parallel code) so no syntax is required to change (mostly).
This is a VERY interesting possibility. I want to add most of features in this way - make them invisible yet powerful.
Any syntax must be reinvestigated/redesigned to fit an "attributes" syntax:
Something like `defer` become `@defer`. No keywords.
Something like `await` become `@await`. Same thing. Just macro.
Try to rewrite all/most of your ideas in this way, and Ill try to implement them.
Like `@magic(true magic here) function a() return @verymagical b;`
Increasing of syntax complexity will be rejected in Nicolas-style.
As you can see, `hello` is NOT initialized in declaration. Compiler will throw an error. But how we can _perfectly_ solve this?
- adding syntax, like:
`function new(var hello:String)` to move declaration to constructor (TypeScript style)
- add an attribute:
`@inited_in_new var hello : String` yeah, compiler is sooo stupid! just say to him to not throw, and trust us
- add a default value:
`var hello : String = default`
......etc
OR! DO NOTHING!
This example will be compiled because it's obvious that `hello` takes a non-null `b` in constructor!
A more complex example:
```
function x(a : Null<String>)
{
if(a == null) throw "WTF!";
var b = a.length;
var c = a.split("");
hello(a); // hello takes a non-null String
}
```
Again, solutions:
```
var b = a?.length;
var c = (a ?? "").split();
if(var temp = a) // Swift-style
hello(temp);
```
AAAAAND... Nope. Compiler will understand, that we already checked value for null.
Thats it.
An "automated proof technology" just means a more smart compiler, to understand more quirky code. Maybe, even in a global/wider scope.
Do you like it?
(You are right)
--
To post to this group haxe...@googlegroups.com
http://groups.google.com/group/haxelang?hl=en
---
You received this message because you are subscribed to the Google Groups "Haxe" group.
For more options, visit https://groups.google.com/d/optout.
Zero things. Some parts of the syntax are taken to make Haxe look more pleasant. I personally think that Swift is /not that good/ (Objective-C compatibility ruined this language). Pfff... I dont understand the point? Anyone, who is from or near core team/contributors just recommends me to "go away". I will not accept this. Haxe - is the best thing for today and tomorrow. Making new implementations will help it to evolve. In future, we will even can combine "two (or more) Haxes" to one standardized Haxe. Or standardize the whole concept, and make something like LLVM but for a high level languages https://tardisgo.github.io/
http://haxememes.tumblr.com/post/87036011589/simn-but-you-should-get-the-hell-out-of
| If the hill will not come to Mahomet, Mahomet will go to the hill.
Community wants short lambdas for last 5 years. I am not a part of Haxe Foundation. I am a part of this community.
| If the hill will not come to Mahomet, Mahomet will go to the hill.
| You are altering Haxe to work with different syntax/features?
| Language/compiler will be in AltHaxe instead of Ocaml?
Yes, full selfhosting
| Targets such as PHP, JS, C++ are handled via macro?
JS and CXX (C++ & LLVM) will be built-in. Other are via macro. Like JSGenAPI, but much better and flexible.
| Language features/syntax can be added with macro but require '@' such as await becomes @await?
There is many types of macro.
1. Lexeme preprocessor, for extending syntax itself (without any requirement, only limited to predefined set of tokens)
2. Classic macro functions. I think it must be replaced to @meta
3. @meta macroses. They works like attributes and can call macro-functions, depending on context
4. Macro classes. Its from original Haxe. Have not yet investigated. Never used
This is really not fully finished. The core concept of new macro system to make it "obvious". YellowAfterLife wrote recently that "@metas fail silently, while calling macro function will work always" -> I want to not allow such situations. @metas must be defined somewhere, to be used.
| Core syntax of AltHaxe will be strictly chosen as is the case with Haxe, community can extend via the macro method(but this is better than current macro method with Haxe?)
To be honest, current macro method is _very_ limited. Saying, for example, "you can just use macro to implement short lambdas!" is not true.
In AltHaxe you limited only on token level, not AST. So anything is possible.
Core syntax _of course_ will be strictly chosen. It must be very-very simple, understandable, eye candy, and powerful. But power comes from type system, theorem-solvers (static analyzing), ... and macro.
Dont think that I want to simplify and change syntax _only_ because of these reasons. It will be a really gift for community, maintainers and newcomers.
| '=>'. '?.' '??'. Does AltHaxe make it possible to configure language like this?
Yes. Definitely. New tokens can be proposed, but its more like "just add more ASCII chars to token list" :) And... most of them already here.
| this could lead to fragmentation
Macro system works only on-demand on a per-file or even per-expression basis. Language cannot be fragmented by design.
Someone could write his lib in one dialect, and it can be safely used in a lib with another dialect.
Think of Haxe as of Intermediate form. There is Tardis Go. Believe it or not, it will be possible even to use subset/kindof of Go just like a "yet another .hx file".
I already wrote Hugh about such macro to use Haxe 3.2 subset some messages above.
| I know normally you'd want a more controlled language as this could lead to fragmentation or different implementations perhaps when handled via community. If you take same stance/view as Nicholas, then when community wants to add to the language, what can be done? We can implement through this different macro approach? Or are there other ways? See the features Patrick demo's with his fork of Haxe, will AltHaxe be flexible to support these additions or would the language need to be modified in a way that my project source code will not run for another user unless they modify(or use fork) AltHaxe too.
"Language cannot be fragmented by design."
"Macro system works only on-demand on a per-file or even per-expression basis"
"extending syntax itself (without any requirement, only limited to predefined set of tokens)"
Example: http://hacking-haxe-dev.atouchofcode.com/#0de59
```
import PatrickDialect.apply; // Syntax will be changed. Maybe `using` fits better, or new keyword... anyway - import a macro first
// The macro is defined inside a some class, like always you do
#apply // enable preprocessor on a whole file basis
// maybe enabling via `using PatrickDialect.apply;` without a #this will be considered. #this syntax is more about "just apply this macro HERE and NOT any other place"
// but really only macro developer decides how his/her macro works
object EMath { // we enabled macro because there is not standard "object" keyword. so we need a lexer-level macro to support it.
@tco def fact(n, acc=1) return if (n<1) acc else fact(n-1, n * acc); // I just removed `:` so `@:` to `@`. Old meta-informational (non-macro) metas syntax is WIP
}
// def is also implemented in same macro. but say, it is NOT (just for example):
object EMath {
@tco #def fact(n, acc=1) return if (n<1) acc else fact(n-1, n * acc);
// def became #def.
// I `def` is just a shorthand for `function` its fun :)
// it will just replace current token
// and CONSIDER -> #macro CAN be nested like `var a = #do #other #another 42;` and WILL NOT conflict (pure magic!)
}
class Test {
static function main() {
trace(EMath.fact(12));
@tco function sum(n, acc=0) {
// @tco works at AST level.
// it takes args like @tco(a,b,c) and only second expression after `@tco this_expr;` (whole function node in this case)
if (n < 0) throw "n can't be negative";
if (n==0) return acc;
return sum(n-1, n+acc);
}
trace(sum(40));
}
}
```
As you can see - the solution is solid. I wont tell you all those marketing /***/ if it will not be possible. I was shocked when the solution (implementation) came to my mind!
| I believe Go also has a code format tool
Its already considered to be built-in. IDE must not support all this crazy stuff. Also, I am using Sublime, and it is not even an IDE :)
About original Haxe you may ask HF. I dont know why they didnt do this already.
And...
| stance/view as Nicholas, then when community wants to add to the language, what can be done
There is PLENTY of things to be done. Syntax is just nothing (hah, you can extend it by yourself!).
- Generating native binaries from compiler directly
- Making macro as fast as possible
- Making more unit tests
- Making generated code as optimized as possible
- Making smart error-detectors
- Extending STD
- Writing macro to support externs from another langs (like TypeScript`s .d.ts to be used in Js target)
- Extending toolkit
- etc etc etc
Community must understand this amount of work, and learn some macro magic. And no "Nicholas" problems will be involved.
LLVM. True native speed of C++. Just-in-time.
First (reference) implementation will be... hscript-like.
And then I will rewrite it to use LLVM JIT possibilities.
Using ANY virtual mahine is NOT an option AT ALL. Not in terms of percents of perf. But in terms of several orders of magnitude.
| Those are thoughts/constraints/ideas I hit when thinking about "how haxe
could be improved". I'm unsure I have solutions to all things I mentioned.
I'm very glad your participation!