71–80 of 86 posts
Earlier quoted context omitted.
> The way that ryelang gets around this is that you pass the arguments in a "code block" surrounded by "{}" Like Lisp’s QUOTE which has to be a special form.
Is this correct though? Lisp's quote would need some eval or something to evaluate later afaik. More fitting might be a (lambda () ...), a.k.a. lazy evaluation.
Earlier quoted context omitted.
TCL is kinda similar to Rebol in some ways but in other ways it's the opposite of Rebol, because in TCL everything is a string (although it can ALSO have another type, thanks to clever shenanigans). (You probably knew this!)
I heard this "everything is a string" line many times abot Tcl and it sounded a little unusual, but I havent delved deep enogh in tcl to see what it really meant and brought. I will.
The way things are done now (and have been for a long time), is that values are stored in a
struct Tcl_Obj{
int refCount; // objs can be shared
int myType; // indicates whether currently a long, double, etc
long longVal;
double dblVal;
[...]
char *stringRep;
int len;
}
So "native" (eg: longVal) values are used when appropriate, no marshalling back/forth between strings, but the string rep is always available (can be generated), because that's what Tcl promises: everything is representable as a string. This is what brings the homoiconicity to Tcl - logically it's just passing text tokens around, and emitting text tokens. Internally, again, more sophisticated, but you get the point.
The blog entry titled "Less variables, more flows example vs Python" is strange. ( https://ryelang.blogspot.com/2021/11/less-variables-more-flo... ) The Python version uses intermediate variables so the author of the code is to blame for verbosity, not the language.
I don't see fewer variables as something good. On the contrary, I find a long "flow" or chain of function calls harder to read or grok. Variables also help readability, because the name can help you discern what those functions return.
Earlier quoted context omitted.
I mean, it's possible in lambda calculus. Anything above that is sugar, right?
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 3Li…
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?
Earlier quoted context omitted.
I mean, it's possible in lambda calculus. Anything above that is sugar, right?
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 3Li…
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 :)
Earlier quoted context omitted.
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 3Li…
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 doe…
True for function calls. But not for the zillions of macros. The "small number", you mention, are the small number of special operators. But there are many more macros. Those get the arg source unevaluated and return a Lisp form, which then is checked again (either by the compiler or at runtime by a source interpreter).
Earlier quoted context omitted.
> The way that ryelang gets around this is that you pass the arguments in a "code block" surrounded by "{}" Like Lisp’s QUOTE which has to be a special form.
Is this correct though? Lisp's quote would need some eval or something to evaluate later afaik. More fitting might be a (lambda () ...), a.k.a. lazy evaluation.
Earlier quoted context omitted.
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 3Li…
> 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?
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.
Earlier quoted context omitted.
I don't see fewer variables as something good. On the contrary, I find a long "flow" or chain of function calls harder to read or grok. Variables also help readability, because the name can help you discern what those functions return.
This is a valid argument. There are already a plenty of programming languages where you can do that. You can make temporary variables in Rye too, but it also tries to work well for these chains of expressions or function calls, and I personally prefer this style many times. There is no wrong way, IMO.
But using long chains of expressions is the same as one-liners or point-free style in Haskell. It saves some typing and also you can skim the code more easily, but only if you're extremely familiar with what's going on there.
I wonder how much you can benefit from this, if you return to the codebase after a 6-month break though. Maybe some people do manage to really memorise these details, but for some of us the effect is more like "wtf is this code doing?"
Earlier quoted context omitted.
This is a valid argument. There are already a plenty of programming languages where you can do that. You can make temporary variables in Rye too, but it also tries to work well for these chains of expressions or function calls, and I personally prefer this style many times. There is no wrong way, IMO.
If you're the only one reading the code, then sure write it however you like it. But using long chains of expressions is the same as one-liners or point-free style in Haskell. It saves some typing and also you can skim the code more easily, but only if you're extremely familiar with what's going on there. I wonder how much you can benefit from this, if you return to the codebase after a 6-month break though. Maybe so…