Re: [racket-dev] Generics and data structures
On 2012-05-09 18:02:04 -0600, Ryan Culpepper wrote: > See the 'supers' argument to 'make-struct-type-property'. > > Create 'real-prop:sequence' that takes a vector (compatible with > generics library). > > Define 'prop:sequence' as a backwards compatibility property that > takes an old-style implementation and transforms it into the > new-style implementation vector. 'prop:dict/contract' plays the same > trick, IIRC. Thanks! That seems like it will work nicely. It turns out that over dinner, after sending out the e-mail, Vincent and I came up with a similar solution. It's nice to know that this pattern is already supported by struct properties. It should even work with sequences, which we thought were difficult. You just need to create a vector of methods that just apply the normal sequence functions to the sequence created by `make-do-sequence`. We will try to implement this tomorrow. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics and data structures
On 2012-05-09 19:01:10 -0400, Neil Van Dyke wrote: > When you say "dictionaries, sequences,", are you including the > Racket types hash, vector, and list? Yes, the changes we made to racket/dict will work with hashes, vectors, and a-lists in the same way it did before. The only difference is when you define your own dictionaries using struct properties. > If so, would current performance for those Racket types be affected? > And does this have implications for what optimizations the compiler > would likely make in the foreseeable future? There should not be any performance impact for the base types. The racket/dict functions will not dispatch to generic methods unless the given object does not match any of the supported base types. Cheers, Asumu _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] emscripten? (was: Re: Using clang to Build Racket on Mac OS X)
Two hours ago, John Clements wrote: > > On May 9, 2012, at 2:47 PM, Michael W wrote: > > Of course this is much more work than just getting racket to build > > with Clang, but I wonder what the implications of a successful > > port could be. > > I believe this would be hard, and I know that others have asked > about this part before (I think Eli's response compared it to > "Racket swallowing gcc" when compared to using Gnu lightning). Not just asked -- we had an experiment with an LLVM-based assembly language. In the end, the main problem it had was indeed that to use this for JIT, LLVM would need to be completely included -- and that's a huge overhead. (The LLVM library was a little bigger than the mzscheme excutable at the time, IIRC.) -- ((lambda (x) (x x)) (lambda (x) (x x))) Eli Barzilay: http://barzilay.org/ Maze is Life! _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics and data structures
On 05/09/2012 04:13 PM, Asumu Takikawa wrote: Hi all, Racket currently provides several generic extensible data structure APIs such as dictionaries, sequences, streams, and so on. Unfortunately, each data structure currently has its own extension API, but no consistent convention exists: some APIs use lists of methods, some use vectors, etc. Furthermore, these APIs are usually rather low-level (e.g., dependent on ordering in the method table). Vincent and I have been working on a unified user-friendly extension interface based on unstable/generics by Eli and Jay (which we have moved to collects/generics). We have a prototype that implements our proposed interface for prop:dict and prop:ordered-dict with complete backwards compatibility with their respective extension APIs. That is, we have modified racket/dict and data/ordered-dict to use generics. The code is on github here: https://github.com/takikawa/racket/tree/generics We would like to get feedback on what we have so far and if nobody has any objections, we would like to push what we currently have to master. Ideally, we would provide similar interfaces for the other generic APIs in the tree, such as streams and sequences. However, the existing APIs rely on different representations for method tables from the one used by unstable/generics, specifically a vector of methods. This makes backwards compatibility complicated and we're not sure how to proceed. Some specific examples: * `prop:sequence`: Instead of a vector of methods, this struct property takes a procedure which takes a struct instance and produces a sequence (not a vector of methods). * `prop:equal+hash-code` uses a list of methods instead of a vector. * `prop:dict/contract` is given both a method vector and a vector of sub-contracts that are used to assemble the method contracts. The generics library currently uses a single vector. To apply our proposal to these cases, we could change these struct properties to use the generics library's preferred representation. However, this would break backwards compatibility with code that currently uses these struct properties, which makes this a non-starter. Does anyone have any suggestions on how to proceed without breaking backwards compatibility? See the 'supers' argument to 'make-struct-type-property'. Create 'real-prop:sequence' that takes a vector (compatible with generics library). Define 'prop:sequence' as a backwards compatibility property that takes an old-style implementation and transforms it into the new-style implementation vector. 'prop:dict/contract' plays the same trick, IIRC. Ryan Streams present a slightly different issue. `prop:stream` already represents its methods with a vector. However, it is used heavily in the implementation of racket/base, so we cannot re-write it to use generics (which depends on racket/base). Assuming we can't restructure racket/private/for to break the circular dependency, another solution would be to allow the generics library to create a generic interface attached to an existing struct property[1], given the struct property accessor. That would require exposing the struct property accessor from the internals of racket/base. Would that be an acceptable solution? [1]: currently, the generics library needs to be the one defining the struct property. Any thoughts or suggestions? Cheers, Asumu& Vincent _ Racket Developers list: http://lists.racket-lang.org/dev _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] emscripten? (was: Re: Using clang to Build Racket on Mac OS X)
On May 9, 2012, at 2:47 PM, Michael W wrote: > That's an interesting thought. > > Racket currently uses GNU Lightning as its JIT, correct? What if > it used LLVM instead? > http://en.wikipedia.org/wiki/LLVM#Description > > Of course this is much more work than just getting racket to > build with Clang, but I wonder what the implications of a > successful port could be. I believe this would be hard, and I know that others have asked about this part before (I think Eli's response compared it to "Racket swallowing gcc" when compared to using Gnu lightning). However, running racket under Emscripten might potentially be possible without the JIT entirely. Anyhow, it looks like Tony Garnock-Jones' response contains the current "state of the art". John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] Generics and data structures
Asumu Takikawa wrote at 05/09/2012 06:13 PM: Any thoughts or suggestions? When you say "dictionaries, sequences,", are you including the Racket types hash, vector, and list? If so, would current performance for those Racket types be affected? And does this have implications for what optimizations the compiler would likely make in the foreseeable future? Thanks, Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] Generics and data structures
Hi all, Racket currently provides several generic extensible data structure APIs such as dictionaries, sequences, streams, and so on. Unfortunately, each data structure currently has its own extension API, but no consistent convention exists: some APIs use lists of methods, some use vectors, etc. Furthermore, these APIs are usually rather low-level (e.g., dependent on ordering in the method table). Vincent and I have been working on a unified user-friendly extension interface based on unstable/generics by Eli and Jay (which we have moved to collects/generics). We have a prototype that implements our proposed interface for prop:dict and prop:ordered-dict with complete backwards compatibility with their respective extension APIs. That is, we have modified racket/dict and data/ordered-dict to use generics. The code is on github here: https://github.com/takikawa/racket/tree/generics We would like to get feedback on what we have so far and if nobody has any objections, we would like to push what we currently have to master. Ideally, we would provide similar interfaces for the other generic APIs in the tree, such as streams and sequences. However, the existing APIs rely on different representations for method tables from the one used by unstable/generics, specifically a vector of methods. This makes backwards compatibility complicated and we're not sure how to proceed. Some specific examples: * `prop:sequence`: Instead of a vector of methods, this struct property takes a procedure which takes a struct instance and produces a sequence (not a vector of methods). * `prop:equal+hash-code` uses a list of methods instead of a vector. * `prop:dict/contract` is given both a method vector and a vector of sub-contracts that are used to assemble the method contracts. The generics library currently uses a single vector. To apply our proposal to these cases, we could change these struct properties to use the generics library's preferred representation. However, this would break backwards compatibility with code that currently uses these struct properties, which makes this a non-starter. Does anyone have any suggestions on how to proceed without breaking backwards compatibility? Streams present a slightly different issue. `prop:stream` already represents its methods with a vector. However, it is used heavily in the implementation of racket/base, so we cannot re-write it to use generics (which depends on racket/base). Assuming we can't restructure racket/private/for to break the circular dependency, another solution would be to allow the generics library to create a generic interface attached to an existing struct property[1], given the struct property accessor. That would require exposing the struct property accessor from the internals of racket/base. Would that be an acceptable solution? [1]: currently, the generics library needs to be the one defining the struct property. Any thoughts or suggestions? Cheers, Asumu & Vincent _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] emscripten? (was: Re: Using clang to Build Racket on Mac OS X)
That's an interesting thought. Racket currently uses GNU Lightning as its JIT, correct? What if it used LLVM instead? http://en.wikipedia.org/wiki/LLVM#Description Of course this is much more work than just getting racket to build with Clang, but I wonder what the implications of a successful port could be. 33 minutes ago, John Clements wrote: > > On Sep 10, 2011, at 6:33 PM, Will M. Farr wrote: > > > Thanks, Matthew! It seems to build OK now. > > > > I missed the implication of this, the first time around. > > If I'm reading this correctly, it means that clang can compile racket, which > is awfully close to being able to run Racket using an LLVM model such as > emscripten, and making it run in the browser. > > In particular, I would expect the JIT to be totally broken, and that there > would be a lot of painful parts related to linking to standard libraries, but > the resulting program could actually do client-side compilation in a web > browser, right? > > John -- Take it easy, _mike _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] emscripten?
On 05/09/2012 05:09 PM, John Clements wrote: In particular, I would expect the JIT to be totally broken, and that there would be a lot of painful parts related to linking to standard libraries, but the resulting program could actually do client-side compilation in a web browser, right? Yep. My initial experiments in this direction suggested that getting it to compile and run with emscripten was Difficult. I didn't put very much effort into it though. I don't remember exactly where I got stuck, but the attached is a build script I was using to try to iterate closer and closer to an appropriately-configured and -compiled Racket. Regards, Tony #!/bin/sh # First, mkdir .../racket/src/build, then from there, run this script. EMSCRIPTEN_PATH=~/src/emscripten-racket/emscripten/tools EMMAKEN_JUST_CONFIGURE=1 \ RANLIB=$EMSCRIPTEN_PATH/emmaken.py \ AR=$EMSCRIPTEN_PATH/emmaken.py \ CXX=$EMSCRIPTEN_PATH/emmakenxx.py \ CC=$EMSCRIPTEN_PATH/emmaken.py \ ../configure \ --host=i686-pc-linux-gnu \ --target=i686-pc-linux-gnu \ --enable-racket="`which racket`" \ --disable-gracket \ --disable-plot \ --disable-jit \ --disable-foreign \ --disable-pthread \ --disable-futures \ --disable-places sed -i bak -e 's:/\* #undef MZ_CAS_AVAILABLE \*/:#define MZ_CAS_AVAILABLE 1:' racket/mzconfig.h echo '#define NO_TCP_SUPPORT 1' >> racket/mzconfig.h echo '#define SCHEME_PLATFORM_LIBRARY_SUBPATH "js-emscripten-0.0"' > racket/src/schsys.h touch racket/starter _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] emscripten? (was: Re: Using clang to Build Racket on Mac OS X)
On Sep 10, 2011, at 6:33 PM, Will M. Farr wrote: > Thanks, Matthew! It seems to build OK now. > I missed the implication of this, the first time around. If I'm reading this correctly, it means that clang can compile racket, which is awfully close to being able to run Racket using an LLVM model such as emscripten, and making it run in the browser. In particular, I would expect the JIT to be totally broken, and that there would be a lot of painful parts related to linking to standard libraries, but the resulting program could actually do client-side compilation in a web browser, right? John smime.p7s Description: S/MIME cryptographic signature _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] [plt] Push #24674: master branch updated
Ryan,
thanks for writing this library. I completely understand why you wanted it.
I have used the name ++ in the past.
I find the many options a bit confusing, so I do understand some of Eli's
concerns. But it is always more productive to start from something concrete to
discuss than to discuss non-existent vaporware. [At the same time, as I am
reading the documentation, I understand why you want the options.]
-- Matthias
On May 9, 2012, at 1:08 AM, Eli Barzilay wrote:
> An hour ago, Ryan Culpepper wrote:
>> On 05/08/2012 08:29 PM, Eli Barzilay wrote:
>>> 5 hours ago, ry...@racket-lang.org wrote:
745607a Ryan Culpepper 2012-04-18 14:58
:
| added unstable/cat
>>>
>>> Why?
>
> This was too implicit -- there's a rationale missing from either the
> source or the documentation. Probably some of your explanation below
> should be added to either/both places.
>
>
>>> and not even for a good reason since `cat' is a pretty bad name
>>> for something that is supposed to be used to print stuff.
>>> "Consider as text" is not really helping in making the name any
>>> better, and it's worse when it gets to obscure names like `catne'
>>> and `catnp'.
>>
>> 'cat' is memorable ("hey, like the unix command"!) and it's short.
>
> I should have mentioned the unix command as the main thing that makes
> this confusing... (When I first read the commit on my phone, all I
> say was "cat" and some stuff about printing -- you can see how I
> interpreted this.)
>
>> The others names are reasonable variations on the central theme and
>> also short. I admit 'catnp' and 'catne' are stretching it; maybe we
>> can find better names for them. But I wanted to have a concrete
>> starting point for discussion.
>>
>> "Consider as text", BTW, is a pure Backronym.
>
> (Even though it's obviously retrofitted, I think that removing it
> would help...)
>
>
>> My main idea is that Racket lacks---and needs---a quick way of
>> turning values into text and conCATenating them. Java has '+', PHP
>> has '.', SQL has '||', and so on. You can make good arguments that
>> none of those is well-named, but once it's The Way, that doesn't
>> matter at all.
>
> (This is the missing rationale, BTW. (One of the things that puzzled
> me was why make it take any number of arguments... so I was way off.))
>
> If this is the intention, then (I'm guessing) you started with just a
> short name for the awfully-long-for-its-utility `string-append', and
> then added a bunch of configurations, right?
>
> If so, then I think that using parameters works better for two
> reasons: it makes the core `cat' function be more like `string-append'
> which just "happens" to also accept any non-string values. The other
> reason is that the huge advantage of a short name is kind of lost with
> the very verbose keywords.
>
>
>>> But there's also the issue of how it's used to print things: IIUC,
>>> this is intended to be used only for converting values to strings,
>>> so there's a good point in having this kind of thing if it's part
>>> of a proper library for formatted output. And there's obviously a
>>> desperate need for something that does that.
>>>
>>> So, more concrete suggestions:
>>>
>>> 1. Rename all of the `cat*'s (unless they end up being used
>>>internally) to some better name.
>>
>> I'm open to suggestions, as long as they're short. (I considered
>> stealing the name 'echo' from you instead of 'cat' from srfi/54, but
>> it's not particularly better and it's a letter longer.)
>
> Yeah, given the rationale that you've now filled in, `echo' is a bad
> name since it implies doing the output. (It's more like `echos' from
> swindle, a name that I never liked but couldn't find anything better.)
> So for this purpose, `cat' makes a bit more sense, but the unix thing
> is still very strongly in the way, IMO, as well as the fact that it
> does more than just concatenate strings.
>
> So, given that a proper full name for this would be something like
> `string-coerce/append', how about a very short `s+'? (This goes
> directly in the direction of this thing having the very short names
> you mention above in other languages.) A slightly longer variant is
> `str+' -- I think that it makes it very clear that this is doing the
> coerce+concatenate (`s+' too, more weakly).
>
>
>>> 2. Implement a proper library formatting library that uses this
>>> for basic values.
>>> 2a. This might mean that this code is used only indirectly, hence
>>> the comment in #1.
>>> 2b. It should also be extensible.
>>
>> More formatting capabilities would be nice, but I don't want to
>> widen the scope of this discussion. I know I've wanted 'cat' and
>> 'catn' many times before, and I'm pretty sure I want 'catp'. Beyond
>> that it's design by speculation (for me, anyway)---and possibly the
>> numeric formatting needs to be scaled back some anyway.
>
> I think that given the above, less formatting options would be
> good... How
[racket-dev] Submodules and internal #langs
With the submodule support, the following is a legal program: #lang racket #lang racket Is this intentional? _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A few suggestions on indentation and DrRacket graphical syntax
Laurent wrote at 05/09/2012 06:55 AM: * Line-width In GEdit, there's an option to show a thin vertical line at 80 chars (modifiable number). I find it of great help to avoid writing long lines, which I tend to not do otherwise or often (inconveniently) look at the column number to see where I am. Such a vertical line might be a good idea for DrRacket. This has come up before. I doubt anyone would complain if someone implemented this and made it optional. Some people (including me) would very much like it. I think that the least-controversial default preference settings would be 80 characters, light gray, and disabled. Neil V. _ Racket Developers list: http://lists.racket-lang.org/dev
Re: [racket-dev] A few suggestions on indentation and DrRacket graphical syntax
* Line-width In GEdit, there's an option to show a thin vertical line at 80 chars (modifiable number). I find it of great help to avoid writing long lines, which I tend to not do otherwise or often (inconveniently) look at the column number to see where I am. Such a vertical line might be a good idea for DrRacket. Laurent On Wed, May 9, 2012 at 10:18 AM, Laurent wrote: > Hi, > > Reading the style guide for Racket, I came up with a few debatable > suggestions. > ( http://www.ccs.neu.edu/home/matthias/Style/style/Textual_Matters.html ) > > Apologies if this has already been longly debated. > > * Indentation: adding new indentations constructs to DrRacket > > From the guide: "Caveat 1: Until language specifications come with fixed > indentation rules, we need to use the default settings of DrRacket’s > indentation for this rule to make sense." > > Maybe a special submodule like drracket-indentation with declarations like: > (module+ drracket-indentation > (like-lambda my-lambda my-function ) > (like-begin my-begin ) > ) > could be useful for user-specific indentation. > > As a submodule, Racket can read&load it only at appropriate moments. > When indenting the file, DrRacket could first load the > drracket-indentation module of the file to know how to indent it. > > One could then create a whole language with its own indentation rules. > It would also be easier to add good indentations for for/fold and others. > > * Graphical syntax > > "When we figure out how to save such files in an editor-compatible way, we > may relax this constraint." > > Maybe the graphical job should be done by DrRacket only, and the file > itself should remain textual. > For example, special forms can be turned into graphics by DrRacket when > reading the file: > You write: > (image "balloon.jpg") > and DrRacket turns this into the image (if the option is turned on > somewhere in the preferences). > Of course, the s-exp should still be editable, for example with a > contextual menu that proposes "Back to s-exp" or "Turn me into graphical > form". > > Or even surround it with a form like (drracket-show-image (image > "balloon.jpg") 48 48) for better rendering (that form obviously expands > into (image "balloon.jpg") for Racket). > > > Same for code folding, 2 options: > - either surround s-exps with a (drracket-fold ) form to inform > DrRacket to fold the s-exp, and Racket to just do what's inside the form, > (but that "pollutes" the file for external editors, though an `unfold-file' > function should not be too difficult to do) > - or do not save folding into the file (loading a file displays it > unfolded, then it can be folded as desired). This might be problematic with > DrSync though, unless the file is not reverted if it has not changed. > > > But I agree all this would require some work, certainly. > > Laurent > _ Racket Developers list: http://lists.racket-lang.org/dev
[racket-dev] A few suggestions on indentation and DrRacket graphical syntax
Hi, Reading the style guide for Racket, I came up with a few debatable suggestions. ( http://www.ccs.neu.edu/home/matthias/Style/style/Textual_Matters.html ) Apologies if this has already been longly debated. * Indentation: adding new indentations constructs to DrRacket >From the guide: "Caveat 1: Until language specifications come with fixed indentation rules, we need to use the default settings of DrRacket’s indentation for this rule to make sense." Maybe a special submodule like drracket-indentation with declarations like: (module+ drracket-indentation (like-lambda my-lambda my-function ) (like-begin my-begin ) ) could be useful for user-specific indentation. As a submodule, Racket can read&load it only at appropriate moments. When indenting the file, DrRacket could first load the drracket-indentation module of the file to know how to indent it. One could then create a whole language with its own indentation rules. It would also be easier to add good indentations for for/fold and others. * Graphical syntax "When we figure out how to save such files in an editor-compatible way, we may relax this constraint." Maybe the graphical job should be done by DrRacket only, and the file itself should remain textual. For example, special forms can be turned into graphics by DrRacket when reading the file: You write: (image "balloon.jpg") and DrRacket turns this into the image (if the option is turned on somewhere in the preferences). Of course, the s-exp should still be editable, for example with a contextual menu that proposes "Back to s-exp" or "Turn me into graphical form". Or even surround it with a form like (drracket-show-image (image "balloon.jpg") 48 48) for better rendering (that form obviously expands into (image "balloon.jpg") for Racket). Same for code folding, 2 options: - either surround s-exps with a (drracket-fold ) form to inform DrRacket to fold the s-exp, and Racket to just do what's inside the form, (but that "pollutes" the file for external editors, though an `unfold-file' function should not be too difficult to do) - or do not save folding into the file (loading a file displays it unfolded, then it can be folded as desired). This might be problematic with DrSync though, unless the file is not reverted if it has not changed. But I agree all this would require some work, certainly. Laurent _ Racket Developers list: http://lists.racket-lang.org/dev
