unofficial mirror of guile-user@gnu.org 
 help / color / mirror / Atom feed
* Guile outside of Emacs + Geiser
@ 2023-09-27 19:07 Christine Lemmer-Webber
  2023-09-27 19:47 ` Ricardo G. Herdt
                   ` (4 more replies)
  0 siblings, 5 replies; 10+ messages in thread
From: Christine Lemmer-Webber @ 2023-09-27 19:07 UTC (permalink / raw)
  To: guile-user

There's a long thread on guix-devel which is related and touches on many
things, but I thought I'd narrow in on this one thing.

Has anyone had a "good" experience programming with Guile without using
Emacs?  If so, what was your development experience like?

Furthermore, what's the right direction to making non-Emacs users have
as nice of an experience as Emacs users do?  Racket, for instance, has
lovely support in vscode with "Magic Racket".  What's the right path to
recommend for the present, and what's the best path to improve the
future?  LSP?  There are a few incomplete implementations I think but I
haven't tried them.

(Let's leave aside whether or not everyone should be using Emacs, or
other approaches to make Emacs easier for newcomers.  This thread is
specifically about making Guile useful to people who already have a tool
they like and present experiences.)

 - Christine



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-27 19:07 Guile outside of Emacs + Geiser Christine Lemmer-Webber
@ 2023-09-27 19:47 ` Ricardo G. Herdt
  2023-09-30 12:42   ` Christine Lemmer-Webber
  2023-09-27 19:48 ` Luis Felipe
                   ` (3 subsequent siblings)
  4 siblings, 1 reply; 10+ messages in thread
From: Ricardo G. Herdt @ 2023-09-27 19:47 UTC (permalink / raw)
  To: guile-user

Hi Christine,

I started writing a Guile LSP server a while ago 
(https://codeberg.org/rgherdt/scheme-lsp-server). Like you said it is 
incomplete, but I got following features so far:

- show signature
- show documentation
- autocompletion
- jump to definition
- show diagnostics

There is an open issue to integrate it into Guix: 
https://issues.guix.gnu.org/60286

I also wrote a simple client for VS Code: 
https://codeberg.org/rgherdt/vscode-scheme-lsp
This extension is focused on LSP support though, sort of a proof of 
concept. Syntax highlighting, REPL support etc could be integrated with 
other extensions. Or someone could implement a more involved extension 
to integrate these features, like what Magic Racket seems to do.

Honestly I have mixed feelings towards LSP. It's kind of a different 
mindset compared to traditional lisp editors: you get a language server 
that typically analyses the project statically, providing information 
regardless of the user's interaction with the REPL. My implementation 
relies, at least for Guile, on Geiser, so it works by interaction with a 
running Guile instance in the background. It might be enough for users 
coming from other editors, but I still prefer the way Slime/Swank works, 
where the REPL is the same image that provides information to the 
editor.

Regards,

Ricardo

Am 27.09.2023 21:07 schrieb Christine Lemmer-Webber:
> There's a long thread on guix-devel which is related and touches on 
> many
> things, but I thought I'd narrow in on this one thing.
> 
> Has anyone had a "good" experience programming with Guile without using
> Emacs?  If so, what was your development experience like?
> 
> Furthermore, what's the right direction to making non-Emacs users have
> as nice of an experience as Emacs users do?  Racket, for instance, has
> lovely support in vscode with "Magic Racket".  What's the right path to
> recommend for the present, and what's the best path to improve the
> future?  LSP?  There are a few incomplete implementations I think but I
> haven't tried them.
> 
> (Let's leave aside whether or not everyone should be using Emacs, or
> other approaches to make Emacs easier for newcomers.  This thread is
> specifically about making Guile useful to people who already have a 
> tool
> they like and present experiences.)
> 
>  - Christine



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-27 19:07 Guile outside of Emacs + Geiser Christine Lemmer-Webber
  2023-09-27 19:47 ` Ricardo G. Herdt
@ 2023-09-27 19:48 ` Luis Felipe
  2023-09-28  7:20 ` tomas
                   ` (2 subsequent siblings)
  4 siblings, 0 replies; 10+ messages in thread
From: Luis Felipe @ 2023-09-27 19:48 UTC (permalink / raw)
  To: Christine Lemmer-Webber, guile-user


[-- Attachment #1.1.1: Type: text/plain, Size: 1439 bytes --]

Hi,

El 27/09/23 a las 19:07, Christine Lemmer-Webber escribió:
> There's a long thread on guix-devel which is related and touches on many
> things, but I thought I'd narrow in on this one thing.
>
> Has anyone had a "good" experience programming with Guile without using
> Emacs?  If so, what was your development experience like?

I have tried several editors and IDEs, and you're pretty much left on 
your own, typing characters. The only assistance I've found is syntax 
highlighting and closing parenthesis automatically. Besides those, the 
minimum features I'd expect to feel comfortable editing scheme are 
structural editing (like Emacs paredit) and something like rainbow 
delimiters. These tools alone make any worries about parenthesis go away 
(at least in my case).

But I've always wanted the same level of assistance I find for Python.


> Furthermore, what's the right direction to making non-Emacs users have
> as nice of an experience as Emacs users do?  Racket, for instance, has
> lovely support in vscode with "Magic Racket".  What's the right path to
> recommend for the present, and what's the best path to improve the
> future?  LSP?  There are a few incomplete implementations I think but I
> haven't tried them.
Personally, I'm hoping projects like 
https://codeberg.org/rgherdt/scheme-lsp-server will make it easier to 
improve the experience outside Emacs (and maybe inside too).

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 2881 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 495 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-27 19:07 Guile outside of Emacs + Geiser Christine Lemmer-Webber
  2023-09-27 19:47 ` Ricardo G. Herdt
  2023-09-27 19:48 ` Luis Felipe
@ 2023-09-28  7:20 ` tomas
  2023-09-28 12:01   ` Mike Gran
  2023-09-28 12:23 ` Maxime Devos
  2023-10-13 13:38 ` Simon Tournier
  4 siblings, 1 reply; 10+ messages in thread
From: tomas @ 2023-09-28  7:20 UTC (permalink / raw)
  To: Christine Lemmer-Webber; +Cc: guile-user

[-- Attachment #1: Type: text/plain, Size: 1442 bytes --]

On Wed, Sep 27, 2023 at 03:07:10PM -0400, Christine Lemmer-Webber wrote:
> There's a long thread on guix-devel which is related and touches on many
> things, but I thought I'd narrow in on this one thing.
> 
> Has anyone had a "good" experience programming with Guile without using
> Emacs?  If so, what was your development experience like?

For one exotic datapoint: I do use Emacs as an editor (almost exclusively)
but never got the hang of Geiser. So I'm happy as a clam with Guile's
REPL in a plain & simple terminal.
> 
> Furthermore, what's the right direction to making non-Emacs users have
> as nice of an experience as Emacs users do?  Racket, for instance, has
> lovely support in vscode with "Magic Racket".  What's the right path to
> recommend for the present, and what's the best path to improve the
> future?  LSP?  There are a few incomplete implementations I think but I
> haven't tried them.

Some people are heavily working on Emacs's LSP support (as I said, not
my thing), so I'd expect that giving Guile a good LSP support too might
be a viable path to support (yuck [1]) vscode.

Cheers

[1] Sorry, I just can't suppress that completely, watching as I
   do how Microsoft is converting software development into Yet
   Another Social Network (and vscode is part of this, as is
   Github or as LinkedIn tried -- and failed to be).

   I'm a political animal, sorry for that.

-- 
tomás

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 195 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-28  7:20 ` tomas
@ 2023-09-28 12:01   ` Mike Gran
  0 siblings, 0 replies; 10+ messages in thread
From: Mike Gran @ 2023-09-28 12:01 UTC (permalink / raw)
  To: Christine Lemmer-Webber, tomas@tuxteam.de; +Cc: guile-user@gnu.org


On Thursday, September 28, 2023 at 12:20:58 AM PDT, <tomas@tuxteam.de> wrote: 

> On Wed, Sep 27, 2023 at 03:07:10PM -0400, Christine Lemmer-Webber wrote:
>> There's a long thread on guix-devel which is related and touches on many
>> things, but I thought I'd narrow in on this one thing.
>> 
>> Has anyone had a "good" experience programming with Guile without using
>> Emacs?  If so, what was your development experience like?

> For one exotic datapoint: I do use Emacs as an editor (almost exclusively)
> but never got the hang of Geiser. So I'm happy as a clam with Guile's
> REPL in a plain & simple terminal.

I also use emacs but not geiser.  And I only use emacs because of the auto-indentation
and tab-to-indent.

I've often used VSCode for other things, but, I never got indent of scheme to
be identical to emacs.

I once tried to write a graphical debugger in Gtk for Guile, but, gave up.
Like often happens, a fun idea ended up being real work.

Regards,
Mike Gran



^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-27 19:07 Guile outside of Emacs + Geiser Christine Lemmer-Webber
                   ` (2 preceding siblings ...)
  2023-09-28  7:20 ` tomas
@ 2023-09-28 12:23 ` Maxime Devos
  2023-10-13 13:38 ` Simon Tournier
  4 siblings, 0 replies; 10+ messages in thread
From: Maxime Devos @ 2023-09-28 12:23 UTC (permalink / raw)
  To: Christine Lemmer-Webber, guile-user


[-- Attachment #1.1.1: Type: text/plain, Size: 1907 bytes --]



Op 27-09-2023 om 21:07 schreef Christine Lemmer-Webber:
> There's a long thread on guix-devel which is related and touches on many
> things, but I thought I'd narrow in on this one thing.
> 
> Has anyone had a "good" experience programming with Guile without using
> Emacs?  If so, what was your development experience like?

I would say no.  In fact, neither has it been a "good" experience with 
using Emacs.

I have used nano in the past.  Nano provides some syntax colouring and 
grepping but that's it.  Development experience:

   * edit files with nano
   * run tests with "make check"
   * in case of tricky failures, try stuff out in the Guile REPL

> Furthermore, what's the right direction to making non-Emacs users have
> as nice of an experience as Emacs users do? [...]

As an Emacs user, I would say that my development experience inside 
Emacs is mostly the same as the development experience in nano, except 
for Emacs providing automatic indentation and being able to have 
multiple files open at once, with easy copying between them.

But that difference has almost nothing to do with Guile, it's just nano 
being minimalistic.

> Racket, for instance, has
> lovely support in vscode with "Magic Racket".  What's the right path to
> recommend for the present, and what's the best path to improve the
> future?  LSP?  There are a few incomplete implementations I think but I
> haven't tried them.
 >
> (Let's leave aside whether or not everyone should be using Emacs, or
> other approaches to make Emacs easier for newcomers.  This thread is
> specifically about making Guile useful to people who already have a tool
> they like and present experiences.)

I don't have such a tool -- neither Emacs nor nano is a good tool for me 
(no Emacs+Geiser isn't it, but the why appears to be off-topic for this 
thread).

Best regards,
Maxime Devos

[-- Attachment #1.1.2: OpenPGP public key --]
[-- Type: application/pgp-keys, Size: 929 bytes --]

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 236 bytes --]

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-27 19:47 ` Ricardo G. Herdt
@ 2023-09-30 12:42   ` Christine Lemmer-Webber
  2023-09-30 17:24     ` defn(life()) via General Guile related discussions
  0 siblings, 1 reply; 10+ messages in thread
From: Christine Lemmer-Webber @ 2023-09-30 12:42 UTC (permalink / raw)
  To: Ricardo G. Herdt; +Cc: guile-user

That's interesting.  Thank you for both the work and the observations
Ricardo!

It's interesting to hear, but maybe not surprising, that LSP seems to be
more oriented around a static programming mindset than a lispy
REPL-oriented development environment.

I guess it will be, as you say, more dedicated work to get proper Guile
support into these editors aside from "just using LSP", but that wasn't
obvious to me until I heard of your experiences!

 - Christine

"Ricardo G. Herdt" <r.herdt@posteo.de> writes:

> Hi Christine,
>
> I started writing a Guile LSP server a while ago
> (https://codeberg.org/rgherdt/scheme-lsp-server). Like you said it is
> incomplete, but I got following features so far:
>
> - show signature
> - show documentation
> - autocompletion
> - jump to definition
> - show diagnostics
>
> There is an open issue to integrate it into Guix:
> https://issues.guix.gnu.org/60286
>
> I also wrote a simple client for VS Code:
> https://codeberg.org/rgherdt/vscode-scheme-lsp
> This extension is focused on LSP support though, sort of a proof of
> concept. Syntax highlighting, REPL support etc could be integrated
> with other extensions. Or someone could implement a more involved
> extension to integrate these features, like what Magic Racket seems to
> do.
>
> Honestly I have mixed feelings towards LSP. It's kind of a different
> mindset compared to traditional lisp editors: you get a language
> server that typically analyses the project statically, providing
> information regardless of the user's interaction with the REPL. My
> implementation relies, at least for Guile, on Geiser, so it works by
> interaction with a running Guile instance in the background. It might
> be enough for users coming from other editors, but I still prefer the
> way Slime/Swank works, where the REPL is the same image that provides
> information to the editor.
>
> Regards,
>
> Ricardo
>
> Am 27.09.2023 21:07 schrieb Christine Lemmer-Webber:
>> There's a long thread on guix-devel which is related and touches on
>> many
>> things, but I thought I'd narrow in on this one thing.
>> Has anyone had a "good" experience programming with Guile without
>> using
>> Emacs?  If so, what was your development experience like?
>> Furthermore, what's the right direction to making non-Emacs users
>> have
>> as nice of an experience as Emacs users do?  Racket, for instance, has
>> lovely support in vscode with "Magic Racket".  What's the right path to
>> recommend for the present, and what's the best path to improve the
>> future?  LSP?  There are a few incomplete implementations I think but I
>> haven't tried them.
>> (Let's leave aside whether or not everyone should be using Emacs, or
>> other approaches to make Emacs easier for newcomers.  This thread is
>> specifically about making Guile useful to people who already have a
>> tool
>> they like and present experiences.)
>>  - Christine




^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-30 12:42   ` Christine Lemmer-Webber
@ 2023-09-30 17:24     ` defn(life()) via General Guile related discussions
  0 siblings, 0 replies; 10+ messages in thread
From: defn(life()) via General Guile related discussions @ 2023-09-30 17:24 UTC (permalink / raw)
  To: Christine Lemmer-Webber, Ricardo G. Herdt; +Cc: guile-user@gnu.org

Olical/conjure is a plugin for vim/nvim that helps work with repls for different lisps. I haven’t been able to really dive into it but it has tutorials. Maybe more tutorials would be awesome.

FM

On Sat, Sep 30, 2023 at 08:42, Christine Lemmer-Webber <[cwebber@dustycloud.org](mailto:On Sat, Sep 30, 2023 at 08:42, Christine Lemmer-Webber <<a href=)> wrote:

> That's interesting. Thank you for both the work and the observations
> Ricardo!
>
> It's interesting to hear, but maybe not surprising, that LSP seems to be
> more oriented around a static programming mindset than a lispy
> REPL-oriented development environment.
>
> I guess it will be, as you say, more dedicated work to get proper Guile
> support into these editors aside from "just using LSP", but that wasn't
> obvious to me until I heard of your experiences!
>
> - Christine
>
> "Ricardo G. Herdt" <r.herdt@posteo.de> writes:
>
>> Hi Christine,
>>
>> I started writing a Guile LSP server a while ago
>> (https://codeberg.org/rgherdt/scheme-lsp-server). Like you said it is
>> incomplete, but I got following features so far:
>>
>> - show signature
>> - show documentation
>> - autocompletion
>> - jump to definition
>> - show diagnostics
>>
>> There is an open issue to integrate it into Guix:
>> https://issues.guix.gnu.org/60286
>>
>> I also wrote a simple client for VS Code:
>> https://codeberg.org/rgherdt/vscode-scheme-lsp
>> This extension is focused on LSP support though, sort of a proof of
>> concept. Syntax highlighting, REPL support etc could be integrated
>> with other extensions. Or someone could implement a more involved
>> extension to integrate these features, like what Magic Racket seems to
>> do.
>>
>> Honestly I have mixed feelings towards LSP. It's kind of a different
>> mindset compared to traditional lisp editors: you get a language
>> server that typically analyses the project statically, providing
>> information regardless of the user's interaction with the REPL. My
>> implementation relies, at least for Guile, on Geiser, so it works by
>> interaction with a running Guile instance in the background. It might
>> be enough for users coming from other editors, but I still prefer the
>> way Slime/Swank works, where the REPL is the same image that provides
>> information to the editor.
>>
>> Regards,
>>
>> Ricardo
>>
>> Am 27.09.2023 21:07 schrieb Christine Lemmer-Webber:
>>> There's a long thread on guix-devel which is related and touches on
>>> many
>>> things, but I thought I'd narrow in on this one thing.
>>> Has anyone had a "good" experience programming with Guile without
>>> using
>>> Emacs? If so, what was your development experience like?
>>> Furthermore, what's the right direction to making non-Emacs users
>>> have
>>> as nice of an experience as Emacs users do? Racket, for instance, has
>>> lovely support in vscode with "Magic Racket". What's the right path to
>>> recommend for the present, and what's the best path to improve the
>>> future? LSP? There are a few incomplete implementations I think but I
>>> haven't tried them.
>>> (Let's leave aside whether or not everyone should be using Emacs, or
>>> other approaches to make Emacs easier for newcomers. This thread is
>>> specifically about making Guile useful to people who already have a
>>> tool
>>> they like and present experiences.)
>>> - Christine

^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-09-27 19:07 Guile outside of Emacs + Geiser Christine Lemmer-Webber
                   ` (3 preceding siblings ...)
  2023-09-28 12:23 ` Maxime Devos
@ 2023-10-13 13:38 ` Simon Tournier
  2023-10-16 19:41   ` Christine Lemmer-Webber
  4 siblings, 1 reply; 10+ messages in thread
From: Simon Tournier @ 2023-10-13 13:38 UTC (permalink / raw)
  To: Christine Lemmer-Webber, guile-user

Hi Christine,

On Wed, 27 Sep 2023 at 15:07, Christine Lemmer-Webber <cwebber@dustycloud.org> wrote:

> Has anyone had a "good" experience programming with Guile without using
> Emacs?  If so, what was your development experience like?

At work, I collaborate with people using different setup and different
programming languages.  And it can be tedious or time-consuming to
manage all that, for each; context switching, etc.  Therefore, most of
the times, we ends with: an editor (whatever which one) and a terminal
running some “REPL“.

For sure, it is better if $editor and $repl are able to communicate back
and forth.  However, most of the time, the pleasant experience comes
first from the $repl capacities.

Emacs + Geiser is often a way to have better $repl capacities than what
Guile offers by default.

For example, IPython, GHCi, R, Julia, etc. provides all a better
experience by default: completion, quick access to documentation, etc.

For what it is worth – not much! :-), let trivially compare below, in
order to get a feeling about one basic capacities.

Well, I think the “poor” experience programming with Guile without using
Emacs mainly comes from the lack of Guile REPL features by default.

My 2 cents. :-)

Cheers,
simon

--8<---------------cut here---------------start------------->8---
$ guix shell --pure guile -- guile -q
GNU Guile 3.0.9
Copyright (C) 1995-2023 Free Software Foundation, Inc.

Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
This program is free software, and you are welcome to redistribute it
under certain conditions; type `,show c' for details.

Enter `,help' for help.
scheme@(guile-user)> ,help map
Unknown command or group: map
scheme@(guile-user)> ,apropos map
(guile): map	#<procedure map (f l) | (f l1 l2) | (f l1 . rest)>
(guile): hash-map->list	#<procedure hash-map->list (_ _)>
(guile): char-set-map	#<procedure char-set-map (_ _)>
(guile): array-map-in-order!	#<procedure array-map-in-order! (_ _ . _)>
(guile): array-map!	#<procedure array-map! (_ _ . _)>
(guile): module-map	#<procedure module-map (proc module)>
(guile): or-map	#<procedure or-map (f lst)>
(guile): array-index-map!	#<procedure array-index-map! (_ _)>
(guile): and-map	#<procedure and-map (f lst)>
(guile): string-map	#<procedure string-map (_ _ #:optional _ _)>
(guile): map-in-order	#<procedure map (f l) | (f l1 l2) | (f l1 . rest)>
(guile): string-map!	#<procedure string-map! (_ _ #:optional _ _)>
(ice-9 threads): n-for-each-par-map	#<procedure n-for-each-par-map (n s-proc p-proc . arglists)>
(ice-9 threads): par-map	#<procedure 7f8076c96180 at ice-9/threads.scm:283:2 (proc . lists)>
(ice-9 threads): n-par-map	#<procedure n-par-map (n proc . arglists)>
scheme@(guile-user)> ,describe map
#f
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ guix shell --pure python python-ipython -- ipython 
Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0]
Type 'copyright', 'credits' or 'license' for more information
IPython 8.5.0 -- An enhanced Interactive Python. Type '?' for help.

In [1]: ?map
Init signature: map(self, /, *args, **kwargs)
Docstring:     
map(func, *iterables) --> map object

Make an iterator that computes the function using arguments from
each of the iterables.  Stops when the shortest iterable is exhausted.
Type:           type
Subclasses:     
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ guix shell --pure ghc gcc-toolchain -- ghci
GHCi, version 9.2.5: https://www.haskell.org/ghc/  :? for help
ghci> :? map
 Commands available from the prompt:

[...]

   :doc <name>                 display docs for the given name (experimental)

[...]

   :showi language             show language flags for interactive evaluation

 The User's Guide has more information. An online copy can be found here:

   https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html

ghci> :doc map
map :: (a -> b) -> [a] -> [b] 	-- Identifier defined in `GHC.Base'
 \(\mathcal{O}(n)\). 'map' @f xs@ is the list obtained by applying @f@ to
 each element of @xs@, i.e.,

 > map f [x1, x2, ..., xn] == [f x1, f x2, ..., f xn]
 > map f [x1, x2, ...] == [f x1, f x2, ...]

 >>> map (+1) [1, 2, 3]
 [2,3,4]
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ guix shell --pure r-minimal coreutils -- R 

R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
Copyright (C) 2023 The R Foundation for Statistical Computing
Platform: x86_64-unknown-linux-gnu (64-bit)

R is free software and comes with ABSOLUTELY NO WARRANTY.
You are welcome to redistribute it under certain conditions.
Type 'license()' or 'licence()' for distribution details.

R is a collaborative project with many contributors.
Type 'contributors()' for more information and
'citation()' on how to cite R or R packages in publications.

Type 'demo()' for some demos, 'help()' for on-line help, or
'help.start()' for an HTML browser interface to help.
Type 'q()' to quit R.

> help(map)
No documentation for 'map' in specified packages and libraries:
you could try '??map'
> ??map
Help files with alias or concept or title matching 'map' using regular
expression matching:

base::Filter            Common Higher-Order Functions in Functional
                        Programming Languages
  Aliases: Map
base::mapply            Apply a Function to Multiple List or Vector
                        Arguments

[...]

Type '?PKG::FOO' to inspect entries 'PKG::FOO', or 'TYPE?PKG::FOO' for
entries like 'PKG::FOO-TYPE'.
--8<---------------cut here---------------end--------------->8---

--8<---------------cut here---------------start------------->8---
$ guix shell --pure julia -- julia
WARNING: failed to select UTF-8 encoding, using ASCII
               _
   _       _ _(_)_     |  Documentation: https://docs.julialang.org
  (_)     | (_) (_)    |
   _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
  | | | | | | |/ _` |  |
  | | |_| | | | (_| |  |  Version 1.8.3 (2022-11-14)
 _/ |\__'_|_|_|\__'_|  |  
|__/                   |

julia> ?
help?> map
search: map map! mapfoldr mapfoldl mapslices mapreduce asyncmap asyncmap! macroexpand @macroexpand @macroexpand1 @atomicswap promote_shape ismutabletype

  map(f, c...) -> collection

  Transform collection c by applying f to each element. For multiple collection arguments, apply f elementwise, and stop when when any of them is exhausted.

  See also map!, foreach, mapreduce, mapslices, zip, Iterators.map.

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  julia> map(x -> x * 2, [1, 2, 3])
  3-element Vector{Int64}:
   2
   4
   6
  
  julia> map(+, [1, 2, 3], [10, 20, 30, 400, 5000])
  3-element Vector{Int64}:
   11
   22
   33

  ──────────────────────────────────────────────────────

  map(f, A::AbstractArray...) -> N-array

  When acting on multi-dimensional arrays of the same ndims, they must all have the same axes, and the answer will too.

  See also broadcast, which allows mismatched sizes.

  Examples
  ≡≡≡≡≡≡≡≡≡≡

  julia> map(//, [1 2; 3 4], [4 3; 2 1])
  2×2 Matrix{Rational{Int64}}:
   1//4  2//3
   3//2  4//1
  
  julia> map(+, [1 2; 3 4], zeros(2,1))
  ERROR: DimensionMismatch
  
  julia> map(+, [1 2; 3 4], [1,10,100,1000], zeros(3,1))  # iterates until 3rd is exhausted
  3-element Vector{Float64}:
     2.0
    13.0
   102.0
--8<---------------cut here---------------end--------------->8---





^ permalink raw reply	[flat|nested] 10+ messages in thread

* Re: Guile outside of Emacs + Geiser
  2023-10-13 13:38 ` Simon Tournier
@ 2023-10-16 19:41   ` Christine Lemmer-Webber
  0 siblings, 0 replies; 10+ messages in thread
From: Christine Lemmer-Webber @ 2023-10-16 19:41 UTC (permalink / raw)
  To: Simon Tournier; +Cc: guile-user

Good points in your email, Simon!  I'm used to REPLs being integrated
with editors, but if the rest of the world isn't, maybe giving them an
external REPL which feels good is already a step forward.

I thought I heard someone was working on an improved external REPL for
Guile but now I can't remember where I heard that...

 - Christine


Simon Tournier <zimon.toutoune@gmail.com> writes:

> Hi Christine,
>
> On Wed, 27 Sep 2023 at 15:07, Christine Lemmer-Webber <cwebber@dustycloud.org> wrote:
>
>> Has anyone had a "good" experience programming with Guile without using
>> Emacs?  If so, what was your development experience like?
>
> At work, I collaborate with people using different setup and different
> programming languages.  And it can be tedious or time-consuming to
> manage all that, for each; context switching, etc.  Therefore, most of
> the times, we ends with: an editor (whatever which one) and a terminal
> running some “REPL“.
>
> For sure, it is better if $editor and $repl are able to communicate back
> and forth.  However, most of the time, the pleasant experience comes
> first from the $repl capacities.
>
> Emacs + Geiser is often a way to have better $repl capacities than what
> Guile offers by default.
>
> For example, IPython, GHCi, R, Julia, etc. provides all a better
> experience by default: completion, quick access to documentation, etc.
>
> For what it is worth – not much! :-), let trivially compare below, in
> order to get a feeling about one basic capacities.
>
> Well, I think the “poor” experience programming with Guile without using
> Emacs mainly comes from the lack of Guile REPL features by default.
>
> My 2 cents. :-)
>
> Cheers,
> simon
>
> $ guix shell --pure guile -- guile -q
> GNU Guile 3.0.9
> Copyright (C) 1995-2023 Free Software Foundation, Inc.
>
> Guile comes with ABSOLUTELY NO WARRANTY; for details type `,show w'.
> This program is free software, and you are welcome to redistribute it
> under certain conditions; type `,show c' for details.
>
> Enter `,help' for help.
> scheme@(guile-user)> ,help map
> Unknown command or group: map
> scheme@(guile-user)> ,apropos map
> (guile): map	#<procedure map (f l) | (f l1 l2) | (f l1 . rest)>
> (guile): hash-map->list	#<procedure hash-map->list (_ _)>
> (guile): char-set-map	#<procedure char-set-map (_ _)>
> (guile): array-map-in-order!	#<procedure array-map-in-order! (_ _ . _)>
> (guile): array-map!	#<procedure array-map! (_ _ . _)>
> (guile): module-map	#<procedure module-map (proc module)>
> (guile): or-map	#<procedure or-map (f lst)>
> (guile): array-index-map!	#<procedure array-index-map! (_ _)>
> (guile): and-map	#<procedure and-map (f lst)>
> (guile): string-map	#<procedure string-map (_ _ #:optional _ _)>
> (guile): map-in-order	#<procedure map (f l) | (f l1 l2) | (f l1 . rest)>
> (guile): string-map!	#<procedure string-map! (_ _ #:optional _ _)>
> (ice-9 threads): n-for-each-par-map	#<procedure n-for-each-par-map (n s-proc p-proc . arglists)>
> (ice-9 threads): par-map	#<procedure 7f8076c96180 at ice-9/threads.scm:283:2 (proc . lists)>
> (ice-9 threads): n-par-map	#<procedure n-par-map (n proc . arglists)>
> scheme@(guile-user)> ,describe map
> #f
>
> $ guix shell --pure python python-ipython -- ipython 
> Python 3.10.7 (main, Jan  1 1970, 00:00:01) [GCC 11.3.0]
> Type 'copyright', 'credits' or 'license' for more information
> IPython 8.5.0 -- An enhanced Interactive Python. Type '?' for help.
>
> In [1]: ?map
> Init signature: map(self, /, *args, **kwargs)
> Docstring:     
> map(func, *iterables) --> map object
>
> Make an iterator that computes the function using arguments from
> each of the iterables.  Stops when the shortest iterable is exhausted.
> Type:           type
> Subclasses:     
>
> $ guix shell --pure ghc gcc-toolchain -- ghci
> GHCi, version 9.2.5: https://www.haskell.org/ghc/  :? for help
> ghci> :? map
>  Commands available from the prompt:
>
> [...]
>
>    :doc <name>                 display docs for the given name (experimental)
>
> [...]
>
>    :showi language             show language flags for interactive evaluation
>
>  The User's Guide has more information. An online copy can be found here:
>
>    https://downloads.haskell.org/~ghc/latest/docs/html/users_guide/ghci.html
>
> ghci> :doc map
> map :: (a -> b) -> [a] -> [b] 	-- Identifier defined in `GHC.Base'
>  \(\mathcal{O}(n)\). 'map' @f xs@ is the list obtained by applying @f@ to
>  each element of @xs@, i.e.,
>
>  > map f [x1, x2, ..., xn] == [f x1, f x2, ..., f xn]
>  > map f [x1, x2, ...] == [f x1, f x2, ...]
>
>  >>> map (+1) [1, 2, 3]
>  [2,3,4]
>
> $ guix shell --pure r-minimal coreutils -- R 
>
> R version 4.3.1 (2023-06-16) -- "Beagle Scouts"
> Copyright (C) 2023 The R Foundation for Statistical Computing
> Platform: x86_64-unknown-linux-gnu (64-bit)
>
> R is free software and comes with ABSOLUTELY NO WARRANTY.
> You are welcome to redistribute it under certain conditions.
> Type 'license()' or 'licence()' for distribution details.
>
> R is a collaborative project with many contributors.
> Type 'contributors()' for more information and
> 'citation()' on how to cite R or R packages in publications.
>
> Type 'demo()' for some demos, 'help()' for on-line help, or
> 'help.start()' for an HTML browser interface to help.
> Type 'q()' to quit R.
>
>> help(map)
> No documentation for 'map' in specified packages and libraries:
> you could try '??map'
>> ??map
> Help files with alias or concept or title matching 'map' using regular
> expression matching:
>
> base::Filter            Common Higher-Order Functions in Functional
>                         Programming Languages
>   Aliases: Map
> base::mapply            Apply a Function to Multiple List or Vector
>                         Arguments
>
> [...]
>
> Type '?PKG::FOO' to inspect entries 'PKG::FOO', or 'TYPE?PKG::FOO' for
> entries like 'PKG::FOO-TYPE'.
>
> $ guix shell --pure julia -- julia
> WARNING: failed to select UTF-8 encoding, using ASCII
>                _
>    _       _ _(_)_     |  Documentation: https://docs.julialang.org
>   (_)     | (_) (_)    |
>    _ _   _| |_  __ _   |  Type "?" for help, "]?" for Pkg help.
>   | | | | | | |/ _` |  |
>   | | |_| | | | (_| |  |  Version 1.8.3 (2022-11-14)
>  _/ |\__'_|_|_|\__'_|  |  
> |__/                   |
>
> julia> ?
> help?> map
> search: map map! mapfoldr mapfoldl mapslices mapreduce asyncmap asyncmap! macroexpand @macroexpand @macroexpand1 @atomicswap promote_shape ismutabletype
>
>   map(f, c...) -> collection
>
>   Transform collection c by applying f to each element. For multiple collection arguments, apply f elementwise, and stop when when any of them is exhausted.
>
>   See also map!, foreach, mapreduce, mapslices, zip, Iterators.map.
>
>   Examples
>   ≡≡≡≡≡≡≡≡≡≡
>
>   julia> map(x -> x * 2, [1, 2, 3])
>   3-element Vector{Int64}:
>    2
>    4
>    6
>   
>   julia> map(+, [1, 2, 3], [10, 20, 30, 400, 5000])
>   3-element Vector{Int64}:
>    11
>    22
>    33
>
>   ──────────────────────────────────────────────────────
>
>   map(f, A::AbstractArray...) -> N-array
>
>   When acting on multi-dimensional arrays of the same ndims, they must all have the same axes, and the answer will too.
>
>   See also broadcast, which allows mismatched sizes.
>
>   Examples
>   ≡≡≡≡≡≡≡≡≡≡
>
>   julia> map(//, [1 2; 3 4], [4 3; 2 1])
>   2×2 Matrix{Rational{Int64}}:
>    1//4  2//3
>    3//2  4//1
>   
>   julia> map(+, [1 2; 3 4], zeros(2,1))
>   ERROR: DimensionMismatch
>   
>   julia> map(+, [1 2; 3 4], [1,10,100,1000], zeros(3,1))  # iterates until 3rd is exhausted
>   3-element Vector{Float64}:
>      2.0
>     13.0
>    102.0




^ permalink raw reply	[flat|nested] 10+ messages in thread

end of thread, other threads:[~2023-10-16 19:41 UTC | newest]

Thread overview: 10+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-09-27 19:07 Guile outside of Emacs + Geiser Christine Lemmer-Webber
2023-09-27 19:47 ` Ricardo G. Herdt
2023-09-30 12:42   ` Christine Lemmer-Webber
2023-09-30 17:24     ` defn(life()) via General Guile related discussions
2023-09-27 19:48 ` Luis Felipe
2023-09-28  7:20 ` tomas
2023-09-28 12:01   ` Mike Gran
2023-09-28 12:23 ` Maxime Devos
2023-10-13 13:38 ` Simon Tournier
2023-10-16 19:41   ` Christine Lemmer-Webber

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).