11–20 of 24 posts
So `let` is being used to define a var that is lexically scoped to... the global environment?! I've noticed you can do this in Javascript as well. As a Lisp programmer, its very jarring and seems like a bad practice. Is there a reason you would do this?
So `let` is being used to define a var that is lexically scoped to... the global environment?! I've noticed you can do this in Javascript as well. As a Lisp programmer, its very jarring and seems like a bad practice. Is there a reason you would do this?
https://www.reddit.com/r/lisp/comments/bgwtsh/fun_ecl_hack/
It can be as simple as:
(defun c-repl ()
(loop (fresh-line)
(princ "c99> ")
(let* ((form (read-line))
(func (eval `(let ((*compile-verbose* nil))
(compile nil (lambda () (ffi:c-inline nil nil :void ,form)))))))
(funcall func))))
> (c-repl)
c99> printf("HELLO world!\n");
HELLO world!
c99> { for(int i=0; iFun thing is, you can just paste the above defun into your ECL REPL and execute it :).
Would not be my first choice. A good REPL allows you to write code quickly and off the top of your head. As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead. If you understand C it just gets in your way. If you don’t understand C it gets in your way even worse. Working with ObjC classes is cleaner, but even that has bridging issues. Incidentally,…
They look perfectly fine to me. What did you find troubling?
>TL;DR: Swift’s a hairy mess. [paraphrased jwz aphorism goes here]
The only mess described thus far is in the REPL/Playgrounds for the language, which are not themselves "Swift".
So `let` is being used to define a var that is lexically scoped to... the global environment?! I've noticed you can do this in Javascript as well. As a Lisp programmer, its very jarring and seems like a bad practice. Is there a reason you would do this?
As a programmer of any language, guessing at what something does, not verifying that the guess was right, and then complaining about it seems like a bad practice.
Would not be my first choice. A good REPL allows you to write code quickly and off the top of your head. As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead. If you understand C it just gets in your way. If you don’t understand C it gets in your way even worse. Working with ObjC classes is cleaner, but even that has bridging issues. Incidentally,…
> As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead They look perfectly fine to me. What did you find troubling? > TL;DR: Swift’s a hairy mess. [paraphrased jwz aphorism goes here] The only mess described thus far is in the REPL/Playgrounds for the language, which are not themselves "Swift".
Earlier quoted context omitted.
> As article notes, Swift’s C pointer/buffer semantics are absolutely horrendous, liable to melt the top of your head instead They look perfectly fine to me. What did you find troubling? > TL;DR: Swift’s a hairy mess. [paraphrased jwz aphorism goes here] The only mess described thus far is in the REPL/Playgrounds for the language, which are not themselves "Swift".
There are ten different pointer types, all with different and not easily memorized APIs.
If only C had those how safer it would be!
Earlier quoted context omitted.
There are ten different pointer types, all with different and not easily memorized APIs.
Well, it's all in the name, no? And the use is rather obvious, mutable vs not, typed vs not, and buffer types (contiguous memory with count of items) or not. If only C had those how safer it would be!
Indeed it would be, because then no-one would want to use C.
All languages are abstractions, but there are good abstractions and there are bad abstractions, and a truly depressing number of Swift abstractions fall firmly in the “not good” camp.
A well-designed type system abstraction would support and encourage free and open-ended composition of clearly-defined individual orthogonal concerns. Thus mutability would be a composable trait, `Mutable>`, untyped would just be `Pointer` without a constaint (Void being the default), and buffers would likewise be expressed via constraint, `Pointer>`. But Swift’s type system was designed by amateurs; its inconsistencies and lack of expressivity resulting in a stdlib that’s a bloated convoluted mess as it struggles around those limitations. (Makes even Ruby’s stdlib APIs look clean, consistent, and concise!)
So `let` is being used to define a var that is lexically scoped to... the global environment?! I've noticed you can do this in Javascript as well. As a Lisp programmer, its very jarring and seems like a bad practice. Is there a reason you would do this?
In Swift, IIRC, `let` defines a constant reference to a value within the current scope.
BUT, there is a gotcha: this “constantness” only applies to the name-value binding, not to the value itself. Thus you can still mutate the content of a let-bound value when that value is a class or class instance. Which kinda defeats the point of having the let/var distinction in the first place. C’s `const` may have its priorities backwards, but least it does what it says on the tin.
(And let’s not mention what a PITA Swift gets when you want to work with the contents of complex nested struct-based collections in a language that doesn’t have native pointers/references. Again, it makes C look good.)
Earlier quoted context omitted.
Well, it's all in the name, no? And the use is rather obvious, mutable vs not, typed vs not, and buffer types (contiguous memory with count of items) or not. If only C had those how safer it would be!
“If only C had those how safer it would be!” Indeed it would be, because then no-one would want to use C. All languages are abstractions, but there are good abstractions and there are bad abstractions, and a truly depressing number of Swift abstractions fall firmly in the “not good” camp. A well-designed type system abstraction would support and encourage free and open-ended composition of clearly-defined individual…
LOL. The amateurish type system design is the one you've described. Mutable> either makes the wrong thing mutable, or makes too much stuff mutable. Pointer> would make the whole language more complicated, and it doesn't solve any of the problems Swift's pointers solve. The Swift devs in fact are not amateurs, and it shows in how they managed to keep things simple, instead of convoluting the problem with total I-am-a-very-smart-Haskell-programmer complexity.
> Thus mutability would be a composable trait
I mean, this is a major tell. You don't just hand-wave mutability being a composable trait.