IRC channel logs

2022-10-02.log

back to list of logs

<a12l>Is there a way to find out if a special syntactical expression are a macro or a language primitive?
<a12l>I'm a Scheme newbie currently reading through the reference manual, and have just read ยง 3.3.1.4.
<a12l>Unsure how to describe them in my notes.
<lilyp>a12l: Type out the expression in a REPL. If you get a syntax error, it was a macro :P
<a12l>lilyp: Wait, so define and lambda are macros? :O
<a12l>What isn't a macro, so I can compare the results?
<lilyp>ah, sorry, I misread the question
<lilyp>I thought you wanted to differentiate between functions and macros (= syntax)
<a12l>I'm looking through R7RS, and it looks like lambda is part of the formal grammar. But from what I read on SO it seems that special syntactic expressions are also called special forms?
<a12l>The manual seems to just use the term "special form" without actually defining it.
<a12l>The manual also begins to use the term "function" instead of "procedure" the first time in that section, without defining it...
<jab>a12l: I think there was some talk about re-writting the guile manual. You could join in the effort!
<a12l>jab: Will see, I've to first learn the actual language and get used writing problems in Guile. :P
***maximed is now known as antipode
***Furor is now known as Haematophage
***NullPointerErro1 is now known as NullPointerError
***rgherdt_ is now known as rgherdt
<dthompson>it seems there's no way to handle duplicate bindings in the use-modules form? am I missing something?
<antipode>dthommpson: #:select
<antipode>dthompson: #:select
<antipode>With that, you can choose which module to take the binding from.
<dthompson>antipode: that will work for picking and choosing, which is normally what I want to do, but now I have a case where I want to merge generic procedures.
<dthompson>my solution is probably going to be to move this script code into a proper module
<antipode>dthompson: Have a look at the 'use-modules' documentation.
<antipode>In particular, #:duplicates
<antipode>(It has some information on GOOPS)
<dthompson>define-module has a #:duplicates option that applies to all modules that are loaded. use-modules, as far as I can tell, does not offer the same thing.
<antipode>dthompson: Put the #:duplicates in your 'define-module'?
<antipode>I assume the 'use-modules' will use that #:duplicates setting, though I haven't ever tried such a thing.
<antipode>Alternatively, you can move your 'use-modules' into a #:use-module (inside the define-module)
<dthompson>yes, my module defintions have this. however, I found myself in a situation where I had a script that is using use-modules to import multiple modules that define the same generic procedure. I want them merged in this instance. it doesn't seem like use-modules can handle the job.
<antipode>Your script can use 'define-module' instead of 'use-modules'.
<dthompson>yes, it can.
<dthompson>I was just checking to see if I was missing something about use-modules.
<dthompson>as a style thing I don't like to define a module inside an executable script.
<antipode>Alternative proposal -- if you don't need the generics to be merged, but rather you need access to both of them, you can use #:prefix to distinguish between them
<dthompson>that's a possible approach, but it sacrifices genericness.
<antipode>Alternatively, use '@' and manually merge the generics (with 'make-method'?)
<dthompson>it seems to me like there's a missing link here for GOOPS users. people that use generic procedures shouldn't have to do this much program modification to use them.
<antipode>The missing link is define-module + #:duplicates, I think.
<antipode>(Guile makes a module anyway under the hood, even if you don't use define-module, going by how I sometimes see #{ gNNN})
<dthompson>but when using use-modules, as is normal in a executable file, doesn't work. having to switch to an explicitly defined module is unideal, imo.
<dthompson>I think I will extract all this script code into a dedicated module and the script will be just a thin wrapper that calls that module. that will avoid the problem. it's just annoying to have to do this while I'm trying to quickly prototype something.
<antipode>Why a wrapper?
<antipode>Because style reasons?
<dthompson>for "real" scripts I always defer all the actual work to a module. the script just serves as the entry point for loading and calling that module.
<dthompson>I'm just currently in a state where I am prototyping something so I don't have that level of organization.
<dthompson>I have a few modules and then a script with all sorts of code in it testing things out.
<lilyp>dthompson: your script can still define a module, see tsukundere for an example that does just that
<dthompson>lilyp: yeah I know. I'm thinking about it more from a usability perspective where it would be nice if user code didn't have to change so much when merged generics are introduced.
<daviid>sneek: later tell dthompson there is indeed no way to ... in a script, you must call (default-duplicate-binding-handler
<daviid> '(merge-generics [...]))
<sneek>Okay.
<daviid>sneek: later tell dthompson, that is _after_ a first use-modules incantation (use-modules (oop goops)) - therefore, especially if your script is distributed (that might/will be run by users you do not have control on their guile settings, pre-using goops in particular, I always and recommend to do as in [as an example] all g-golf examples (which are scripts) -
<daviid> https://git.savannah.gnu.org/cgit/g-golf.git/tree/examples/gtk-4/hello-world.scm?h=devel
<sneek>Okay.
<daviid>sneek: later tell dthompson the template being https://paste.debian.net/1255735/
<sneek>Okay.
***Furor is now known as Colere