Live data from Hacker News

GNU Guile 2.2.0

gnu.org

81–90 of 149 posts

Re: GNU Guile 2.2.0

#81
post #52

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?

0) Guile is a GNU project 1) Guile has no Global Interpreter Lock. 2) Guile is a scheme, so it is homo-iconic cf. https://en.wikipedia.org/wiki/Homoiconicity 3) Scheme (and lisp in general) are nice to write Domain Specific Languages. 4) Guile doesn't have a particular overhead for calling simple functions which makes it possibly as fast as C. 5) Guile has a very powerful object oriented programming framework beating…

Many of these would apply to most if not all scheme implementations though. I'm genuinely curious if there are use cases that set Guile apart from, say, Chez Scheme.

EDIT: Given that the original question appeared to imply "relevant as compared to other schemes"

Re: GNU Guile 2.2.0

#83
post #15

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!

While others in this thread rightly point out that there's still work to be done to make GuileEmacs, I'm interested in another use case that seems like it could potentially be realized in the near-ish term:

lib-org-mode.

I love org-mode, but wish that some of the features could be ported elsewhere just to make the format more ubiquitous. Or a stand-along org-mode notebook server. Or support in other text editors. Or...

Re: GNU Guile 2.2.0

#84
It seems that guile and lua have similar goals (one of the largest being to function as an extension language). Anyone have practical pros/cons between them?

Re: GNU Guile 2.2.0

#85
post #78

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…

By the way, some 18 years ago, I came up with a system for catching the use of expressions with side effects in C macros. Basically, I introduced an API that you could use in your macro definitions to identify insertions of expressions which would cause problems if containing side effects. This API, at run-time, would parse the expressions, analyze them for side effects, and diagnose problems. (It would also cache the results for faster execution of the same macro site.)

All the programmer has to do is achieve run-time coverage to catch all the problems.

We could define a getc-like macro such that getc(*stream++) would diagnose, provided that the line is executed.

See sfx.h and sfx.c here: http://git.savannah.nongnu.org/cgit/kazlib.git/tree/

Re: GNU Guile 2.2.0

#86

Earlier quoted context omitted.

It's been 6 years since Guile 2.0, when Guile went from being an interpreter only to having a VM and AOT compiler.

You mean a jit compiler. There is still not AOT compiler for GNU Guile AFAIK. Except janneke work.

There is an AOT compiler from source to bytecode, and then there is a bytecode interpreter. Wingo is considering the possibility of having a bytecode-to-native JIT or a source-to-native compiler.

Re: GNU Guile 2.2.0

#87
post #78

Earlier quoted context omitted.

> 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…

There are all kinds of macros that have to evaluate an expression exactly once, and cannot be made into functions. ;; cond evaluated exactly once; ;; then or else at most once, not before cond. (if cond then else) getc doesn't have to be a macro. It illustrates just the point that the macro issues in C are so unfixable that broken macros have even been codified in ISO C.

Sure, functions can do that and more (borrowing a page from Smalltalk):

    (if* cond
        #'(lambda () then)
      #'(lambda () else))
All the macro does is eliminate the need to write out all the lambda syntax.

   (defmacro (if cond then else)
      `(if* ,cond
          #'(lambda () ,then)
        #'(lambda () ,else)))
This brings my back to my original point: "the extent of the logic encoded in macros should be minimized, with the macros translating the code pretty much straight away into something built on more functional abstractions.".

Works in C too, although not as nicely:

    void dscwritef_impl(const _TCHAR * format_str, ...);
    
    #define pdscwritef(flag, args) \
         do { if (DEBUG_FLAG(flag)) dscwritef_impl args; } while(0);
The funny thing is, I think we're largely in agreement.

Re: GNU Guile 2.2.0

#88
post #52

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?

Besides being controlled by GNU, not really. Guilemacs is probably not going to happen either.

I like Emacs and all, but I'm really not sure why we'd be excited about Guile. Andy is a really awesome guy but he's the only one contributing to Guile, so there's no way it's ever going to compete with things like Chez or Racket (which is moving to Chez soon as well).

Re: GNU Guile 2.2.0

#89
post #52

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?

Besides being controlled by GNU, not really. Guilemacs is probably not going to happen either. I like Emacs and all, but I'm really not sure why we'd be excited about Guile. Andy is a really awesome guy but he's the only one contributing to Guile, so there's no way it's ever going to compete with things like Chez or Racket (which is moving to Chez soon as well).

Andy is not the only one contributing to Guile. He does a ton, for sure, but Guile is far from a one man show. There are 2 other maintainers and many other contributors.

Re: GNU Guile 2.2.0

#90
post #87

Earlier quoted context omitted.

There are all kinds of macros that have to evaluate an expression exactly once, and cannot be made into functions. ;; cond evaluated exactly once; ;; then or else at most once, not before cond. (if cond then else) getc doesn't have to be a macro. It illustrates just the point that the macro issues in C are so unfixable that broken macros have even been codified in ISO C.

Sure, functions can do that and more (borrowing a page from Smalltalk): (if* cond #'(lambda () then) #'(lambda () else)) All the macro does is eliminate the need to write out all the lambda syntax. (defmacro (if cond then else) `(if* ,cond #'(lambda () ,then) #'(lambda () ,else))) This brings my back to my original point: "the extent of the logic encoded in macros should be minimized, with the macros translating the…

I do not agree that an if macro stands for some specific lambda-based utterance. That isn't historically true, or in any other sense. The macro potentially stands for any and every possible way in which its semantics can be achieved.
Post reply on HN