71–80 of 149 posts
Earlier quoted context omitted.
You usually don't write anything other than emacs extensions in emacs lisp -- it would be overkill to have to start emacs just to start an HTTP server. For these purposes, guile would be a better choice?
yes.
Earlier quoted context omitted.
The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type. However all this can be represented fully without parentheses — and this is possible with Guile using a reader extension without losing any of its power. This is realiz…
> The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type. I've heard this repeatedly over the years, but the explanation unfortunately always stops right there. Could you please give an example of why you'd want to change yo…
Performance, macros are executed at compile time. Also, sometime the macro is easier to write that the equivalent non-macro code.
For me this is the most exciting part: Complete Emacs-compatible Elisp implementation Thanks to the work of Robin Templeton, Guile's Elisp implementation is now fully Emacs-compatible, implementing all of Elisp's features and quirks in the same way as the editor we know and love. This means we can finally have a proper GuileEmacs!
There’s still work to be done in pre-compiling the elisp in Guile Emacs to reduce the starttime (a lot).
Why are those brackets there in the syntax? What's the need? It looks hard to read when the programs are bigger. Is there any super advantage to it?
This "problem" is not unique to Lisps. Quite often, when I look at a piece of code written in C++, especially when it uses lambda functions inside calls, I can't help asking myself why there are so many brackets (and whether a Lisp would be a better alternative to C++, syntax-wise). The syntax of the lambda itself in C++ is sort of funny: it requires to use all the bracket types at the same time! [](){}
IMO it's an open question. There is not much statically typed lisp AFAIK.
Can anyone tell me if Guile is relevant? The list of example programs written in Guile is small. EmacsLisp and not Scheme seems to be the Gnu lisp of choice. The VM is not the fastest and not the most portable. Is there any driver behind it?
If you have all these constraints:
- must be easy to use extensions languages functions from C, and the other way around
- must therefore be easy to convert values from the extension language to C, and the other way around
- must be possible to share this state in a multi thread program
- including, have several threads implemented in the extension language
- must be able to load code at runtime
Then guile is not only a good choice, it's sadly the only possible choice (or at least that was the case last time I checked few years ago). Many languages that claim to be good at extending C are lacking one of the above (usually the multithreading part; Lua, for instance, allows to start several VM in several threads, but they are isolated).
Earlier quoted context omitted.
The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type. However all this can be represented fully without parentheses — and this is possible with Guile using a reader extension without losing any of its power. This is realiz…
> The super advantage of Lisp (including Scheme): Its format for defining data is the same as for writing code, making macros a natural part of the syntax: You can change your source code just like you’d change any other list (or rather tree) data type. I've heard this repeatedly over the years, but the explanation unfortunately always stops right there. Could you please give an example of why you'd want to change yo…
(Enter (Arne))
(Arne (Hello!) (Who are you?))
The above is actual code which makes Arne say two lines of text.
Essentially the Enter defines a new specialized control structure which is optimized for the task of defining lines of text for a character in an RPG to say.
This removes cognitive overhead while writing a scene: You only write what which character should say.
Essentially you invest into creating a better-fitting tool to simplify all following work. With Scheme you can take this further than with anything else — short of taking over the whole language implementation (which for example Facebook did with their new PHP implementations. With Guile you can take the path Facebook took, without first needing to be a multi-billion-dollar company). But as any other power, use this with care: You won’t want to make your code so much different from what other Schemers do that others have a hard time joining in.
¹: https://fosdem.org/2017/schedule/event/naturalscriptwritingg... — also see the video and the slides which show the difference between this syntax and examples from other methods, including one of my earlier tries with Python.
Earlier quoted context omitted.
> I've heard this repeatedly over the years, but the explanation unfortunately always stops right there. Lisp macros are something like C macros, chainsaws, hydrochloric acid, or anything else that's powerful-but-dangerous. This is to say that sometimes they are the one tool you have to use, but often they are unnecessary and should be avoided. Coming up on ten years ago, I wrote this blog post on one of the dangers…
All computer code is a dangerous tool that is often unnecessary and should be avoided if possible. A macro is no more or less dangerous than a function, class, variable, module, or anything else. C macros have the issue that even when everyone involved in the creation and use of a C macro understands its pifalls, those pitfalls cannot be removed from the macro. For instance, a certain C macro might evaluate some expr…
If your macros is 'fixed' to emulate function call semantics by evaluating its arguments only once, then maybe a function is a more appropriate abstraction in the first place. The whole point of macros is that they let you break the rules of function call application in hopefully useful and predictable ways.
Another way to look at it is that repeatedly evaluating an argument is what you do NOT want for a macro like 'getc', but probably what you DO want for a macro like 'repeat'. The danger lies in the fact that it's hard to tell the difference when looking at a call site in isolation.
Whether or not that danger is an acceptable risk is, of course, situation dependent.
Earlier quoted context omitted.
> skipping the parse step entirely. Not strictly true... there is still parsing involved in reading Lisp data structures from a character stream. (It's just much less involved than in traditional infix languages.) The way to think of it is this: 1) Lisp has a much more comprehensive (and read/write) syntax for its core data structures. 2) Lisp, the language, is defined in terms of those data structures rather than in…
I think of it as serialing/deserializins the AST to text :)
To see what I mean, consider this:
(if condition 1 2 3)
Earlier quoted context omitted.
All computer code is a dangerous tool that is often unnecessary and should be avoided if possible. A macro is no more or less dangerous than a function, class, variable, module, or anything else. C macros have the issue that even when everyone involved in the creation and use of a C macro understands its pifalls, those pitfalls cannot be removed from the macro. For instance, a certain C macro might evaluate some expr…
> a certain C macro might evaluate some expression twice. Everyone knows that this is dangerous...ISO C itself says that getc may evaluate its argument multiple times; ... Lisp macros do not have issues that are unfixable in this way. If your macros is 'fixed' to emulate function call semantics by evaluating its arguments only once, then maybe a function is a more appropriate abstraction in the first place. The whole…
;; cond evaluated exactly once;
;; then or else at most once, not before cond.
(if cond then else)