On 20 February 2013 03:21, Mark H Weaver wrote:
> (define (func x)
> (let ((r (my-special-function x)))
> (+ x 2 r)))
>
> Here, (my-special-function x) must be evaluated before evaluating '+'.
> Evaluating '+' means to fetch the value stored in the location denoted
> by '+'. Therefore, if '
Thanks, Mark. This all sounds very sensible to me, and I will
continue working on the scmutils port while waiting for your patch.
On Fri, Feb 22, 2013 at 3:52 AM, Mark H Weaver wrote:
> Mikael Djurfeldt writes:
>> The API you suggest would compose much easier, but to me it feels like
>> just an
Mikael Djurfeldt skribis:
> Thanks, Mark. This all sounds very sensible to me, and I will
> continue working on the scmutils port while waiting for your patch.
BTW, in the meantime you can always use Guile-Reader, which supports
DSSSL keyword syntax.
Ludo’.
Mark H Weaver skribis:
> Ludovic Courtès writes:
>> This is basically DSSSL keyword syntax. What about adding a new keyword
>> style to read.c? Sounds like the easiest solution for this particular
>> problem.
>
> This is a tempting solution, but I see a problem with this proposal:
> We'd have
Hi!
stefan.ita...@gmail.com skribis:
> I have spend quite a lot of work porting racket code to guile
> e.g. syntax-parse and the code for contracts, as a spinoff I have
> done several other parts as well e.g.
Would you like to come up with individual commits to add those to Guile?
Ludo’.
Thanks for posting it! It's always nice to see people writing Guile
programs.
You might also be interested in the guile-user list (guile-u...@gnu.org).
That's usually where people talk about building things with Guile, and they
might be interested in this. This list (guile-devel) is mostly about t
On Friday, February 22, 2013 04:56:24 PM Ludovic Courtès wrote:
> Hi!
>
> stefan.ita...@gmail.com skribis:
> > I have spend quite a lot of work porting racket code to guile
> > e.g. syntax-parse and the code for contracts, as a spinoff I have
> > done several other parts as well e.g.
>
> Would yo
Hi Daniel,
thanks for your answer, but where i understand a strict name space will lead to
merging the generic(s) from/with the ones that comes from the modules you are
importing [as opposed to a general 'goops' name space], i disagree that this
would be
a 'pre limitation' that provides a proper
On 23 February 2013 07:11, David Pirotte wrote:
> Hi Daniel,
>
> thanks for your answer, but where i understand a strict name space will lead
> to
> merging the generic(s) from/with the ones that comes from the modules you are
> importing [as opposed to a general 'goops' name space], i disagree t
On 22 February 2013 04:59, wrote:
> I also suggest that for people writing compatability code that we have
> a standard namespace for this. Let me suggest
>
> (compat name-of-scheme/lisp component ...)
> e.g.
> (compat racket match)
> (compat racket for)
> (compat racket struct)
>
> The idea is t
Daniel Hartwig writes:
> For those parts specific to racket, did you consider the (language
> racket ..) namespace, where an eventual language definition could be
> placed also?
That sounds somewhat misleading, since Racket is not really one
language. Yeah, there is #lang racket, but they have o
William ML Leslie writes:
> On 20 February 2013 03:21, Mark H Weaver wrote:
>> (define (func x)
>> (let ((r (my-special-function x)))
>> (+ x 2 r)))
>>
>> Here, (my-special-function x) must be evaluated before evaluating '+'.
>> Evaluating '+' means to fetch the value stored in the locatio
12 matches
Mail list logo