[HN Gopher] Rye Language
___________________________________________________________________
Rye Language
Author : emdashcomma
Score : 50 points
Date : 2024-07-12 17:11 UTC (5 days ago)
(HTM) web link (ryelang.org)
(TXT) w3m dump (ryelang.org)
| galaxyLogic wrote:
| This sounds cool:
|
| "Every active component in Rye is a function (if, loop, for, fn,
| return, extends, context). No keywords, no special forms."
|
| It should make the language much simpler than other languages.
| The challenge of programming is dealing with copmplexity in code,
| and if the language takes away much of that complexity it should
| be a good thing.
| middayc wrote:
| Thanks, that comes from it's REBOL base ideas, but maybe it's
| even more pronounced in Rye where also operators are just "op-
| word" functions, and any function can be op-word/pipe-word
| (also the ones above if loop for ...).
| galaxyLogic wrote:
| Not having studied Rye documentation, is it true that Rye
| syntax is "minimal"? Compared to for instance Smalltalk?
| middayc wrote:
| Yes ... Rye is syntax-wise in similar camp than Lisps, only
| without parenthesis. Some say Lisp has no syntax (which is
| debatable), but has a point that there are no syntax rules.
| There are multiple token types and they always combine /
| apply in the same ways, there are no special forms like
| "how to define a function" or "how to write and if else".
| In Rye calling if or eihter (if/else) is no different than
| calling any other function.
| galaxyLogic wrote:
| Note in Smalltalk ifTrue:ifFalse: is similarly just a
| method/function of the class Boolean. Rye seems very
| promising.
| middayc wrote:
| Thanks! Out of many languages I tried, I have to admit I
| never really worked with smalltalk. I should one day!
| lispm wrote:
| > There are multiple token types and they always combine
| / apply in the same ways, there are no special forms like
| "how to define a function" or "how to write and if else".
| In Rye calling if or eihter (if/else) is no different
| than calling any other function.
|
| Not in Lisp. In Lisp IF, COND, ... are either special
| operators or macros which expand to more primitive
| special operators. They are not functions.
|
| The syntax for COND is: cond {clause}*
| => result* clause::= (test-form form*)
|
| For example: (cond ((> x 1) (print
| 'larger) 1) ((= x 1) (print 'equal) 1)
| (t (print 'smaller)))
|
| COND is not a function. It is a macro. In a function call
| all arguments would be evaluated. But COND does not work
| that way.
|
| COND has a list of clauses. During evaluation, the first
| clause is looked at. It's first subform then is
| evaluated, here (> x 1). If that is true, then the
| following subforms are evaluated left to right and the
| values of the last form is returned. If the first subform
| form was not evaluated to true, the evaluation goes to
| the next form and repeats the process on the subform.
|
| * COND is not a function
|
| * COND has a special syntax
|
| * COND has a special evaluation rule
|
| The same is the case for defining functions. In Lisp the
| operator to define a global function is called DEFUN.
| DEFUN is a macro, not a function. It has special syntax
| (for example the second element in a DEFUN form needs to
| be an unevaluated function name, which usually (I omit
| some detail) needs to be a symbol (which will not be
| evaluated)...
|
| Again, DEFUN is not a function, it has special syntax and
| special semantics with side effects during compilation.
| middayc wrote:
| Yes, you are correct. I wasn't exact e nough about it,
| the end result syntax wise is similar, but there are
| macros involved in Lisps case.
|
| I wrote multiple times right about this difference
| between Rebol-s and Lisp-s. The main difference being
| that Lisps evaluate lists by default and you have to
| quote them to not be evaluated and Rebols don't evaluate
| blocks by default and you have to "do" them to evaluate
| them. That's why Rebol's can have if/loop/fn as ordinary
| functions and Lisps use Macros for them.
|
| If in rebol would be more like (if (> x 1) '(print
| 'larger)) I think.
|
| Thanks for making this clear ... it was a nice read.
| lispm wrote:
| > Lisps use Macros
|
| IF is a built-in special operator in Common Lisp. COND is
| a macro, which expands into IF forms.
|
| > (if (> x 1) '(print 'larger))
|
| Stuff like this would not really work Common Lisp for the
| following code example: (let ((x 1))
| (if (> x 1) '(print x)))
|
| The evaluator would not know that the X in the print form
| refers to the lexically bound X from the LET form.
| cardanome wrote:
| There is Lisps with so called f-expressions[0] which do
| not have special forms. That would be similar to the
| Rebol approach I think, I am a bit fuzzy on that.
|
| The general consensus in the lisp community is that
| having a few special forms is worth it as it makes the
| compiler's job much easier. Basically it is a trap
| because yes it is much more elegant but practically it
| isn't worth the trouble, or at least some people see it
| that way. I also heard that Smalltalk is considered hard
| to compile for its lack of special forms.
|
| But more complicated doesn't mean it is necessary
| impossible to still have a efficient compiler. It is
| definitely an interesting topic. Definitely would love to
| hear if you had any trouble on that front. If you already
| that far that you are thinking about optimization that
| is.
|
| And your new languages looks amazing. Definitely going to
| check it out.
|
| [0] https://web.cs.wpi.edu/~jshutt/kernel.html
| IshKebab wrote:
| That's a reasonably common feature in hobby languages, at least
| for basic flow control. I've seen it a few times before. You
| could say TCL works like this too in the most horrible way
| possible.
| bsder wrote:
| Apparently it's called "either" and it doesn't evaluate every
| arm.
|
| So, explain to me how that is a function and not a special
| form?
| RodgerTheGreat wrote:
| REBOL-family languages (including Logo) don't eagerly
| evaluate expressions like a Lisp, and therefore can use
| ordinary functions/operators in places that would otherwise
| need to be special forms and/or macros.
| middayc wrote:
| Exactly ... I tried to explain this here:
| https://ryelang.org/meet_rye/basics/if_either/
| ilyagr wrote:
| FYI, Rye is the name of a tool that's gaining popularity in the
| Python world. https://github.com/astral-sh/rye
| middayc wrote:
| I know about Rye package manager since last year. I've made a
| rye(lang) blogspot and github repository in 2020. I try to use
| term ryelang in general so there is a distinction. Otherwise,
| what can I do. I have no spare name and reason to rename right
| now, at the end, a name is just a name ...
| BiteCode_dev wrote:
| Interesting, but optional parenthesis is a no go for me.
|
| Every time I try to read a Ruby line with no (), I have to stop
| and think.
|
| Not being able to scan code is an anti feature.
| middayc wrote:
| Rye as Rebol (that it derives from) doesn't use parenthesis in
| general. In Rebol you can use them optionally for explicitly
| defining evaluation priority. But not in the same form as in
| Algol based languages: print(inc(x))
|
| But like Lisps. I've used them when I wanted to be very certain
| about evaluation, but not in general.
| (print(inc x))
|
| In Rebol (or Rye) this is usually just: print
| inc x
|
| That's why all function in Rebol/Rye have fixed arity and yes,
| you generally have to know it or deduce it from the code, which
| is a minus.
|
| Rye currently doesn't have parenthesis option, but it might get
| it at the end. It does have op and pipe words, an optional left
| to right flow, which can also better hint about the structure
| than pure polish notation of Rebol I think. For better of
| worse, these Rye expressions all do the same :) --
| print inc x print x .inc x .inc .print
| inc x |print
| __MatrixMan__ wrote:
| Ideally this would be a view setting, and could be enabled or
| disabled for different users without making edits to the code.
| middayc wrote:
| Yes, and IDE that would know the arity of functions (which is
| not totally simple, because of the very dynamic nature of the
| language) would be able to display the "parenthesis" or the
| grouping of function calls. I plan to make sort of visual
| editor for it too as an experiment so that could be a first
| demo of it.
| mofoteam wrote:
| Next stupid language name ideas: amaranth, barley, buckwheat,
| corn, farro, kamut, millet, oats, quinoa, rice, spelt, wheat, ...
| middayc wrote:
| why would cereals be worse than precious stones? :)
| eddd-ddde wrote:
| From single consonants, to animals, I don't know many
| languages with "real" names.
|
| Personally big fan of gemstones.
| ejstembler wrote:
| Looks interesting! +2 for Postgres and AWS support. Looking
| forward to GCP support someday...
| middayc wrote:
| Rye is Go based, and Go has a great number of well done
| libraries. Integrating Go libraries into Rye by hand is very
| simple and I was able to add plenty of them, at least at proof
| of concept level just on my own.
|
| Rye-front is also an experiment of how you can externally
| extend Rye, by adding Rye to your code/library. In this case
| the main focus is Go GUI library Fyne.
|
| Now a colleague is writing a tool that auto-generates Fyne
| bindings and has already made great progress (Fyne has couple
| of 1000 functions/structs/... If we will be able to generalize
| this to any Go library, this will be really exciting.
| skybrian wrote:
| Hint: the "interactive" demos are scrollable by dragging the
| bottom. (Sadly, you don't have any access to the terminal
| window's scrollbar, so you can't just scroll to the end of the
| "video.")
|
| I still think a non-animated transcript of a terminal session is
| better.
___________________________________________________________________
(page generated 2024-07-17 23:03 UTC)