Re: IXIN 1.2 available
On Sun 13 Jan 2013 12:53, Thien-Thi Nguyen writes: >The SXML modules don't do DTD parsing right now > > Is anyone working on that? No, I don't think so. Andy -- http://wingolog.org/
Re: case-lambda* question
On Wed 14 Nov 2012 11:20, Daniel Llorens writes: > (pass-if "case-lambda*" >(null? (call-with-warnings > (lambda () > (compile '(let ((f (case-lambda* >((x #:optional y) 1) >((x #:key y) 2) >((x y #:key z)3 > (list (f 1) > (f 1 2) > (f #:y 2) > (f 1 2 #:z 3))) >#:opts %opts-w-arity >#:to 'assembly) > > I also get an error here. Strangely, I can run make check without > anything being reported. The test doesn't actually run the result, it just compiles it. That's why it "works". Andy -- http://wingolog.org/
Re: case-lambda* question
On Thu 15 Nov 2012 02:01, Germán "A. Arias" writes: > /home/german/Escritorio/./test.scm:3:10: In procedure # #:optional y) | (x #:key y) | (x y #:key z)>: Odd length of keyword > argument list > > But there is one interest line > > 3: 0 [f 1 # 2 #:z 3] > > What mean this? That is taking the second argument as a keyword? This is an error that occurs during the parsing of keyword arguments. The arguments have been shuffled around, and you are seeing an intermediate state. Perhaps we should treat this case better. Andy -- http://wingolog.org/
Re: case-lambda* question
Hi Daniel, On Mon 12 Nov 2012 14:54, Daniel Llorens writes: > (define f > (case-lambda* > ((a b c #:key x) 3) > ((a #:key x) 1))) > > scheme@(guile-user)> (g 0 #:x 1) > $1 = 3 > > The manual says > >> Also, for completeness. Guile defines case-lambda* as well, which is >> like case-lambda, except with lambda* clauses. A case-lambda* clause >> matches if the arguments fill the required arguments, but are not too >> many for the optional and/or rest arguments. >> >> Keyword arguments are possible with case-lambda*, but they do not >> contribute to the “matching” behavior. That is to say, case-lambda* >> matches only on required, optional, and rest arguments, and on the >> predicate; keyword arguments may be present but do not contribute to I think this mention of a "predicate" probably refers to a brief time when each clause could have a predicate to determine if it matched; probably needs fixing. Fixed the docs. >> the “success” of a match. In fact a bad keyword argument list may >> cause an error to be raised. > > I see that it gives 3 because ‘a b c’ matches ‘0 #:x 1’, so it's > counting #:x as an ‘argument’ by itself. This is not what I expected > from the description above. I think that the description should make > clear that each item in the arg list is counted as an argument for the > purposes of matching. > > Moreover I think this behavior makes case-lambda* fairly useless, or > even treacherous. I wonder what other people think. So, the story here is fairly simple, but the result is complicated. The principles are: 1. Case-lambda* clauses match in order. Order is significant. 2. Each clause is considered in isolation. If the clause's formal arguments are compatible with the actual arguments, the clause is chosen. 3. Keyword arguments are not checked for compatibility. Commentary: 1. Straight-forward. 2. If you have some actual arguments ARGS... and a sequence of clauses CLAUSE1 CLAUSE2... of the form (FORMALS BODY...), to see if CLAUSE1 applies, consider it in isolation: ((lambda* FORMALS1 BODY1...) ARGS...) Does it apply? Then it will be chosen. 3. This rule is an exception to (2). Rationale: At runtime we try to be fast. Calling functions with keyword arguments doesn't allocate anything on the heap. Instead, after required and optional arguments are bound, Guile shuffles up the remaining arguments above the space reserved for the final values of the keyword arguments, and then binds them in the order they are passed to the function. This process is hairy and it's not easy to "roll back" to the initial state of the function call if a keyword does not match. Perhaps it is doable, but I was too scared to fully implement it. So, in your original example: (define f (case-lambda* ((a b c #:key x) 3) ((a #:key x) 1))) (f 0 #:x 1) Here we look at the first clause: ((lambda* (a b c #:key x) 3) 0 #:x 1) Does it apply? Yes, yes it does: the 3 required arguments consume the three arguments. So it is chosen, and this is correct, or at least consistent with lambda*. (Required arguments are taken by position only, regardless of what kind of object they are, even for keywords. Optional arguments are the same, _except_ within a clause that also has #:key arguments, in which case optionals are bound to positional arguments only while the positional arguments are not keywords.) Daniel Hartwig gives this second example, where the clauses are reversed: (define f (case-lambda* ((a #:key x) 1)) ((a b c #:key x) 3)) (g 1 2 3) Again, considering the first clause: ((lambda* (a #:key x) 3) 1 2 3) Does it apply? It shouldn't: there are three positional arguments, whereas only one is expected. However, Guile currently thinks that it does, in the case-lambda* context, because it only checks that there is at least one positional argument. This is probably a bug. The attached patch fixes the problem. If there are no comments against it, I will apply it to stable-2.0. It does introduce a slight incompatibility, but I don't think there are many case-lambda* users, and it makes cases work that previously failed to work. Andy >From 581f410fbd803721eb750ed8e7d6ec4cc4bcda79 Mon Sep 17 00:00:00 2001 From: Andy Wingo Date: Mon, 14 Jan 2013 11:38:09 +0100 Subject: [PATCH] case-lambda* clauses fail to match if too many positionals * doc/ref/api-procedures.texi (Case-lambda): Expand case-lambda* documentation. * module/ice-9/eval.scm (primitive-eval): * libguile/eval.c (prepare_boot_closure_env_for_apply): Dispatch to the next case-lambda clause if there are too many positionals. * doc/ref/vm.texi (Function Prologue Instructions): * libguile/vm-i-system.c (bind-optionals/shuffle-or-br): New instruction, like bind-optionals/shuffle but can dispatch to the next clause if there are too many posit
Re: GNU Guile community in google+
On Sun, Jan 13, 2013 at 12:33 PM, Andy Wingo wrote: > Hi, > > I'm catching up with mail and thought you might be interested in my > thoughts. They're just my thoughts, the thoughts of one Guile hacker, > and I don't represent Guile with them -- so please do make up your own > minds. > > I basically agree with Ludo and Mark that proprietary, centralized > social networks are bad for society, and are dangerous because they are > attractive. > > I agree with Zx that there are many ways that Guile could be better as a > community -- especially among new and younger Guilers, many of whom have > "come of age" in an internet sense on social networks. > > I think that Guile probably could engage with users who are already on > proprietary social networks, in a kind of announcement-oriented way, but > I agree that we as a project shouldn't try to build a community there. > Perhaps we could have someone manage "official" accounts for Guile on > these services and link them up to re-post things from our news feed. > > If there are community needs that are not being met right now, we should > try to identify them and find solutions. Is a blog aggregator the > thing, or is it something else? I liked the idea of a Guile subreddit, > though I don't know if it could get enough interest. > > Is there something that we need to build into gnu.org somehow? > > Whatever we do, I think we should try to point people to the "primary" > vehicles of discussion: the mailing lists and the IRC channel. > > Again, these are just opinions of one guy, take them as you will :) > > Cheers, > > Andy > -- > http://wingolog.org/ I agree entirely with your words. I wish engage newbie guilers (as me) who are already on proprietary social networks and I, too, think best solution is that someone manage accounts for Guile on these services and link them up to repost things. I think that repost things should be from a blog aggregator that should be created in www.gnu.org/software/guile/community.html . Conversations and questions say explicitly that must be in official Guile IRC, mailing lists (or subreddit?) As I said previously I created google+ community because I thought that it was the only unpretentious way for a noob. I agree that it is best solution as explained above. In summary, I think that some guile maintainer would have to create the blog aggregator and accounts should be created in identi.ca (already done), twitter (occupied account, it should be "GNU Guile begginers"), google+ and subreddit GNU Guile (I don't know but there is strong schemers community www.reddit.com/r/scheme (Read there Scheme implementations: /r/Racket only) . If someone expert Guiler wants to do this work it's perfect. If nobody wants to waste time then I can open accounts (passwords be sent to Guile maintainer) and manage it because I only would have to put links of blog agreggator and if some newbie guiler asks something I only would have to say: "Conversations in IRC and questions in official mailing lists, please" and for this I don't need MIT PhD. Even as a newbie forty years old I think I can do it.
Re: case-lambda* question
Hi! Andy Wingo skribis: > So, the story here is fairly simple, but the result is complicated. Woow, thanks for the clear and thorough explanation! [...] > Again, considering the first clause: > > ((lambda* (a #:key x) 3) 1 2 3) > > Does it apply? It shouldn't: there are three positional arguments, > whereas only one is expected. However, Guile currently thinks that it > does, in the case-lambda* context, because it only checks that there is > at least one positional argument. This is probably a bug. > > The attached patch fixes the problem. If there are no comments against > it, I will apply it to stable-2.0. It does introduce a slight > incompatibility, but I don't think there are many case-lambda* users, > and it makes cases work that previously failed to work. Yes, makes sense to me. Ludo’.
Re: GNU Guile community in google+
On Sun, Jan 13, 2013 at 12:33 PM, Andy Wingo wrote: > Hi, > > I'm catching up with mail and thought you might be interested in my > thoughts. They're just my thoughts, the thoughts of one Guile hacker, > and I don't represent Guile with them -- so please do make up your own > minds. > > I basically agree with Ludo and Mark that proprietary, centralized > social networks are bad for society, and are dangerous because they are > attractive. > > I agree with Zx that there are many ways that Guile could be better as a > community -- especially among new and younger Guilers, many of whom have > "come of age" in an internet sense on social networks. > > I think that Guile probably could engage with users who are already on > proprietary social networks, in a kind of announcement-oriented way, but > I agree that we as a project shouldn't try to build a community there. > Perhaps we could have someone manage "official" accounts for Guile on > these services and link them up to re-post things from our news feed. > > If there are community needs that are not being met right now, we should > try to identify them and find solutions. Is a blog aggregator the > thing, or is it something else? I liked the idea of a Guile subreddit, > though I don't know if it could get enough interest. > > Is there something that we need to build into gnu.org somehow? > > Whatever we do, I think we should try to point people to the "primary" > vehicles of discussion: the mailing lists and the IRC channel. > > Again, these are just opinions of one guy, take them as you will :) > > Cheers, > > Andy > -- > http://wingolog.org/ I agree entirely with your words. I wish engage newbie guilers (as me) who are already on proprietary social networks and I, too, think best solution is that someone manage accounts for Guile on these services and link them up to repost things. I think that repost things should be from a blog aggregator that should be created in www.gnu.org/software/guile/community.html . Conversations and questions say explicitly that must be in official Guile mailing lists (or subreddit?) As I said previously I created google+ community because I thought that it was the only unpretentious way for a noob. I agree that it is best solution as explained above. In summary, I think that some guile maintainer would have to create the blog aggregator and accounts should be created in identi.ca (already done), twitter (occupied account, it should be "GNU Guile begginers"), google+ and subreddit GNU Guile (I don't know but there is strong schemers community www.reddit.com/r/scheme (Read there Scheme implementations: /r/Racket only) . If someone expert Guiler wants to do this work it's perfect. If nobody wants to waste time then I can open accounts (passwords be sent to Guile maintainer) and manage it because I only would have to put links of blog agreggator and if some newbie guiler asks something I only would have to say: "Conversations and questions in official mailing lists, please" and for this I don't need MIT PhD. Even as a newbie forty years old I think I can do it.
Re: regexp character classes not supported?
From: Ian Price Subject: Re: regexp character classes not supported? Date: Tue, 08 Jan 2013 12:32:02 + > Klaus Schilling writes: > > > does irregex support SNOBOL-style patterns? > > I have not used SNOBOL, so I can't really say for sure if irregexes > functionality subsumes it. The documentation itself does not refer to > SNOBOL at all. > Snobol's pattern are said to be equivalent to recursive descent parsers with backtracking or to context free grammers. Klaus Schilling
Re: Guile API for foreign languages: proposing SCM scm_list_0(void)
>> The reason is accessing macros from languages >> other than C is cumbersome. > > Apologies for ignoring you. Hi, Wingo, Hi, All, No need to apologise, given your track record I trust you spending every minute of your time for a good purpose. :) Lack of time is a good evolutionary filter against worthless proposals. > I think that the thought that if we wanted > to follow through the logic of making Guile's C API available to non-C > languages, we should do so either all the way or not at all. This does not need to be a full Guile API, but rather a "Scheme" API --- the necessary minimum to "write Scheme in a foreign language". A language may be assumed to be C-interoperable, though macros should not be part of this interoperability. > Each additional function added to Guile's ABI imposes additional cost in > runtime memory, ELF symbol resolution, and (to a degree) startup time, > without providing any benefits to C users. On the other hand, if we are > only talking about 2 functions (say), then clearly we should do it. So > part of the question is, how much work are we talking about? Another valid reason to distinguish Guile and "Scheme" APIs. > I grepped the header files for lines starting with "#define SCM_", > munged out the name of the macro and sorted them for uniqueness. That > was around 1200 macros. I filtered out certain kinds of macros: > > * those ending in _H (header guards) > * those starting with SCM_I_ (internal macros) > * those containing _BIT (implementation details) > * SCM_VALIDATE_ macros (there are corresponding C procedures) > > That left me with about 900 macros. > > I then filtered out all macros that had a corresponding C binding. For > example, SCM_CAR has a C procedure, `scm_car'. That left me with about > 780 macros. > > Finally, from this list, I filtered out those symbols that did not > appear in our documentation. That resulted in the following 77 symbols: Thanks for a serious analysis. However there appear also to be some lower case scm_* macros documented as an API. Here are those that I had to "add to API as functions" in my case: scm_to_int(); scm_is_true(); scm_is_symbol(); scm_is_null(); These may be the real showstoppers. Someone on the list (or IRC) told me adding them as functions may result in a problem. Or was that "redefining them as functions"? I must confess that I never compiled Guile myself, so I am in no way qualified ehough to classify all the SCM_* macros left after your filtering, but let me start. The first group of a few constants contains those that are mentioned in the Scheme standard. Most of them may be obtained as a return value by calling that or another function. A global (linker) symbol or a dedicated "constructor" may be more convinient in some situations for foreign bindings: SCM_BOOL_F #f SCM_BOOL_T #t SCM_EOL '() SCM_UNDEFINED "something that when stored in a location makes it an error to try to obtain the value stored in the location (no such expression is defined in Scheme)" SCM_UNSPECIFIED (if #f #f) SCM_EOF_VAL (with-input-from-string "" read) Not so sure about the next two predicates. They do not have a Scheme counterpart, but appear to be an important implementation detail for functions of variable arity (I guess). There appears to be already some redundancy/confusion, at least for me [1]: SCM_UNBNDP SCM_UNBOUND The rest below should not be required to "write scheme in a foreign language", but rather to extend Scheme. Other macros, such as SCM_GLOBAL_VARIABLE_INIT, and snarfing magic are convenience macros for C programs and do not necessarily need to have a counterpart in other bindings: SCM_ALLOW_INTS SCM_ARG1 SCM_ARG2 SCM_ARG3 SCM_ARG4 SCM_ARG5 SCM_ARG6 SCM_ARG7 SCM_ARGn SCM_ASSERT_TYPE SCM_BYTEVECTOR_CONTENTS SCM_CELL_OBJECT SCM_CELL_OBJECT_0 SCM_CELL_OBJECT_1 SCM_CELL_TYPE SCM_CELL_WORD SCM_CELL_WORD_0 SCM_CELL_WORD_1 SCM_DEFER_INTS SCM_ELISP_NIL SCM_FRAME_DATA_ADDRESS SCM_FRAME_LOWER_ADDRESS SCM_FRAME_UPPER_ADDRESS SCM_GLOBAL_KEYWORD SCM_GLOBAL_VARIABLE SCM_GLOBAL_VARIABLE_INIT SCM_GPROC SCM_HOOKP SCM_IMP SCM_NEWSMOB SCM_NEWSMOB2 SCM_NEWSMOB3 SCM_PTAB_ENTRY SCM_PTOBNUM SCM_REGISTER_PROC SCM_RETURN_NEWSMOB SCM_RETURN_NEWSMOB2 SCM_RETURN_NEWSMOB3 SCM_SET_CELL_OBJECT SCM_SET_CELL_OBJECT_0 SCM_SET_CELL_OBJECT_1 SCM_SET_CELL_TYPE SCM_SET_CELL_WORD SCM_SET_CELL_WORD_0 SCM_SET_CELL_WORD_1 SCM_SET_SMOB_DATA SCM_SET_SMOB_DATA_2 SCM_SET_SMOB_DATA_3 SCM_SET_SMOB_FLAGS SCM_SET_SMOB_OBJECT SCM_SET_SMOB_OBJECT_2 SCM_SET_SMOB_OBJECT_3 SCM_SIMPLE_VECTOR_LENGTH SCM_SIMPLE_VECTOR_REF
