61–70 of 87 posts
What does "is is is" mean in this language? Maybe it's a quine? Can you define an "isn't" operator?
“is is is” would be called BillClintonLang, no?
"It is what it is".
https://www.google.com/search?q=Trump+it+is+what+it+is
2nd hit onwards.
I would really like to see more discussions about the difficulties using LLVM can create for smaller language projects. The entire PL ecosystem is hyped up to revolve around the project, but rarely do you see language designers and solo/small group devs talk specifically about problems relying on LLVM. The history section of XL’s page cites non-commitment to code compatibility between releases as their big struggle,…
I use LLVM since v9, nowadays I'm stuck on v15 (that's not because of LLVM btw).
Between the two versions there's been a radical change too, i.e "opaque pointers", but the transition was rather smooth as we were provided, for a long time, the two versions of the functions affected by the change. Maybe the LLVM team got more serious since the author experienced the said difficulties ?
Other thing I note is that the author uses the CPP API. I use the C one which exposes only a high-level subset of the CPP one. This encourages a saner use of LLVM, a more concrete separation between the front-end and the mid-end, although sometimes there are limitations.
A simple example of what encourages the C API, especially since opaque ptrs are added, is not to rely on LLVM to retrieve the IR type of an IR value. That should always be done using the AST, eg with an `.ir` field in your nodes.
Another one I remark, after a brief overview of LLVM-CRAP, is that the author had to change the internal data structure used, depending on the LLVM version [0]. Using the C API that would never had happened. The C API essentially allows to create block refs, instructions refs, value refs, type refs, contexts. Then you choose the containers you want to use to hold them. No need to switch to another stdcpp one, even if internally LLVM does so.
[0]: https://github.com/c3d/xl/blob/master/src/llvm-crap.cpp#L265
I'd like C, but where I could use some syntax like: typedef _Load("libvector.so")(int) vector_int; to add arbitrary "builtin" types to the language. The idea being that "libvector.so" would use some spec-defined API to extend the core C language with the new features. This would replace a slew of features in the core C++ language (templates, classes, any sort of reflection, etc.), with some sort of 3rd party dylib yo…
Earlier quoted context omitted.
Obligatory "FORTH has had this for ages". :-)
Is Forth really homoiconic? I’m asking as a recent fan of Forth. I would’ve thought to describe it as having strong, interactive metaprogramming but not necessarily homoiconic. Unless ‘code = data, data = code’ because they’re all bytes… haha. Postscript would count as homoiconic, I’d think. Though I haven’t actually seen programs that so this.
Compiled Forths might opt to wall off some of those options behind the compiler interface, in effect making the language slightly less far-reaching.
Author of the project here... Weird to see this generates such a discussion when the project is something like 20 years old, and has been quasi-dead for a while now ;-) An interesting derivative of XL is Tao3D, which shows what you can do with it. https://tao3d.sourceforge.net A FOSDEM workshop about Tao3D (which includes initiation to XL): https://www.youtube.com/watch?v=uE9LwSuZD64 The design philosophy, and why it…
Earlier quoted context omitted.
Obligatory "FORTH has had this for ages". :-)
Is Forth really homoiconic? I’m asking as a recent fan of Forth. I would’ve thought to describe it as having strong, interactive metaprogramming but not necessarily homoiconic. Unless ‘code = data, data = code’ because they’re all bytes… haha. Postscript would count as homoiconic, I’d think. Though I haven’t actually seen programs that so this.
It is trivial to collect those Xts as data and execute them later.
CREATE XT-LIST ] THESE WORDS COULD BE FORTH CODE [
XT-LIST now contains six XTs. They can now be read one XT at a time and executed.
So if one accepts that those XTs are data, BUT they are also code since they can be "executed" by the Forth VM then I think we can say Forth is homoiconic.
However if that doesn't suffice it is perfectly legal to pass text strings to EVALUATE.
: TEST S" THESE WORDS COULD BE FORTH CODE" EVALUATE ;
That's all I got.
Author of the project here... Weird to see this generates such a discussion when the project is something like 20 years old, and has been quasi-dead for a while now ;-) An interesting derivative of XL is Tao3D, which shows what you can do with it. https://tao3d.sourceforge.net A FOSDEM workshop about Tao3D (which includes initiation to XL): https://www.youtube.com/watch?v=uE9LwSuZD64 The design philosophy, and why it…
https://www.piumarta.com/software/id-objmodel/objmodel2.pdf
The focus is on the object runtime where almost any operation including method lookup can be changed inside the end user environment.
Author of the project here... Weird to see this generates such a discussion when the project is something like 20 years old, and has been quasi-dead for a while now ;-) An interesting derivative of XL is Tao3D, which shows what you can do with it. https://tao3d.sourceforge.net A FOSDEM workshop about Tao3D (which includes initiation to XL): https://www.youtube.com/watch?v=uE9LwSuZD64 The design philosophy, and why it…
Makes me think of this paper "Open, extensible object models" by Ian Piumarta and Alessandro Warth: https://www.piumarta.com/software/id-objmodel/objmodel2.pdf The focus is on the object runtime where almost any operation including method lookup can be changed inside the end user environment.
Spring Framework & other Java IoC/DI stuff was pretty amazing. I kept finding new cool layers of depth as I dove into the model.
I love the idea of programming languages that might better integrate some of these ideas, of instrumentability. I'm not sure if it's actually necessary though; maybe having all these code assemblers living in userland libraries is fine.
Thanks for the link! Not sure if I've run into this VPRI / Warth combo paper, & worth revisiting either way.
Seems cool. But I'm not convinced extensible languages benefit from adding a variety of syntactic forms. As your ability to extend the feature-set increases, the need for a single regular syntactic form increases. Lisp may not be appealing to beginners because of its parenthesis, but they absolutely are what makes it work so well for its intended use cases. Really, all use cases. I'm actually a fan of the parenthesis…
I'm starting to be increasingly certain that making a new (sub)language to express and solve your problems is the highest form of programming. You'd think the ability to define custom syntax would be the most important, but paradoxically lisp makes it a lot easier simply because there is no syntax.
That is not much different from a mathematician that creates a new notation like "∞" or "∫_d_" because existing notation is capable but not convenient (to cluttered, shorthand needed to focus on domain concepts) for what needs to be done.
Earlier quoted context omitted.
I've always been curious about teaching total beginners Lisp. If the adage is true that learning a variety of languages will round you out in the long run, then experimenting with the S-expression, functional-lite model of Lisps as a first exposure should be low or zero-cost. And then we get to observe: If instead of modeling instructions and memory semantics, we first teach someone to model abstractions and computat…
Though the pool of students was biased towards those who excelled in high school which post 1980..1990 probably means some prior exposure (i.e., not your "total beginners"), this was a big part of the original idea behind SICP-6.001 at MIT. AFAIK, they gave up on that experiment 15 years ago and moved to Python: http://lambda-the-ultimate.org/node/3312 Being faculty / wordy, there is probably much written about it at…
The audience for the series I’m thinking of is adult professionals- programmers I believe. And I’d heard they were from DEC or HP or some such. So in addition to the material itself, you have the blessed quirkiness of its two authors, alongside a whole lot of late 70s/early 80s attire and rudimentary graphics. Quite a feast… lol.