Re: [racket-users] Redex: macro expanding to a side-condition clause

Right, so I need a separate metafunction for each pattern I want to negate. On Mon, Oct 24, 2016 at 6:56 PM, Robby Findler wrote: > I am saying to write this: > > (define-metafunction L > [(not-thing pat) #false] > [(not-thing any) #true]) > > and then where you

Re: [racket-users] Redex: macro expanding to a side-condition clause

I am saying to write this: (define-metafunction L [(not-thing pat) #false] [(not-thing any) #true]) and then where you wrote: (where/not pat tm) write this: (where #true (not-thing pat)) On Mon, Oct 24, 2016 at 5:47 PM, Sam Caldwell wrote: >> In the meantime,

Re: [racket-users] Redex: macro expanding to a side-condition clause

> In the meantime, consider using a metafunction with an `else` clause. This would entail fixing the pattern, right? As in, I can write a metafunction deciding whether a term does not match a pattern, but I can't write a metafunction taking both the term and the pattern. I'm ok with failed

Re: [racket-users] Redex: macro expanding to a side-condition clause

Unfortunately, Redex's pattern language does not currently support `not`. It might be easy to add it, or maybe hard, or maybe impossible. Offhand, it seems probably possible to support in the unifier and impossible in the enumerator and not hard in the matcher. In the meantime, consider using a

[racket-users] Re: Error messages in DSL implementations

On Monday, October 24, 2016 at 6:25:07 AM UTC-7, Konrad Hinsen wrote: > > I can think of a few approaches, such as redefining > error-display-handler in the expanded code, but I suspect that others > have already found better solutions to this problem. I'd be grateful for > any pointers. > >

Re: [racket-users] unit testing syntax errors

See `convert-compile-time-error` and `convert-syntax-error` from the `syntax/macro-testing` library. I should fix the docs to say that the type of the exception can change, so they work best for testing the contents of the exception message. For examples, there are tests for invalid uses of

Re: [racket-users] unit testing syntax errors

Take a look at convert-compile-time-error and convert-syntax-error from syntax/macro-testing[1], which make it possible to defer syntax errors to runtime. The docs include examples for using them with rackunit’s check-exn form to make assertions about syntax errors. [1]:

[racket-users] unit testing syntax errors

Hi - Could someone point me to an example of using a test submodule and rackunit to verify a correctly raised syntax-error in the syntax phase? Here's an example of the kind of code I have: http://pasterack.org/pastes/82067 (Uncomment the last expression in the test submodule to see the

[racket-users] Redex: macro expanding to a side-condition clause

I have a Redex judgment that I would like to specify in terms of a *failed* pattern match. I can write this like so: [(side-condition ,(not (redex-match? L pat (term tm))) -- ...] which works, but I would rather just abbreviate this

Re: [racket-users] degenerate performance in syntax-parse

On Monday, October 24, 2016 at 2:07:16 PM UTC-7, Ryan Culpepper wrote: > > It might make sense for syntax-parse to offer something like Redex's > `variable-not-otherwise-mentioned`, which would behave like you > expected. I think it would have to be a baked-in special case, but it > might be

Re: [racket-users] FFI and C macros

Is https://docs.racket-lang.org/gir/index.html of any use in your context? /Jens Axel 2016-10-24 23:13 GMT+02:00 James James : > I am trying to use the libnice C library by way of FFI but a lot of the > libnice example C code is using macros. > > For example, G_OBJECT().

[racket-users] FFI and C macros

I am trying to use the libnice C library by way of FFI but a lot of the libnice example C code is using macros. For example, G_OBJECT(). See: https://developer.gnome.org/gobject/stable/gobject-The-Base-Object-Type.html#G-OBJECT:CAPS It's used in Example 1 here:

Re: [racket-users] degenerate performance in syntax-parse

On 10/24/2016 02:15 PM, Dan Liebgold wrote: On Sunday, October 23, 2016 at 1:14:56 PM UTC-7, Ryan Culpepper wrote: [...] 1. A term like `(a <- blend)` will match the first pattern and treat `blend` as a `remap:id`. If you don't want that to happen, there are two ways to prevent it. One is to

[racket-users] Test message - please ignore

Sorry for the burned electrons; my co-founder has been having some trouble sending to the list and I'm wondering if it's a general issue. -- You received this message because you are subscribed to the Google Groups "Racket Users" group. To unsubscribe from this group and stop receiving emails

Re: [racket-users] degenerate performance in syntax-parse

On Sunday, October 23, 2016 at 1:14:56 PM UTC-7, Ryan Culpepper wrote: > > > The easiest fix is to add the #:commit option to the `remap-entry` > syntax class. Then when `remap-entry` succeeds the first time, it throws > away the choice points it created, so the repeated pattern is never >

Re: [racket-users] Error messages in DSL implementations

> On Oct 24, 2016, at 9:58 AM, Matthias Felleisen > wrote: > > This is an interesting class of errors. As Dimitry says, you might > be able to leave behind enough source code info when you generate > that code, so that it looks like > > (define foo (if (empty? blah) (error

Re: [racket-users] Error messages in DSL implementations

> On Oct 24, 2016, at 11:00 AM, Konrad Hinsen > wrote: > > Hi Dmitry, > >> Is it compile-time or run-time errors? > > Mostly module-instantiation-time errors, which are closer to run-time errors. > > As a simple example, consider syntactically correct DSL code

Re: [racket-users] Error messages in DSL implementations

Is it compile-time or run-time errors? Mostly module-instantiation-time errors, which are closer to run-time errors. As a simple example, consider syntactically correct DSL code that expands to (define foo (first '())) The call to first raises an exception, which is displayed without

Re: [racket-users] Error messages in DSL implementations

Hi Dmitry, Is it compile-time or run-time errors? Mostly module-instantiation-time errors, which are closer to run-time errors. As a simple example, consider syntactically correct DSL code that expands to (define foo (first '())) The call to first raises an exception, which is

Re: [racket-users] help

Hi Masto, You have at least one obvious syntax error in that code, which you should probably fix before asking for help. Also, it sounds like you're asking for help with homework, which generally defeats the point. May I suggest that you take a real swing at it, then ask for more specific help?

Re: [racket-users] Error messages in DSL implementations

Konrad, Is it compile-time or run-time errors? Assuming compile-time, I would suggest an approach I took for a non-SEXP language: call raise-syntax-error in the (custom) compiler, which runs after parser and transforms syntax objects to other syntax objects. The third argument of

[racket-users] Error messages in DSL implementations

Hi everyone, I am working on a DSL embedded in Racket (for the curious, it's on GitHub: https://github.com/khinsen/leibniz) and as I am starting to use my DSL in practice, I wish my implementation had better error reporting. My DSL consists of a bunch of syntax transformers that expand to