5 ms·

This is possible with fexprs or equivalent constructs https://en.wikipedia.org/wiki/Fexpr https://en.wikipedia.org/wiki/Fexpr It looks like that's how Rye does

This is possible with fexprs or equivalent constructs https://en.wikipedia.org/wiki/Fexpr https://en.wikipedia.org/wiki/Fexpr It looks like that's how Rye does it as well, blocks can be conditionally evaluated: https://ryelang.org/meet_rye/basics/if_either/ https://ryelang.org/meet_rye/basics/if_either/ "In REBOL, contrary to Lisps, blocks or lists don’t evaluate by default. For better or for worse, this little difference is what makes REBOL - REBOL." https://ryelang.org/meet_rye/basics/doing_blocks/ https://ryelang.org/meet_rye/basics/doing_blocks/ It's difficult for a language with this semantics to be made efficient, but efficiency isn't everything.

fuzztester 3y ago
>programming language based on ideas from Rebol, flavored by Factor, Linux shell and Go That makes it potential interesting to me.
- fuzztester 3y ago
  potentially, autocorrect incorrect :)
_nalply 3y ago
Why is it difficult?
- samatman 3y ago
  Since code-is-data, you can put that exact if statement into several functions. Since code-is-data, you can swap the if and else clauses around. This applies to all the functions where you've inserted the if statement. This kind of thing makes it difficult to compile a function to a fast set of machine instructions with the same effect. Not impossible, but difficult.
- sparkie 3y ago
  It's difficult to optimize because evaluation of expressions depends on the dynamic environment, which you don't have ahead-of-time. You can't even assume `+` means "add the arguments", because `+` may have been bound to something completely different prior to evaluating the expression containing `+`.
  - alexisread 3y ago
    Late to the party here. What would be your take on dynamic-by-default, but the ability to fix the env a la Dreams (http://elilabs.com/~rj/dreams/dreams- http://elilabs.com/~rj/dreams/dreams- rep.html) or Zig (comptime)? You can obv. do this in Rye via a static context.
andrewflnr 3y ago
I mean, it's possible in lambda calculus. Anything above that is sugar, right?
- gumby 3y ago
  Yes, but with supposedly no special forms there cannot be a lambda operator. Turns out the language does have special forms, which is OK; it's just weird to say there aren't (though it's an understandable goal). When I worked on 3Lisp (so many decades ago) it became clear to me how many special forms there are (a small number, but more than I thought) and, honestly, how few there really are, so the "benefit" of a 3Lisp turns out to be negligible in practice. Oddly enough I didn't really notice that when writing interpreters because I thought of most special forms as simply compiler hacks ("eventually we can get rid of this").
  - JadeNB 3y ago
    > it became clear to me how many special forms there are … and … how few there really are … I'm having trouble parsing this. The two parts there seem to be saying opposite things. Was that an accident, or were you saying that from one point of view it seems to be a lot while from another point of view it doesn't, or something else?
    - gumby 3y ago
      The latter. When writing a somewhat standard implementation people expect redundant special forms (like both if and cond) so there are more than you think. OTOH you can implement some in terms of the others so maybe there aren’t as many as one might thing. Also, of course, in 3Lisp you can run code in your interpreter and so define new control structures and such. Turns out there aren’t many interesting ones and they have mostly already been thought of. One new control structure that didn’t need to modify its own interpreter was method combinators. Turns out they mainly useful for unpredictable behavior, except in very simple cases like :before and :after.
  - tln 3y ago
    I would say Rye does not have special forms; in LISP aiui, lists are evaluated by looking up the definition of first symbol, then evaluating the rest of the list, then apply the rest of the list to the definition. Except when the first symbol is one of a small number; then the list is evaluated fifferently. Rye's evaluator seems more complicated, but the forms are regular. A block is always evaluated the same way doesn't change how it's evaluated based on what the first element is. You can have lambdas without special forms in Rye because blocks aren't evaluated eagerly. Of course I could be way off; I've been having fun this morning poking at Rye for the first time and my Lisp / Scheme exposure is limited to Uni classes eons ago and a resulting allergy to parentheses. Seeing the meta-circular Rye would tell us for sure :)
gumby 3y ago
I know well what a FEXPR is (I was a Maclisp maintainer) but they are special forms. It is interesting to imagine inverting the sense of execution, but as you say it's hard to do much optimization.
- samatman 3y ago
  They're special forms in a language where functions are something which eagerly evaluates its arguments. In a language where functions don't do that, they're just functions. Rye appears to be one of those languages. One could quibble about whether that's the right thing to call them, but if we say they're vau or whatever, "everything in Rye is a vau" is still true. I think calling them functions is reasonable though.
  - sparkie 3y ago
    In Kernel, we could argue that operatives are the more fundamental type of combiner, and applicatives (aka functions) are the sole special-form, constructed by calling `wrap` on another combiner.
sctb 3y ago
This is how Joy and Factor work as well, so I'd say this is standard fare for concatenative languages.

fuzztester 3y ago

>programming language based on ideas from Rebol, flavored by Factor, Linux shell and Go That makes it potential interesting to me.

fuzztester 3y ago
potentially, autocorrect incorrect :)

_nalply 3y ago

Why is it difficult?

samatman 3y ago
Since code-is-data, you can put that exact if statement into several functions. Since code-is-data, you can swap the if and else clauses around. This applies to all the functions where you've inserted the if statement. This kind of thing makes it difficult to compile a function to a fast set of machine instructions with the same effect. Not impossible, but difficult.
sparkie 3y ago
It's difficult to optimize because evaluation of expressions depends on the dynamic environment, which you don't have ahead-of-time. You can't even assume `+` means "add the arguments", because `+` may have been bound to something completely different prior to evaluating the expression containing `+`.
- alexisread 3y ago
  Late to the party here. What would be your take on dynamic-by-default, but the ability to fix the env a la Dreams (http://elilabs.com/~rj/dreams/dreams- http://elilabs.com/~rj/dreams/dreams- rep.html) or Zig (comptime)? You can obv. do this in Rye via a static context.

andrewflnr 3y ago

I mean, it's possible in lambda calculus. Anything above that is sugar, right?

gumby 3y ago
Yes, but with supposedly no special forms there cannot be a lambda operator. Turns out the language does have special forms, which is OK; it's just weird to say there aren't (though it's an understandable goal). When I worked on 3Lisp (so many decades ago) it became clear to me how many special forms there are (a small number, but more than I thought) and, honestly, how few there really are, so the "benefit" of a 3Lisp turns out to be negligible in practice. Oddly enough I didn't really notice that when writing interpreters because I thought of most special forms as simply compiler hacks ("eventually we can get rid of this").
- JadeNB 3y ago
  > it became clear to me how many special forms there are … and … how few there really are … I'm having trouble parsing this. The two parts there seem to be saying opposite things. Was that an accident, or were you saying that from one point of view it seems to be a lot while from another point of view it doesn't, or something else?
  - gumby 3y ago
    The latter. When writing a somewhat standard implementation people expect redundant special forms (like both if and cond) so there are more than you think. OTOH you can implement some in terms of the others so maybe there aren’t as many as one might thing. Also, of course, in 3Lisp you can run code in your interpreter and so define new control structures and such. Turns out there aren’t many interesting ones and they have mostly already been thought of. One new control structure that didn’t need to modify its own interpreter was method combinators. Turns out they mainly useful for unpredictable behavior, except in very simple cases like :before and :after.
- tln 3y ago
  I would say Rye does not have special forms; in LISP aiui, lists are evaluated by looking up the definition of first symbol, then evaluating the rest of the list, then apply the rest of the list to the definition. Except when the first symbol is one of a small number; then the list is evaluated fifferently. Rye's evaluator seems more complicated, but the forms are regular. A block is always evaluated the same way doesn't change how it's evaluated based on what the first element is. You can have lambdas without special forms in Rye because blocks aren't evaluated eagerly. Of course I could be way off; I've been having fun this morning poking at Rye for the first time and my Lisp / Scheme exposure is limited to Uni classes eons ago and a resulting allergy to parentheses. Seeing the meta-circular Rye would tell us for sure :)

gumby 3y ago

I know well what a FEXPR is (I was a Maclisp maintainer) but they are special forms. It is interesting to imagine inverting the sense of execution, but as you say it's hard to do much optimization.

samatman 3y ago
They're special forms in a language where functions are something which eagerly evaluates its arguments. In a language where functions don't do that, they're just functions. Rye appears to be one of those languages. One could quibble about whether that's the right thing to call them, but if we say they're vau or whatever, "everything in Rye is a vau" is still true. I think calling them functions is reasonable though.
- sparkie 3y ago
  In Kernel, we could argue that operatives are the more fundamental type of combiner, and applicatives (aka functions) are the sole special-form, constructed by calling `wrap` on another combiner.

sctb 3y ago

This is how Joy and Factor work as well, so I'd say this is standard fare for concatenative languages.