Re: [racket-users] crash in nightly build

[Matthew Flatt]

At Thu, 15 Oct 2015 11:56:21 +0300, Dmitry Pavlov wrote:
> Oops, it just crashed again, 5+ hours of running.
> I will re-run in under gdb. There is no guarantee, though,
> that it will crash this time.
> 
> By the way, I input "handle SIGSEGV nostop noprint" into gdb prior
> to running, to get rid of gdb's complaints about Racket VM's way of
> doing things. Am I correct that this should not hide the actual crash?

Yes, that's correct.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Re: Formatting Function

[Taro Annual]

2015年10月13日火曜日 3時28分13秒 UTC+9 George Neuner:
> On Mon, 12 Oct 2015 12:28:56 -0400, Deren Dohoda
>  wrote:
> 
> >Probably racket/format is what you need to look at.
> >http://docs.racket-lang.org/reference/strings.html#%28mod-path._racket%2Fformat%29
> 
> 
> Or  SRFI 48:
> 
> http://docs.racket-lang.org/srfi/srfi-std/srfi-48.html
> 
> racket/format is more capable, but the SRFI fomat may be simpler to
> use if you are just looking for something like C printf().
> 
> George

Thank you, Daren.
Thank you, George.

I'm just busy this week and I'm not willing to ignore.

Taro

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Laurent]

On Thu, Oct 15, 2015 at 3:25 PM, Deren Dohoda 
wrote:

> I don't have a very strong opinion, it seems like convenient syntax, but
> half of what draws me to stick with lisps is the low amount of syntax.
> Pound-colon has a strong line noise quality to it which colons lack,  I
> admit. But they also have an explicit feel which colons lack.
>
In particular, they have a "reader syntax" feeling, as most things that
start with a pound in Racket. I initially didn't like them for keywords,
but now I'm feeling somewhat ok with them. Having two characters to prefix
a keyword argument is a lot though, especially when one uses them so much.

Laurent

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Deren Dohoda]

I don't have a very strong opinion, it seems like convenient syntax, but
half of what draws me to stick with lisps is the low amount of syntax.
Pound-colon has a strong line noise quality to it which colons lack,  I
admit. But they also have an explicit feel which colons lack.

Inclusion or exclusion of this will not really affect me though. I will
probably stick to pound-colon.

Deren

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Fortran (Was: [racket-users] racket users fight for their right to colon keywords)

[Neil Van Dyke]

Regarding Fortran, about 3 weeks ago, I looked into implementing a 
`#lang fortran77` or `#lang fortran90`.


Functionality-wise, it looks doable; speed-wise, not so great.  I have 
no further need for this, but it's an interesting practical/hobby 
project someone might want to pursue.


(For easy intermixing of Fortran and Racket code, there are boxing and 
marshalling inefficiencies, especially when you combine that with code 
that depends on behavior like shared mutations of very 
byte/word-layout-sensitive overlaying/sharing of dissimilar types on the 
same memory.  Though there do appear to be lots of optimization 
opportunities, when you can prove that some Fortran-specific language 
complications don't apply, to particular 
procedures/variables/values/calls.  The control flow construct mapping 
is relatively easy.  F77 and F90 parsing are both doable, and 
potentially a little fun.  I didn't get all the way into all the things 
that can be done with arrays, and there might be other tricky Fortran 
features I didn't get to.  It would be a substantial project, for either 
a good practical reason or a hobby.)


Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[racket-users] Question about template

[david . cao2002]

I am little confuse about template, my understanding is that template can only 
put into comment, template is not real code, am i right?

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] Defining a symbol breaks symbols?

[Alex Knauth]

Sorry it took so long, but I just finished making a meta-language that adds 
quote, quasiquote, etc. as hygienic reader extensions.

https://github.com/AlexKnauth/hygienic-quote-lang 


So now, you can write

#lang hygienic-quote racket

To make sure that the ' character will always be bound to the quote from 
racket/base, not some weird thing that you accidentally defined. It also does 
this for quasiquote, unquote, unquote-splicing, syntax, quasisyntax, unsyntax, 
and unsyntax-splicing.

It only works with the the new scope-set expander right now, although I could 
probably tweak it so that it works for both.


> On Oct 8, 2015, at 11:31 AM, Alex Knauth  wrote:
> 
> 
>> On Oct 8, 2015, at 9:00 AM, Lyle Kopnicky  wrote:
>> 
>> Yes, sorry, I've been traveling and didn't have time to respond. I was 
>> originally tempted to say "statically typed" and then realized that wasn't 
>> exactly right, because it was not static types that would forbid such a 
>> construction, so I said "static languages" suggesting languages where things 
>> cannot be so easily changed.
> 
> Ok I think I see what you're saying. Unhygienic macros capture bindings from 
> the use site, which breaks lexical scope and brings it closer to looking like 
> dynamic scope, and unhygienic reader extensions do the same thing. But that's 
> why we have hygienic macros and hygienic reader extensions; to restore 
> lexical scope, which is static.
> 
>> I'm not so familiar with reader macros. The documentation looks pretty 
>> extensive so I don't have to time to absorb it right now.
> 
> Reader extensions are not my favorite part of racket. Whenever I make them, 
> they feel like a bit of a mess.
> 
>> I would imagine that macros are not closures, therefore they shouldn't have 
>> any free variables.
> 
> Half the point of hygienic macros is that they can "close over" variables 
> that would otherwise appear to be free variables, but are actually bound to 
> some variable in the context of the macro definition instead of the context 
> of the macro use site. So they can act like closures. And it's in that 
> analogy of hygienic macros as closures that unhygienic macros look like 
> dynamic scope. But hygienic macros can "close over" these things to restore 
> lexical scope. 
> 
> Hygienic reader extensions can do the same thing, although there can be some 
> complications with an identifier being bound to an identifier that is not 
> available anywhere that the use site module knows about. So for instance the 
> afl meta-language expands to lambda from racket/base, but it only works when 
> the base language depends in some way on racket/base. That base language 
> doesn't need to provide the lambda from racket/base, but a dependency has to 
> be there somewhere. That isn't a lot to ask, but it does means that for 
> instance #lang afl racket/kernel won't work.
> 
> Matthew Flatt explained to me that for normal macros, this is handled 
> automatically, but not for reader extensions.
> 
>> Matthew Flatt gave a nice demonstration of a clean way to do that (using 
>> multiple scopes with colors). I'm not sure how things might be different for 
>> reader macros, though. It seems to me that while the input of a reader macro 
>> is different (plain text instead of sexprs), the output is still sexprs, so 
>> the same sort of scoping rules should apply.
> 
> For hygienic macros to avoid this capturing behavior, there has to be a color 
> at the use site of the macro that is not in the context of the definition of 
> the macro. This is handled automatically by default.
> 
> For hygienic reader extensions, the same principle applies, but you have to 
> do that yourself because it's not handled automatically. Also, there has to 
> be a dependency somewhere on the module that provides the identifier, which 
> is another thing macros handle automatically and reader extensions don't.
> 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Hendrik Boom]

On Thu, Oct 15, 2015 at 05:18:22PM -0400, Matthias Felleisen wrote:
...
...
> A common reason for fragmentation is the creation and use of function 
> libraries. For example, a Fortran programmer in the field of physical 
> simulations used different function libraries than one in commercial 
> check processing. When the former read the code of the latter, he 
> invariably experienced some form of alienation. [I am using past tense 
> because I am sure Fortran is kind of dead now :-).]

No, Fortran is not dead.  It's he preferred language used in heavy 
numerical computation because of its extreme efficiency for this class 
of application.

See 
http://arstechnica.com/science/2014/05/scientific-computings-future-can-any-coding-language-top-a-1950s-behemoth/

Fun that you mentioned Fortran; the article contains the sentence
"Originally specified in 1958, Lisp is the second-oldest high-level 
programming language in widespread use today; only Fortran is older"

credited to Dr. Joey Paquet.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Neil Van Dyke]

Hendrik Boom wrote on 10/15/2015 01:25 PM:

I'd like to ask:

What do the Scheme standards say about this?
What do Lisp standards say about this?

I don't know the answers to these questons, though maybe I should, and
Racket is not a standard Scheme, but I think these answers should
at least guide us.


Racket is all grown-up as its own language/platform now, and I 
definitely wouldn't encumber Racket evolution with CL or RnRS 
decisions.  (Though those other Lisp family subtrees have their own 
noble merits.)


I just found a paper that lays out Racket's pound-colon-prefix 
rationale: Flatt, Barzilay, "Keyword and Optional Arguments in PLT 
Scheme", http://www.ccs.neu.edu/racket/pubs/scheme2009-fb.pdf


But to start to answer your question, CL has long used colon-prefix for 
the visual appearance of keyword arguments.


Most Schemes don't agree with each other on keywords, though there is a 
tendency towards programmer-controlled selectivity among multiple 
conventions for what keyword arguments look like:
* I don't see keyword arguments in a quick skim of R7RS (although Google 
does find random claims that R7RS has keyword arguments, perhaps 
referring to committee discussion).
* Gambit Scheme has colon-suffix, plus some selectivity for colon-prefix 
(and uses pound-bang for some different purpose?). 
http://www.iro.umontreal.ca/~gambit/doc/gambit.html#Keyword-syntax

* Marc Feeley's (of Gambit fame) SRFI-88 and SRFI-89 propose colon-suffix.
* Guile supports all three conventions, selectively. 
http://www.gnu.org/software/guile/manual/html_node/Keyword-Read-Syntax.html
* Chicken uses pound-bang and selectively either colon-prefix or 
colon-suffix. 
http://wiki.call-cc.org/man/4/Non-standard%20read%20syntax#keyword
* Gauche has colon-prefix. 
http://practical-scheme.net/gauche/man/gauche-refe_5.html

* Chibi Scheme seems to use colon-suffix.

The Scheme situation is discouraging, and I'm glad that Racket (PLT 
Scheme) went ahead and did something.  However, I wish we all had cared 
slightly less about R5RS compatibility and such back then (especially 
since R5RS compatibility has been abandoned in much larger ways in 
Racket today, such as in pair mutability).  Perhaps I could've been 
using colon-prefix happily the last several years. And also, no one 
would have introduced the few problematic colon-symbols that now have to 
be considered before adding colon-prefix keywords today.


I'm still interested in adding colon-prefix keywords to `#lang racket` 
and `#lang racket/base`, ASAP, if the designers consider that 
worthwhile.  If it's not considered worthwhile at this time, then I'm 
tempted to finally do it with a package of my own writing, though that 
might effectively fragment the language.


(BTW, in response to an earlier comment regarding fragmentation, I think 
that `#lang foo-reader racket` and `#lang foo-replacing-racket-reader` 
are equivalent in immediate fragmentation effect.  What's more 
significant to fragmentation is when different people are using 
*incompatible source dialects* in snippets of code in forum posts, 
documentation, etc. -- not what the `#lang` line looks like in a 
complete module, if the code below that line would be the same 
regardless, and the module still interoperates across source dialects.)


Neil V.

--
You received this message because you are subscribed to the Google Groups "Racket 
Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Eli Barzilay]

On Thu, Oct 15, 2015 at 3:37 PM, Anthony Carrico  wrote:
> I didn't really want to get dragged into this, but keep in mind that:
>
> (symbol? #'test) ; -> #f
>
> IIRC the common lisp keywords you admire are symbols. I think that the
> proposed syntax confuses symbols and keywords, which are distinct
> types.

Yes, CL keywords are symbols, but there's no confusion since they are
very different from regular symbols.

To complete the details for whoever might be interested, in CL symbols
can be written as `foo:bar` for the (externally visible) "bar" symbol
from the "foo" package.  Symbols with no colon are implicitly in the
current package.  This is why `:foo` makes sense for keywords: it's the
"foo" symbol from the special keyword package -- special since it has no
name, and since all of its symbols are visible outside.  Now, consider
the fact that CL equates "identifiers" with "symbols", and uses packages
as a half-assed[*] attempt to get some sanity with my code not stepping
over your code -- and that should explain why `:foo` and `foo` are both
"the same type" but are very different in nature -- to the point that
your argument of a distinct type doesn't hold well in CL (and in Racket
too, since Neil's suggestion would make `:foo` not be a symbol).

Notes:

1. I use [*] in a technical way -- I once tried to explain hygiene to
   CLers by saying that it's as if each scope has its own (anonymous)
   package.

2. Also, talking about what counts as a symbol in CL is not too
   productive.  CL can surprise you with gems like: (symbol? (cdr '(1)))
   returning true.

3. I didn't see it mentioned so: the original motivation for `#:foo` was
   an attempt to avoid the argument of `:foo` vs `foo:` vs "either one"
   vs whatever.

-- 
((x=>x(x))(x=>x(x)))   Eli Barzilay:
http://barzilay.org/   Maze is Life!

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Matthias Felleisen]

On Oct 15, 2015, at 5:01 PM, Neil Van Dyke  wrote:

> BTW, in response to an earlier comment regarding fragmentation, I think that 
> `#lang foo-reader racket` and `#lang foo-replacing-racket-reader` are 
> equivalent in immediate fragmentation effect.  What's more significant to 
> fragmentation is when different people are using *incompatible source 
> dialects* in snippets of code in forum posts, documentation, etc. -- not what 
> the `#lang` line looks like in a complete module, if the code below that line 
> would be the same regardless, and the module still interoperates across 
> source dialects.


Neil and everyone else, 

Communities around extensible languages naturally fragment. The very moment you 
provide a mini-linguist, which is what a programmer really is, with the means 
to define nouns and verbs, the fragmentation starts. A common reason for 
fragmentation is the creation and use of function libraries. For example, a 
Fortran programmer in the field of physical simulations used different function 
libraries than one in commercial check processing. When the former read the 
code of the latter, he invariably experienced some form of alienation. [I am 
using past tense because I am sure Fortran is kind of dead now :-).]

When you allow programmers to define even more advanced aspects of a language 
-- with means such as macros -- you get even more fragmentation. People wish to 
conduct a discourse about a domain in the language of their domain, and the 
more we enable the creation of languages, the closer to the domain language(s) 
we get. 

In the end though, all of these linguistic disconnects can be bridged with a 
bit of reading code and documentation. 

In contrast to linguistic fragmentation, programming language communities may 
also experience social fragmentation. At the simplest level, they may disagree 
on the meaning of some feature. I think the order of evaluation in a function 
application is an example of the right kind here. They may disagree with the 
philosophy of language design in the standardization sense. The rollback of 
R6RS to the quasi-R5RS standard of R7RS is an example of this kind. This 
technical disagreements lead to forks in the tree of language development that 
are much more serious than the linguistic differentiation above. 

My take is that #lang colon-kw-mixn racket/base is a dialect in the way South 
German or Swiss German relates to High German (a normative language that nobody 
speaks except for some pretty-looking dumb TV announcers perhaps). The R6RS vs 
R7RS differentiation of Scheme vs Clojure separation is more like English and 
German. 

With this said, I am fine with North Germans. I just wished they learned to 
speak properly -- Matthias :-) 

p.s. Similar analogies could be drawn with American social dialects. But as a 
Man from Away, I'll stay away from this hot topic. 

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] crash in nightly build

[Matthew Flatt]

I've just stumbled across a subtle and difficult-to-provoke GC bug
while testing new changes to the GC. The problem was introduced in
commit 50df879e or so (September 10), so I think the timing of the
change is consistent with your problem.

For this bug to be relevant, your program would need to run a minor
collection when memory use is in the neighborhood of 256MB to 300MB
(which is not uncommon for 64-bit programs).

The specific crash I can see also involves allocation a finalizer
shortly before the GC, but the creation of a finalizer can be triggered
in many ways, such as calling a bit of code for the first time so that
it gets JIT-compiled.

At Thu, 15 Oct 2015 11:56:21 +0300, Dmitry Pavlov wrote:
> Matthew,
> 
> > It seems that I have lost my grip on the crash.
> > It has not happened for almost a week---neither with the version
> > that I build myself, nor with the nightly build where I definitely
> > saw it. I did not update Racket during this time.
> > I did not do anything else. I have no idea why it is gone. Sorry.
> 
> Oops, it just crashed again, 5+ hours of running.
> I will re-run in under gdb. There is no guarantee, though,
> that it will crash this time.
> 
> By the way, I input "handle SIGSEGV nostop noprint" into gdb prior
> to running, to get rid of gdb's complaints about Racket VM's way of
> doing things. Am I correct that this should not hide the actual crash?
> 
> Best regards,
> 
> Dmitry
> 
> -- 
> You received this message because you are subscribed to the Google Groups 
> "Racket Users" group.
> To unsubscribe from this group and stop receiving emails from it, send an 
> email to racket-users+unsubscr...@googlegroups.com.
> For more options, visit https://groups.google.com/d/optout.

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Anthony Carrico]

In case I'm being to oblique, I'm trying to point out that:
  (equal? '#:test ':test) ; -> #f
which means that the proposal will certainly break things.

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Hendrik Boom]

On Thu, Oct 15, 2015 at 05:48:17AM +0200, Pierpaolo Bernardi wrote:
> On Wed, Oct 14, 2015 at 11:34 PM, Neil Van Dyke  wrote:
> > Alex Knauth wrote on 10/14/2015 04:37 PM:
> >>
> >> You can use
> >> #lang colon-kw racket
> >> for :kw syntax, and
> >> #lang kw-colon racket
> >> for kw: syntax.
> >
> >
> > If the standard `#lang racket` and `#lang racket/base` don't support
> > `:keyword` out of the box -- but instead some alternative reader or forked
> > #lang is required -- then we would expect error messages about `:keyword`
> > not working to be an FAQ on the email list.  That's one intuitive example of
> > the kinds of problems that arise.
> 
> But supporting this out of the box in #lang racket would invalidate
> existing racket programs, no?

I'd like to ask:

What do the Scheme standards say about this?
What do Lisp standards say about this?

I don't know the answers to these questons, though maybe I should, and 
Racket is not a standard Scheme, but I think these answers should 
at least guide us.

-- hendrik

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Anthony Carrico]

I didn't really want to get dragged into this, but keep in mind that:

(symbol? #'test) ; -> #f

IIRC the common lisp keywords you admire are symbols. I think that the
proposed syntax confuses symbols and keywords, which are distinct types.

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Anthony Carrico]

On 10/15/2015 03:37 PM, Anthony Carrico wrote:
> I didn't really want to get dragged into this, but keep in mind that:
> 
> (symbol? #'test) ; -> #f

err... (symbol? '#:test) ; -> #f

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

Re: [racket-users] racket users fight for their right to colon keywords

[Anthony Carrico]

On 10/15/2015 03:39 PM, Anthony Carrico wrote:
> On 10/15/2015 03:37 PM, Anthony Carrico wrote:
>> I didn't really want to get dragged into this, but keep in mind that:
>>
>> (symbol? #'test) ; -> #f
> 
> err... (symbol? '#:test) ; -> #f
> 

Yes. I found this in the Common Lisp Hyperspec:

(symbolp :test) =>  true

http://www.lispworks.com/documentation/HyperSpec/Body/f_symbol.htm#symbolp

-- 
Anthony Carrico

-- 
You received this message because you are subscribed to the Google Groups 
"Racket Users" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to racket-users+unsubscr...@googlegroups.com.
For more options, visit https://groups.google.com/d/optout.