free expressions (namely quoted lists) and returns the last one which is
(define q "i am Q\n")
This then gets evaluated at run time, defining q .
You probably wanted something like
`(begin (define p ...) (define q ...))
as your body (and return expression) instead.
> (my-macro-old 1 2)
> (my-macro-new 1 2)
> (display x1)
> (display x2)
> (display q)
> (display p)
>
>
> thanks,
--
David Kastrup
Linus Björnstam writes:
> On Sat, 1 Feb 2020, at 12:09, David Kastrup wrote:
>>
>> Can you expand about the "expansion time and macro time separation"?
>>
>> If we have
>>
>> (define decl '())
>> (define (make-var n v) (list "
Han-Wen Nienhuys writes:
> On Sat, Feb 1, 2020 at 11:11 AM David Kastrup wrote:
>> >> Here is an example that shows better how things work, and what might
>> >> be the cause of my problems. Is it right that programmatically set
>> >> contents of "
hat inner calls make-var (and
accesses decl) which is only being defined at expansion time.
The error message, however, rather appears to complain about inner being
undefined rather than the definition of inner referring to undefined
entities.
Can you clarify?
--
David Kastrup
/.cache/guile/ccache/2.2-LE-8-3.A/home/hanwen/vc/lilypond/ew.scm.go'
>> [hanwen@localhost lilypond]$ GUILE_AUTO_COMPILE=0 guile2.2 ew.scm
>> I-am-called-at-runtime xy
>> Backtrace:
>>6 (apply-smob/1 #)
>> In ice-9/boot-9.scm:
>> 705:2 5 (call-with-prompt ("prompt") # …)
>> In ice-9/eval.scm:
>> 619:8 4 (_ #(#(#)))
>> In ice-9/boot-9.scm:
>>2312:4 3 (save-module-excursion #)
>> 3832:12 2 (_)
>> In ew.scm:
>> 10:10 1 (runtime-call "xy")
>> In unknown file:
>>0 (scm-error misc-error #f "~A ~S ~S ~S" ("No variabl…" …) …)
>>
>> ERROR: In procedure scm-error:
>> No variable named xy in #
>>
But that is not using a local define at all. Can you point out the
actual code that failed for you?
--
David Kastrup
pilation run is not an
option.
But you really cannot maintain one large project sensibly under two
fundamentally different toolchains. Particularly not a GNU-relevant one
that will want to be able to access a number of UNIX-typical facilities
and programs in order not to degress into what programming was before
the seventies.
--
David Kastrup
mp; ~(scm_t_bits) 0xff00);
+
+ return (void *) smobnum;
+}
this looks like only clearing the smob type field, leaving the flags in
place. So if you really need some former type information for a
decommissioned object, it could be stored in the flags (which are
documented as still being referenceable).
--
David Kastrup
*/
/* The setter and getter are unsynchronized.*/
GC_API void GC_CALL GC_set_java_finalization(int);
GC_API int GC_CALL GC_get_java_finalization(void);
This might be enough to make the scheme work. A whole bit of type field
might be much, however. I seem to remember that there are only 8 to go
around anyway.
--
David Kastrup
David Kastrup writes:
[...]
I apologize for sending this and the previous mail to the Guile-devel
list in violation of my ban here. I had been of the impression that
this was copied to the LilyPond developer list rather than the Guile
developer list.
Feel free to delete it.
--
David Kastrup
Jan Nieuwenhuizen writes:
> David Kastrup writes:
>
> Hi David,
>
>> Shouldn't we worry about switching _to_ guile-2.0 first?
>
> Are you asking for help on this?
Is there any to be had? I got a whole lot of promises from Guile
developers over the years. Basical
nstead of throwing early.
Shouldn't we worry about switching _to_ guile-2.0 first?
--
David Kastrup
remember correctly, even something like C:\tmp\nul.txt would serve
as null device, though I cannot vouch for this remaining true with
NT-based Windows systems. It was the case for those versions running on
top of MSDOS I'm pretty sure.
--
David Kastrup
Pierpaolo Bernardi writes:
> On Wed, Jun 20, 2012 at 4:27 PM, David Kastrup wrote:
>> Andy Wingo writes:
>>
>> If the Scheme standard states that
>>
>> (and (pair? x) (not (eq? (car x) (car x
>>
>> can return #t in a conforming implementation,
Andy Wingo writes:
> On Wed 20 Jun 2012 16:31, David Kastrup writes:
>
>> Andy Wingo writes:
>>
>>> interesting and permissible optimizations
>>
>> Name one.
>
> FWIW, eta-conversion (for primitives). Copy propagation for the
> purposes of inli
Andy Wingo writes:
> On Wed 20 Jun 2012 16:27, David Kastrup writes:
>
>> I am not comparing numbers when writing (eq? x x).
>> I am checking the identity of an object. Whether that object is a
>> number or not, and if so, what value it has, is irrelevant.
>
>
er or running memq on a
list containing a number.
That would be interesting and apparently permissible behavior. I have
my doubts that users will be impressed favorably.
--
David Kastrup
do so in an alternate universe.
Again: it is fine if an optimizer chooses not to track object identities
for numeric values. But if it doesn't, it needs to assume they are eq?
when equal rather than some random choice.
--
David Kastrup
David Kastrup writes:
> I think it is completely absurd. It would mean, for example, that
> (memq x (list x))
> is generally unspecified. It would mean that things like
> (eq? (car x) (car x))
> are generally unspecified even when x is a pair.
So that we can have (eq? x x) but
Andy Wingo writes:
> On Wed 20 Jun 2012 12:40, David Kastrup writes:
>
>> Numbers and characters are not equal to any other object, but the
>> problem is they're not necessarily `eq?' to themselves either.
>> This is even so when the num
specified*
I think that is wrong. A variable reference can't really be anything
except eq? to itself in my opinion. As long as a Scheme object is not
being manipulated in any manner, it should stay eq? to itself.
What am I missing?
--
David Kastrup
start index agnostic).
Indexes in math often run from 1, being able to translate into a
straightforward 1-based rendition can avoid transliteration errors.
It is definitely a higher-level feature and not a fundamental property
of underlying primitive data types, though.
--
David Kastrup
Daniel Hartwig writes:
> On 15 June 2012 01:15, David Kastrup wrote:
>> Daniel Hartwig writes:
>>> What is this half-in-place algorithm that makes this efficient? If
>>> the table is to remain balanced, all items should be rehashed and
>>> realloc
Daniel Hartwig writes:
> On 14 June 2012 23:34, David Kastrup wrote:
>
>> Huh? When resizing a hash table by doubling, you need to recoalesce
>> each bucket to two buckets, one of which is the original. Doubling
>> the size of the underlying vector is a rea
Daniel Hartwig writes:
> On 14 June 2012 22:47, David Kastrup wrote:
>> Mark H Weaver writes:
>>
>>> David Kastrup writes:
>>>> Scheme/Guile vectors are fixed size. [...] It is a bit of a nuisance
>>>> that one can grow a hashtable eff
Mark H Weaver writes:
> David Kastrup writes:
>> Scheme/Guile vectors are fixed size. [...] It is a bit of a nuisance
>> that one can grow a hashtable efficiently and on-demand, but not so an
>> array.
>
> Although Scheme vectors should remain fixed-size for reaso
Mark H Weaver writes:
> David Kastrup writes:
>> Mark H Weaver writes:
>>> C++, like Scheme, already supports fixed-size vectors in the core
>>> language, so it would be redundant to include them in a library.
>>
>> A vector with run-time determined siz
Mark H Weaver writes:
> Hi David,
>
> David Kastrup writes:
>> Mark H Weaver writes:
>>> Simpler data structures can usually be implemented with less memory,
>>> shorter code sequences with fewer conditional branches and less space in
>>> the instruct
Mark H Weaver writes:
> Hi David,
>
> David Kastrup writes:
>> I don't think I need yet another data structure deficient in some
>> respects. We have vectors that can't grow, hashtables that can grow but
>> only index through a hash function, vlists that c
Andy Wingo writes:
> On Mon 11 Jun 2012 16:19, David Kastrup writes:
>
>> Are you even reading what you are replying to?
>
> Please be civil. People are trying to help you.
More like telling me off. Of course, I am perfectly able to implement
my own moderately efficien
Daniel Hartwig writes:
> On 11 June 2012 20:20, David Kastrup wrote:
>>> P.S.: I still need to look at vlists. They might already address this
>>> issue, though I can't use them in Guile 1.8.
>>
>> No, the "immutable" angle would make them
Daniel Hartwig writes:
> On 11 June 2012 20:00, David Kastrup wrote:
>>> I guess to summarize: if you want an abstraction like tables, you would
>>> build it out of vectors and hash tables. But vectors and hash tables
>>> themselves are the lower-level buildi
e point in thinking up yet another restriction that will make
for a new data structure "complementing" the others?
Why not just have a superset without arbitrary restriction and implement
the other structures based on that? Then each one just needs to enforce
its personal restrictions in its accessor functions, and otherwise just
use what is there in the general mechanism.
--
David Kastrup
David Kastrup writes:
> David Kastrup writes:
>
>> Andy Wingo writes:
>>
>>> Hi,
>>>
>>> On Mon 11 Jun 2012 11:55, David Kastrup writes:
>>>
>>>> Tables are a superset of what I need here. I need the "growable vector&q
David Kastrup writes:
> Andy Wingo writes:
>
>> Hi,
>>
>> On Mon 11 Jun 2012 11:55, David Kastrup writes:
>>
>>> Tables are a superset of what I need here. I need the "growable vector"
>>> aspect, not the "hash part"
Andy Wingo writes:
> Hi,
>
> On Mon 11 Jun 2012 11:55, David Kastrup writes:
>
>> Tables are a superset of what I need here. I need the "growable vector"
>> aspect, not the "hash part" aspect. Guile 1.8 only offers subsets:
>> "growable&
f dynvector-grow!, doing the growth in a
loop rather then just the determination of the new size seems a bit
expensive:
(while (<= (dynvector-capacity dynvector) k)
(dynvector-grow! dynvector))
--
David Kastrup
Andy Wingo writes:
> You raise an interesting issue. But first, a nitpick :)
>
> On Sat 09 Jun 2012 14:32, David Kastrup writes:
>
>> Scheme hashtable
>
> To be very pedantic, there are no hashtables in R5RS Scheme. SRFI-69
> and R6RS specify them (in different way
Daniel Hartwig writes:
> On 11 June 2012 12:37, David Kastrup wrote:
>> What is a vlist?
>
> vlist is a data type introduced around guile 2.0. You will find it
> documented in the Guile Reference under Compound Data Types.
>
> They are growable and provide vector-like
Daniel Hartwig writes:
> On 9 June 2012 20:32, David Kastrup wrote:
>>
>> Hi,
>>
>> the main data structure of Lua is a "table", an associative array, and a
>> table t has a continguous numerically addressed part from 1..#t, with
>> all othe
Krister Svanlund writes:
> On Sat, Jun 9, 2012 at 2:32 PM, David Kastrup wrote:
>
>
> One principal distinguishing feature, like with a Scheme
> hashtable, is the ability to grow on-demand.
>
> Scheme/Guile vectors are fixed size.
>
> It is a bit
would seem like a reasonably useful idea. After
all, there already _is_ such a mechanism underlying hash tables so it
seems somewhat peculiar not to have it available for vectors as well.
Suggestions?
--
David Kastrup
rguments both in favor and against separate binary/textual ports.
The question binary/textual concerns ports connected to a file. String
ports and Scheme ports should be _transparent_: input and output
identical. They are used for connecting character streams within Scheme
and should not tamper with them.
--
David Kastrup
hout
change.
Things are complicated enough talking to the outside. There is no point
in Guile being confused even when talking to itself.
--
David Kastrup
l...@gnu.org (Ludovic Courtès) writes:
> Hi,
>
> David Kastrup skribis:
>
>> Shouldn't strings be in "internal encoding" anyway? The whole point of
>> a string is to be an array of characters. Not an array of arbitrarily
>> encoded bytes.
>
>
oint of
a string is to be an array of characters. Not an array of arbitrarily
encoded bytes.
--
David Kastrup
other representation better suited to
compile into code for a certain amount of registers. Of course, the
threshold to picking actual registers of the available processor and
compiling native code is then not all too large.
--
David Kastrup
later the owner says "You took the halter! I did not sell the
halter!" that's a worse situation to be in rather than if he handed you
the horse including halter, even though the halter is not in the
contract.
Frankly, in the given situation I should be rather surprised if there
was potential for misunderstandings. It does look like both the intent
to contribute as well as the compass of the contribution are quite
well-understood.
--
David Kastrup
m checking in the changes or otherwise contributing
them in a manner making clear that the contribution is intentional.
Matching copyright headers are obviously a good indicator for that.
--
David Kastrup
will be glad to subscribe.
>
> Yes, of course they can. I think at least 95%
> of mailing lists these days work the same way
> to avoid spam.
If postings will never get accepted anyway, they should be rejected
instead of being silently discarded. An unannounced "mostly inactive
moderator" is rather impolite.
--
David Kastrup
Noah Lavine writes:
>> On Sat, May 5, 2012 at 12:42 PM, David Kastrup wrote:
>>> Noah Lavine writes:
>>>
>>>> It appears to me (anecdotally) that most of the build time is spent
>>>> compiling Scheme code, rather than C code.
>>>>
he
> portion of compile-time where the interpreter is running the compiler.
Bootstrap hell. If the "copy of Guile already around" happens to
produce different code, you have lots of fun ahead.
--
David Kastrup
d mutable needs to
>> be synchronized. I think this is reasonable. What do you think?
>
> I agree.
I just reread what I replied, and it was probably hard to detect the
implicit "I too" between the lines of the diatribe.
--
David Kastrup
ized well. The more assumptions an optimizer is allowed to make by
default, the better it can do its work. _Without_ special help by the
programmer. And if we wanted to rely on special help by the programmer,
it would be more straightforward if we let the programmer write the
assembly code rath
l...@gnu.org (Ludovic Courtès) writes:
> Hi David,
>
> Sorry for the late reply.
>
> David Kastrup skribis:
>
>> Previous attempts have mostly exploded around the problem that we have
>> something like
>>
>> (for-each ly:load init-scheme-files)
>>
ck, by the
time you are interested in getting to work on LilyPond again, this rock
of Sisyphos will already be on the other side, making room for more
rewarding things.
All the best
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>>> In the long run, I think this is probably your best way forward, but
>>> admittedly it would require more work to make this transition.
>>
>> The main problem is that it requires such a large reorganisation
Mark H Weaver writes:
> David Kastrup writes:
>
>> How is this supposed to work for compiling and installing a package?
>> Basically,
>>
>> make all
>> sudo make install
>>
>> The usual case will be that the user calling lilypond will not have
; usually does a good job but sometimes needs help. In this case it
> helped my benchmark by a percent or so without increasing code size.
With your compiler, the current compiler version, and on a particular
platform.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> Excellent! As long as you load everything in the right order, such that
>>> macros are defined before they are used, I don't see why there should be
>>> an
Mark H Weaver writes:
> Hello all,
>
> I occasionally talk about my large Guile TODO list, and sometimes people
> say that I should put it somewhere public. Okay, here it is (not
> including my ticked messages in Gnus).
Were you planning to do anything on the seventh day?
--
David Kastrup
for newbies especially came from Python of
> C.
That's like thinking the easiest path for a Franch-speaking newbie to
learn English is to start by learning Latin.
You'll find that kind of opinion expressed mostly by people fascinated
with Latin rather than English.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> David Kastrup writes:
>>>
>>>> with the stable release 2.16 of LilyPond looming around the corner, it
>>>> will become imminent soon to think about s
Mark H Weaver writes:
> David Kastrup writes:
>
>> with the stable release 2.16 of LilyPond looming around the corner, it
>> will become imminent soon to think about supporting Guile 2.0.
>>
>> Previous attempts have mostly exploded around the problem that we hav
2 era, and if we could tackle design or
maldesign questions mostly independently and in bite-sized chunks rather
than humongous patches moving material around, this would help a lot in
getting Guilev2 support on track.
Suggestions?
--
David Kastrup
a () (proc (lambda xs (throw key xs
> (lambda (key xs) (apply values xs)))
>
> (define call/ec call-with-escape-continuation)
Given the constraints of current guile-1 and guile-2, I doubt that there
is much to take away anymore from this solution.
Thanks
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> Andy Wingo writes:
>>
>>> On Sun 04 Mar 2012 13:01, David Kastrup writes:
>>>
>>>> The global symbol space is a different identity space than heap
>>>> equality, and it never gets
Andy Wingo writes:
> Hi David,
>
> On Sun 04 Mar 2012 13:01, David Kastrup writes:
>
>> The global symbol space is a different identity space than heap
>> equality, and it never gets garbage collected: the lifetime of a
>> gensym is eternal.
>
> This is not
Andy Wingo writes:
> On Fri 02 Mar 2012 02:35, David Kastrup writes:
>
>> Sure, but things like gensym and make-prompt-tag (and (list '()) for
>> creating an eq?-unique object) are artificial hygiene coming at a cost
>> in symbol table and symbol generation time rat
ames, like prompts, undoes the
> hygiene that Scheme is supposed to have. But the only solution I can
> think of is pretty messy.
Yup. call-with-single-continuation would make best sense as a primitive
for building other stuff, not the other way round.
--
David Kastrup
ure
mode when you disobey the "single" contract is an uncaught exception
with a weird symbol.
--
David Kastrup
Noah Lavine writes:
> On Thu, Mar 1, 2012 at 7:00 PM, David Kastrup wrote:
>>
>> Hi,
>>
>> I am just meddling around with coding and have come up with the
>> following:
>>
>> (define-public (find-child music predicate)
>> "Find the
e continuation after it has already returned.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>>> Scheme has a very useful property which your proposed syntax would
>>> destroy: any valid expression can be substituted for any other valid
>>> expression, and the result has the same meaning except for
Mark H Weaver writes:
> David Kastrup writes:
>>
>> A list in dotted tail position is evaluated via (map ... eval) rather
>> than (eval ...). I don't see much of a problem with that.
>
> No, it's worse than that. I think you failed to understand my point
David Kastrup writes:
> Mark H Weaver writes:
>
>> David Kastrup writes:
>>> I guess my "real" problem is that I'd like to do call wrapping by writing
>>>
>>> (lambda ( . x) (fun . x))
>>>
>>> instead of having to
Mark H Weaver writes:
> David Kastrup writes:
>> I guess my "real" problem is that I'd like to do call wrapping by writing
>>
>> (lambda ( . x) (fun . x))
>>
>> instead of having to write
>>
>> (lambda ( . x) (apply fun x))
>>
ad of having to write
(lambda ( . x) (apply fun x))
I assume eval is not supposed to try dealing with dotted lists?
--
David Kastrup
David Kastrup writes:
> David Kastrup writes:
>
>> Noah Lavine writes:
>>
>>> Hello,
>>>
>>> I've been working on a patch to add a new sort of optimization to
>>> peval, and I think it's almost ready. It's based on som
David Kastrup writes:
> Noah Lavine writes:
>
>> Hello,
>>
>> I've been working on a patch to add a new sort of optimization to
>> peval, and I think it's almost ready. It's based on some of the ideas
>> in "Environment Analysis of High
#t)
I have a hard time imagining this optimization to be useful for any code
occuring in practice. Can you suggest an example that would make more
sense than demonstrating that the optimization works? Is this supposed
to help with automatically generated code like macros?
--
David Kastrup
n-1 test cases.
Differing from the standard would be asking for even more trouble. I
have no idea what sense declaring § as punctuation makes (it is not used
in that manner), but at least for ¶, there is some motivation.
--
David Kastrup
Mike Gran writes:
> You could try having EMACS re-indent the whole buffer to see if you
> slipped a paren.
What's wrong with M-x check-parens RET ?
--
David Kastrup
(string #\m))
Dingdingding. That sounds to me like I am not the only person of the
opinion that (eq? (string) (string)) is a standard-compliant
implementation choice. I know this was a different discussion
altogether but thought it might be worth pointing out.
--
David Kastrup
of
things. I don't have much of a clue about the other differences. But
this one _really_ comes at a dear price in its implications.
--
David Kastrup
heavy-hitting component, that is a
definite plus.
--
David Kastrup
Mark H Weaver writes:
> Remember, (current-module) is a compile-time concept, not a run-time
> concept.
Then current-module should probably be a macro, not a function. In
which case the tail call problem would take care of itself.
--
David Kastrup
s, at least not in 2.0.
> Bummer.
It just occured to me that the _only_ way of getting and setting
variables under a computed name (apart from using macros) is using
(module-set! (current-module) (compute a symbol))
since symbol-set! apparently has been deprecated.
Not sure what the implication
andom sequence, but if there
happens to be a problem at any time, it becomes much easier to diagnose.
--
David Kastrup
ength. Of course, if the subsequences _do_ overlap, you tend to
get colliding sequences instead of just single outliers.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>
>> Mark H Weaver writes:
>>
>>> Andy Wingo writes:
>>>
>>>> Sorry for asking a stupid question, but why is it that we want the
>>>> gensym counter to be thread-local? Just to avoid th
ady designed to avoid collisions between multiple _sessions_
> without coordination. So why bother with the lock?
To avoid both threads reading the same seed value before generating the
same number? I have not looked at the code, but that could be a reason
for serializing.
--
David Kastrup
user meddles
with the value of current-module other than just calling it, he is going
to be in for surprises.
--
David Kastrup
ll-with-current-continuation? "a little too crazy" is not a
criterion. "Too complex to work or or with" would be. Those are
related, but not necessarily the same.
--
David Kastrup
Mark H Weaver writes:
> David Kastrup writes:
>> Well, deciding to use my guile checkout not just for reference, I tried
>> ./autogen.sh, ./configure and make on master.
>
> For now, it's best to stay on the "stable-2.0" branch.
> That's our cu
Mark H Weaver writes:
> David Kastrup writes:
>
>> (define current-module
>> (let ((top-level (the-environment)))
>> (lambda () (eval '(the-environment) top-level
>
> Some more notes about the above code (changing `eval' ==> `local-eval
Marijn writes:
> On 13-01-12 17:39, Mark H Weaver wrote:
>> David Kastrup writes:
>>
>> However, my mind is not set in stone on this. Does anyone else
>> here agree with David? Should we defend the legitimacy of this
>> optimization, and ask the R7RS
evel variable; it would produce an error.
I am not saying that the actual code would need to work. It was more
intended as a show of equivalences.
--
David Kastrup
David Kastrup writes:
> In the light of local-eval evaluating a _form_ rather than a _body_
> (stupid of me to forget), and seeing the weird semantics of begin, I
> agree that an implicit (let () ...) wrapper for a single form does not
> really appear to add significant gains.
Mark H Weaver writes:
> David Kastrup writes:
>
>>> You are suggesting that we wrap the expression within a (let () ...),
>>> for the dubious benefit of allowing you to wrap the local forms in
>>> (begin ...) instead of (let () ...).
>>
>>
Mark H Weaver writes:
> David Kastrup writes:
>
>> What is confusing here? "Obviously, definitions made in the scope of
>> local-eval can't retroactively affect the environment where
>> the-environment was called." And now instead of continuing with t
1 - 100 of 210 matches
Mail list logo
