Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

The Unison language

unisonweb.org

Post reply on HN
Print view View original

101–110 of 144 posts

Re: The Unison language

#101

Post by hybrids »

Tade0 wrote: post #44
giancarlostoro wrote: post #32

One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not. Show a sample of code with the console output or a screenshot of an UI from the code. I think Racket had it right ages back. They would show everything from a web server, to other things. This is what major programming languages (with some excepti…

Perhaps this is the reason: https://www.unisonweb.org/docs/language-reference#a-note-on-...

https://forum.nim-lang.org/t/2811

The Nim language in 2008 (when it was known as Nimrod) had originally been planned a similar approach of considering a unified AST with multiple "syntax skins," and as far as I understand there used to be a limited implementation of this. This would theoretically have been a boon for Nim, because an often complaint about Nim from emigrating programmers from languages with a C-style syntax was the (rather superficial) complaint - "no braces? Pythonic syntax? Yuck!"

https://forum.dlang.org/thread/mailman.1427.1428691340.3111....

The problem with this - and why Nim never really committed to the "syntax skin" concept - is that it would have led to far much fragmentation within Nim's own community as some users would prefer one "sub-language" over another. Given as it is the opinion of new languages (Nim included) towards a tool-based unified syntax formatting (e.g. certain naming conventions for identifiers, number of spaces for indent), "syntax skins" have become harder of a sell in favor of lingual consistency.

The original idea was that the same program could be rendered in a variety of different syntaxes in the author's IDE - but the implied maintenance cost of such skins plus that previously mentioned potential for fragmentation led to this idea falling to the wayside. Nim, as a language, grew to be quite flexible within its prime syntax over the years - e.g. the macro system (which modifies the AST directly) made way for a variety of DSLs (e.g. https://github.com/khchen/wNim#code-examples) that remain valid Nim code.

Re: The Unison language

#102

Post by strbean »

xwowsersx wrote: post #45
nadam wrote: post #13

Earlier quoted context omitted.

Hmmm, interesting. It is getting a bit philosophical: you can view it as a conflict. But you can also view it as: hm we have these nice 2 main functions. Let's create a merged one. Kind of what was previously conflict resolution becomes part of regular programming... A slight perspective change.

There's nothing philosophical about it! There will exist a conflict as far as Git (or any other) version control system is concerned. That's all he saying!

The files holding the ASTs are append-only. So you get:

PR #1: appended stuff

PR #2: appended stuff

So there is no merge conflict in the git sense.

Re: The Unison language

#103

Post by strbean »

capableweb wrote: post #93
aidenn0 wrote: post #91

Earlier quoted context omitted.

So I append X to my file and you append Y to your file, do we not have a conflict?

Yes and no. Yes as in, if you'd like them to be merged into a new one, then you'll have to resolve a conflict. But no as in, you both appended different data, so you both have new files from the original one, as you're dealing with immutable data.

If you want to resolve merges using the workflow of git, you can generate scratch files and diff them, right?

Re: The Unison language

#104

Post by strbean »

war1025 wrote: post #98

Maybe I'm missing something, but this seems like it would get unwieldy very quickly for anything more serious than toy examples. Even the toy examples I'm having trouble following along with. The benefit of code-as-text is that you can navigate the text without knowing what you are looking for. This seems to take the opposite approach of making it very easy to look things up assuming you know ahead of time what you a…

> What am I missing here?

I think IDE tooling for Unison could pretty easily give you the exact same experience. Generate code from the AST, group it reasonably, and give you a view that is indistinguishable from a traditional source tree.

It might be non-trivial to structure things nicely, but I think theres a good chance your generated structure would be better organized than a traditional codebase.

Re: The Unison language

#105

Post by strbean »

tasogare wrote: post #20
Avi-D-coder wrote: post #18

I really like the idea, I like the language, but the world will not be rewritten in Unison. A web assembly FFI story is needed for Unison to succeed.

Is this satire? Web assembly has no real adoption on the browser yet, is waiting for a standard I/O interface on the desktop to be useful and is itself the nth iteration of an old concept.

Unity targets WASM. I've run into several browser games using it in the wild.

Re: The Unison language

#106

Post by floatboth »

dunham wrote: post #88
ktpsns wrote: post #58

Earlier quoted context omitted.

Interesting. Maybe they should add further representations of the code. This is not the only language where there are mutliple representations of the same "code". Wolfram Mathematica (or "the Wolfram language") introduced "forms" for that, for instance https://reference.wolfram.com/language/ref/FullForm.html or https://reference.wolfram.com/language/ref/InputForm.html or, quite charming in the math context, https://r…

Also Bucklescript and ReasonML respectively provide OCaml and javascript-like syntax over the same AST and can translate your code between the two (as seen in the try reasonML UI).

That's not exactly how it works: Bucklescript is a JS backend for OCaml, and ReasonML is an alternative syntax for OCaml. Bucklescript is not involved in this translation, it generates the JS output on the top right pane of that UI.

Re: The Unison language

#107

Post by perfunctory »

giancarlostoro wrote: post #32

One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not. Show a sample of code with the console output or a screenshot of an UI from the code. I think Racket had it right ages back. They would show everything from a web server, to other things. This is what major programming languages (with some excepti…

> One thing that takes away from programming languages is not having code samples on the index. I think this lets someone know immediately if it's interesting to them or not.

Because when I see Chinese characters I know immediately if it's interesting to learn Mandarin or not.

Re: The Unison language

#108

Post by breuleux »

rzwitserloot wrote: post #100
nadam wrote: post #10

Earlier quoted context omitted.

" I make the green 'OK' button now red, and you make it blue" I did not fully read the introduction yet, but in my mind, in a truly content-addressed system this is not a conflict: you have the hash of a main() function which ultimately makes the button red, and the other guy has a main() function that makes the button blue. No conflict in the physical sense. Yes, philosophycally there is a conflict, which is resolve…

If it works precisely as you say, then most likely the last committer wins, and that's bad. The most hopeful case is that there is ONE place that isn't 'strictly append only', and that's, for lack of a better term, the 'main pointer'. Which hash is the actual state of the app as it should be compiled and deployed right now? Then THAT conflict, together with tooling to diff 2 different hashes, should swiftly lead to f…

> The most hopeful case is that there is ONE place that isn't 'strictly append only', and that's, for lack of a better term, the 'main pointer'. Which hash is the actual state of the app as it should be compiled and deployed right now?

I think that's how it works. The way I understand it from reading the tour, there is a separate store for the code and for the name mappings. Both main functions would merge without conflict into the code store, but the mappings would conflict.

Re: The Unison language

#109

Post by lilyball »

SamBam wrote: post #72
blamestross wrote: post #24

Append only is nice, but I would think a "Garbage Collect" would be useful. Remove all the code not attached to the import tree anymore. Otherwise you will just keep collecting junk forever Honestly git has the problem too, but I expect orphaned/dead code will happen a lot more with this approach.

Git has this problem only as far as the developer's storage of the history of all files is concerned. That "junk" doesn't remain in the final program. You can have a decades-old git repository containing hundreds of MBs of files, but output a 2kB program. Someone correct me, but it sounds like if you had the same thing with a unison project, the actual executable size can only grow?

My assumption is the content store can only grow, but any executable produced from it would only contain live code.

Re: The Unison language

#110

Post by jayrhynas »

breuleux wrote: post #108
rzwitserloot wrote: post #100

Earlier quoted context omitted.

If it works precisely as you say, then most likely the last committer wins, and that's bad. The most hopeful case is that there is ONE place that isn't 'strictly append only', and that's, for lack of a better term, the 'main pointer'. Which hash is the actual state of the app as it should be compiled and deployed right now? Then THAT conflict, together with tooling to diff 2 different hashes, should swiftly lead to f…

> The most hopeful case is that there is ONE place that isn't 'strictly append only', and that's, for lack of a better term, the 'main pointer'. Which hash is the actual state of the app as it should be compiled and deployed right now? I think that's how it works. The way I understand it from reading the tour, there is a separate store for the code and for the name mappings. Both main functions would merge without co…

This [1] seems to be the "head pointer", and I assume it would conflict when merging. In fact, would it not conflict on every merge even if unrelated code was changed, since it hashes on the value of the entire codebase?

Edit: After thinking some more, it wouldn't conflict on a file-level, since the file itself has a different name. But there would be now two files in the _head folder, and I assume the `ucm` tool would detect that and present the user with merging options?

[1]: https://git.io/Jvfen

Post reply on HN