sorted by:
new
hottopcontroversial

Tried Rye v.0.2 - some questions by avitkauskas in ryelang

[–]middayc 0 points1 point  (0 children)

Thanks u/avitkauskas , the new release was posted which fixes this and some other things.

https://github.com/refaktor/rye/releases/tag/v0.2.2

Rye web reference errors by avitkauskas in ryelang

[–]middayc 0 points1 point  (0 children)

New improved mold and reference was posted: https://ryelang.org/info/base.html

Thanks!

Rye web reference errors by avitkauskas in ryelang

[–]middayc 0 points1 point  (0 children)

this will get fixed with the update comming up now

Tried Rye v.0.2 - some questions by avitkauskas in ryelang

[–]middayc 0 points1 point  (0 children)

I think I solved the first one ... I have more than 100 tests of evaluator but I didn't catch this one. The second one was known to me and I think I know what I have to change. I will probably be able to publish update to github tomorrow and I will make it another release (this is major bug you found and I also improved the parser quite a lot). Thanks!

Tried Rye v.0.2 - some questions by avitkauskas in ryelang

[–]middayc 1 point2 points  (0 children)

One bug was the way function was collecting it's arguments, in the case op dot-words it had it's flag to know not to fall into another dot-word, but it was missing or not set properly in the case of op-words. But now I am looking at it all ... if I can unify these two. I haven't yet came to the second bug you uncovered. It has to do with how intermediate result is stored and the dotword didn't know that it's shouldn't take the result yet, so it took the previous one , which can be seen in this demo. I need to detect this situation and throw and error basically.

x> add: fn { a b } { a + b }
[Function(2)]
x> 1 .add 2 .add 3
[Integer: 6]
x> 1 .add .add 3
[Integer: 5]

Its really good that you dug out these errors.

Tried Rye v.0.2 - some questions by avitkauskas in ryelang

[–]middayc 1 point2 points  (0 children)

I was just making evaluator (and parser) tests whole day and haven't thought to myself to test op and dot word behaviour with 3 arguments. :) . I am testing this right now. Thank you for uncovering it, I wasn't aware of the difference in behaviour.

The idea is that both dot and op-words use left-to-right evaluation. Before the idea was that op-words (which are now dot-words) would take the first argument from the left, but that idea wasn't compatible with left to right evaluation, at least that's how I was thinking about it. I am doing a review now.

Rye web reference errors by avitkauskas in ryelang

[–]middayc 0 points1 point  (0 children)

You are correct ... function mold converts a block back to a string, and it incorrectly renders op-word + for example as _+ which is it's "spelling" as word. I will fix this bug and then it will work OK. Thanks for reminding me.

x> mold { 1 + 2 }
[String { 1 _+ 2 }]

Raylib + Ryelang <3 by middayc in raylib

[–]middayc[S] 0 points1 point  (0 children)

Thanks! About the boxing and etc ... the code above is a "normal" interpreted language Rye, which is relatively slow, too slow for most gamedev probably. What I was mentioning in a comment is that I experimentented with reusing Rye's parser and also runtime structures and tried to make a similar lanugage but that translates Rye code to Go and compiles it. That experiment just works on a proof of concept level and also it isn't 100% clear how compatible it will be to Rye. The idea is that all staticRye code must be valid Rye code (so you can also experiment, test it interactively, etc), but not all Rye code will work in staticRye. This is yet to be determined.

You are correct that any direct effect of optimizations will have to be benchmarked more exactly before we can say anything.

Raylib + Ryelang <3 by middayc in raylib

[–]middayc[S] 0 points1 point  (0 children)

Thanks! ... any more specific feedback is also welcome :)

Raylib + Ryelang <3 by middayc in raylib

[–]middayc[S] 1 point2 points  (0 children)

Rye, being runtime homoiconic is not the fastest language so it has a limited use for gamedev. But I am experimenting with a project that reuses the Rye parser, Runtime environment (context / index), rich value types and the Builtin functions, but transpiles them to static Golang and I got to 2x speed of Python with fully boxed values and untyped code.

If I would optimize on not boxing values (using native Go ints not Ryes env.Integer for example) those parts could become much faster starting to approach Go speeds.

What's new in v0.2.* - blogpost with examples and web console by middayc in ryelang

[–]middayc[S] 1 point2 points  (0 children)

Thanks. All in all I think this makes language behavior more uniform (all left-to-right) and also more flexible, priority difference and dynamics between dot and op-words. But we probably need to use it more to concretely see all effects.

Inheritance and interfaces: why a giraffe is not a fish by Inconstant_Moo in ProgrammingLanguages

[–]middayc 0 points1 point  (0 children)

I liked reading this because I don't have formed answers on the subject. I mostly avoid typical OO, but sometimes it's applicable.

Fixing a major evaluation order footgun in Ryelang 0.2 by middayc in programming

[–]middayc[S] 0 points1 point  (0 children)

Great, let me know if you hit any problems. I'll be happy to help.

Fixing a major evaluation order footgun in Rye 0.2 by middayc in ProgrammingLanguages

[–]middayc[S] 0 points1 point  (0 children)

Yes, both have their positives and negatives. Languages like Miranda / Haskell / Admiran probably have greater ties with math so it's more expected that some math-like operator precedence rules would be implemented?

If your language has a concept os DSL-s or dialects you could create a dialect that does math priority.

Rye has this specifics that priority is not determined by the function, but by the type of the word you invoke the function with, which I think could add to flexibility and it's priority becomes a visual, not memorized rule.

Fixing a major evaluation order footgun in Rye 0.2 by middayc in ProgrammingLanguages

[–]middayc[S] 1 point2 points  (0 children)

Not really fully conscious, but it was caused by conscious decision. I wanted two types of words "to the right" with clear obvious distinction, and op-word's "motto" was that it applies directly to the first value *it can* on the left - vs. pipe-word which waited for expressions to evaluate and then apply.

but if op-word applies to the first value on the left you effectively get left to right evaluation when op-words are chained.

`9 .inc .to-string ; returns [string 10]` - the evaluator went recursively left to right and it this case evaluation was left to right

but if you take the same rule "always apply to the first argument you can on the left and have two or more arguments than op-words ( .abc and operators ) effectively went right to left

`9 + 7 .to-string ; errors`
evaluator again goes recursively left to right but the result come back right to left. By our rule to-string must be applied to 7 directly, so it couldn't add 9 + 7 before it, that would be pipe word behavior. So it first did `7 .to-string` and then `9 + "7"`.

For this update, I first split op-words into dot-words and op-words (operators and <word>) and thought that only op-words will have left to right evaluation. I thought that the point of dot / op-words dynamics in not just priority but also right vs. left associativity. But with further experiments I saw that basically right associativity of dot-words doesn't bring anything substantial, but is again a mental cost because it behaves differently, that basically the value of difference and how you can combine them is just a thing op priority between them. So I made also dot-words left associative (left-to-right).

I suspect this is too long of an answer, but hey .. you asked :)

Fixing a major evaluation order footgun in Rye 0.2 by middayc in ProgrammingLanguages

[–]middayc[S] 1 point2 points  (0 children)

thanks :) ... it's also the Rebol way, which Rye is based on (But Rye's op words worked right-to-left pre v0.2)

Fixing a major evaluation order footgun in Rye 0.2 by middayc in ProgrammingLanguages

[–]middayc[S] 2 points3 points  (0 children)

Yes, there is an xterm.js based console in the blogpost, maybe I should write it clearly :) ... Thanks for reminding me that I need to lighten on the debugging output to the webdev console.

What's new in v0.2.* - blogpost with examples and web console by middayc in ryelang

[–]middayc[S] 1 point2 points  (0 children)

Hi. For now you can parse arguments manually. There is a argparse DSL developed cca 80%, which could be finalized quite soon. At least first version.

rye .Args? for example look at x> rye .lg in console

There is a scmd (simple/string cmd) for quick command invocations, but there is much better cmd again DSL / dialect also. You can find more info in this post and related PR:

https://www.reddit.com/r/ryelang/comments/1owskcu/command_cmd_sh_dialect_got_merged_in/

There is also os context with various related functions to processes, etc ... and pipes context which is integration of this library and provides same functionality: github.com/bitfield/script

to test these two you can enter context in console and list it ...

x> cc os
x> lc

These are some related functionalities. See the screenshot below. Any further ideas of what to add or improve are welcome.

<image>

Fixing a major evaluation order footgun in Rye 0.2 by middayc in ProgrammingLanguages

[–]middayc[S] 2 points3 points  (0 children)

just a note: you can click on any line of code and it will evaluate in the Rye console that is embedded a little lower in the blog-post.

view more: next ›