Re: [racket-users] C level bit manipulation - Racket Manifesto

2018-08-14 Thread David Brown
I think Racket handles this pretty well. The rule it defines is that a module cannot directly mutate another module's top-level symbols. This means that if a module itself does not contain any mutations of a top-level function, that definition cannot be changed at runtime. Therefore, everyone ca

Re: [racket-users] C level bit manipulation - Racket Manifesto

2018-08-14 Thread Arthur Nunes-Harwitt
Hi, Racket seems to depricate redefinition of functions at run-time. Since Racket isn't Scheme, why not prevent that and get back that performance? -Arthur == Arthur Nunes-Harwitt Computer Science Department, Rochester Institute o

Re: [racket-users] C level bit manipulation - Racket Manifesto

2018-08-13 Thread George Neuner
On 8/13/2018 10:02 AM, 'Paulo Matos' via Racket Users wrote On 11/08/18 19:41, Sam Tobin-Hochstadt wrote: > There are basically two differences between the `unsafe-lsb` function > in Racket and the C one: > - the Racket calling convention vs the C calling convention > - the instruction used t

Re: [racket-users] C level bit manipulation - Racket Manifesto

2018-08-13 Thread 'Paulo Matos' via Racket Users
On 11/08/18 19:41, Sam Tobin-Hochstadt wrote: > There are basically two differences between the `unsafe-lsb` function > in Racket and the C one: > - the Racket calling convention vs the C calling convention > - the instruction used to perform the LSB calculation > > For a variety of reasons R

Re: [racket-users] C level bit manipulation - Racket Manifesto

2018-08-11 Thread Sam Tobin-Hochstadt
There are basically two differences between the `unsafe-lsb` function in Racket and the C one: - the Racket calling convention vs the C calling convention - the instruction used to perform the LSB calculation For a variety of reasons Racket's function calling convention is more heavyweight than