[racket-users] degenerate performance in syntax-parse

[Dan Liebgold]

Hi all -

In the process of putting together a somewhat complex application using 
syntax-parse, I discovered that when I specified a repeated pattern in a 
syntax-class (which was incorrect) AND I had a certain usage of the syntax 
transformer with an error, it would lead to degenerate performance (Racket 
would run out of memory or it would need to be killed. 

Please see this example and uncomment the last non-paren line to see it fall 
down:

http://pasterack.org/pastes/50261

Thanks,
Dan

-- 
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: opinions on YAML as communication tool

[Jack Firth]

If you'd still like to use yaml, I would like to quietly point out that each of 
the following is a valid boolean value in yaml:

- true
- false
- yes
- no
- y
- n
- True
- False
- TRUE
- FALSE
- on
- off
- YES
- NO

... but it's not strictly case-insensitive, as yES is parsed as a string

-- 
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] opinions on YAML as communication tool

['John Clements' via Racket Users]

> On Oct 21, 2016, at 12:42 PM, Tony Garnock-Jones  wrote:
> 
> On 10/21/2016 01:21 AM, 'John Clements' via Racket Users wrote:
>> I thought hard about scribble and JSON (and xml, yecch), but I think 
>> that YAML and sexps are the two viable candidates, and I’m guessing 
>> that if non-programmers have to edit it, they’ll be less likely to 
>> botch the YAML one.
> 
> If it's a choice between the two then RUN, do not walk, away from YAML
> and go for sexps. (XML or JSON would also be OK choices.)
> 
> YAML is never the right choice. (In writing this email, I have gone over
> it several times toning down my language.)
> 
> YAML makes XML look simple, elegant and well-designed. The spec is ~80
> pages long. I find it impossible to predict how a YAML processor will
> interpret any given input.
> 
> You know how Excel guesses whether things are dates or not and messes
> things up as a consequence? YAML does that too.
> 
> The "spec" vaguely suggests that applications should use regular
> expressions to take a guess at what type of information is presented in
> a non-explicitly-tagged field. What if there are multiple possible
> interpretations? The spec doesn't help you. No, it explicitly disavows
> responsibility for such weighty decisions, pointing out that ultimately,
> "tag resolution is specific to the application". It's a mess.
> 
> There's room for something that does what YAML aims to do, but YAML
> isn't it.

Interesting. I’m trying to wiggle out of your argument, but it’s fairly 
persuasive. Many thanks for your info. Sigh.

John



-- 
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] Intro documentation question

[Matthew Butterick]

On Oct 21, 2016, at 11:39 AM, Doug Edmunds  wrote:
> 
> (define series
>  (lambda (mk)
>(hc-append 4 (mk 5) (mk 10) (mk 20
> 
> (define (rgb-series mk)
>  (vc-append
>   (series (lambda (sz) (colorize (mk sz) "red")))
>   (series (lambda (sz) (colorize (mk sz) "green")))
>   (series (lambda (sz) (colorize (mk sz) "blue")
> 
> I am having difficulty understanding how the numbers 5, 10, and 20
> in the first definition 
> become "sz"  in the second definition. 

`series` is a function that takes one argument (also a function), labeled `mk`, 
and applies it to 5, 10, and 20.

So if `series` is called like this:

(series (lambda (sz) (colorize (mk sz) "red")))

Then the `mk` argument in `series` is:

(lambda (sz) (colorize (mk sz) "red"))

(Note that the `mk` identifier inside this lambda refers to a different `mk` = 
the one from `rgb-series`)

So within `series`, this:

(mk 5)

Means this:

((lambda (sz) (colorize (mk sz) "red")) 5) 

When this lambda is applied to 5, then `sz` takes on the value 5 (or 10, or 20) 
within the lambda.

-- 
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] Unable to track down what is requiring inclusion of tzinfo module - Resolved

[Jon Zeppieri]

This connects to a similar issue I was having with my reorganization of the
CLDR libraries (which I'm getting back into): https://groups.google.
com/d/msg/racket-dev/MrmxvvKidj8/ASEF22_lBQAJ.

It looks like, in the present case, I should do something like this:


- The tzdata package includes, in its info.rkt:

(define tzdata-data-files )

I suppose each of the paths should have the form (list 'lib
"tzinfo/private/data/<...>"), based on the current directory structure of
the tzdata package.

- The tzinfo code then does something like:

(define-runtime-path-list tzdata-paths
  (match (find-relevant-directories '(tzdata-data-files))
[(cons dir _)
  ((get-info/full dir) 'tzdata-data-files)]
[_ #f]))

Does that sound right?

- Jon




On Fri, Oct 14, 2016 at 12:39 AM, Sam Tobin-Hochstadt 
wrote:

> That's likely the problem. Usually you need to use define-runtime-path or
> a variant of that to cooperate with raco exe.
>
> Sam
>

-- 
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] opinions on YAML as communication tool

[Tony Garnock-Jones]

On 10/21/2016 01:21 AM, 'John Clements' via Racket Users wrote:
> I thought hard about scribble and JSON (and xml, yecch), but I think 
> that YAML and sexps are the two viable candidates, and I’m guessing 
> that if non-programmers have to edit it, they’ll be less likely to 
> botch the YAML one.

If it's a choice between the two then RUN, do not walk, away from YAML
and go for sexps. (XML or JSON would also be OK choices.)

YAML is never the right choice. (In writing this email, I have gone over
it several times toning down my language.)

YAML makes XML look simple, elegant and well-designed. The spec is ~80
pages long. I find it impossible to predict how a YAML processor will
interpret any given input.

You know how Excel guesses whether things are dates or not and messes
things up as a consequence? YAML does that too.

The "spec" vaguely suggests that applications should use regular
expressions to take a guess at what type of information is presented in
a non-explicitly-tagged field. What if there are multiple possible
interpretations? The spec doesn't help you. No, it explicitly disavows
responsibility for such weighty decisions, pointing out that ultimately,
"tag resolution is specific to the application". It's a mess.

There's room for something that does what YAML aims to do, but YAML
isn't it.

Tony

-- 
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] Intro documentation question

[Doug Edmunds]

I am new to Racket and have just started the tutorials.

In section 7 "Lexical Scope" of the Quick introduction
http://download.racket-lang.org/releases/6.6/doc/quick/index.html

there is this code:

(define series
  (lambda (mk)
(hc-append 4 (mk 5) (mk 10) (mk 20

(define (rgb-series mk)
  (vc-append
   (series (lambda (sz) (colorize (mk sz) "red")))
   (series (lambda (sz) (colorize (mk sz) "green")))
   (series (lambda (sz) (colorize (mk sz) "blue")

I am having difficulty understanding how the numbers 5, 10, and 20
in the first definition 
become "sz"  in the second definition. 

-- 
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] Better? or less good?

[Matthew Butterick]

On Oct 21, 2016, at 7:24 AM, David Raymond Christiansen 
 wrote:

> (let ((v #t))
>  (if v v fnord))
> 
> This is not even a program, because "fnord" has no meaning.

If you don't like unbound-identifer errors, you can change `#%top`:

(define-syntax-rule (#%top . x) (error 'oops))
(or #t Gor) ; #t
(or #f Gor) ; error: oops

-- 
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] Re: date->seconds complaining about a supposedly non-existent date

[Jon Zeppieri]

On Fri, Oct 21, 2016 at 12:17 AM, Jack Firth  wrote:

> There's also the Gregor package (https://docs.racket-lang.org/
> gregor/index.html?q=gregor), which gives a much more comprehensive
> interface to dates and times. In particular, Gregor allows you to specify
> an "offset resolver" for these sorts of time-holes.
>
>
I'd just add to this that if you're not using local times at all (which
seems to be the case here), you're better off using Gregor's `datetime`
type (instead of `moment`). That way you don't need to worry about time
zones and their idiosyncrasies.

-- 
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] opinions on YAML as communication tool

[Jay McCarthy]

Since we're all just making up stuff, I mostly agree with Ben that if
a spreadsheet is the right tool, then use that tool. There are a few
spreadsheets that support version control internally, like Google Docs
and Microsoft Office Version Tracking.

In addition, there are the elite tools of graybeard grognards like
Emacs org-mode spreadsheets and your truly best option 'sc' [1],
because these have plain-text version-control system friendly formats
from the get-go. `sc` is the only way I spreadsheet. n00bs.

Jay

1. man page from FreeBSD:
https://www.freebsd.org/cgi/man.cgi?query=sc=0=0=FreeBSD+6.0-RELEASE+and+Ports=html

On Fri, Oct 21, 2016 at 12:16 PM, Ben Greenman
 wrote:
> I vote that you stick with Excel & change the version control protocol.
>
> Maybe:
> http://stackoverflow.com/a/17106035/5237018
>
> On Fri, Oct 21, 2016 at 9:22 AM, Matthias Felleisen 
> wrote:
>>
>>
>> See Claire’s paper on cKanren. Scheduling is one of her examples (though
>> small scale).
>>
>>
>>
>> > On Oct 21, 2016, at 7:18 AM, Robby Findler 
>> > wrote:
>> >
>> > Wh? You're not going to design your own language and implement a
>> > syntax colorer in DrRacket for it so they can tell immediately when
>> > something goes wrong?  ;)
>> >
>> > Robby
>> >
>> >
>> > On Fri, Oct 21, 2016 at 12:21 AM, 'John Clements' via Racket Users
>> >  wrote:
>> >> Yet another totally off-topic question for you extremely smart people.
>> >> Well, it’s a language design question, so it’s not *too* off-topic.
>> >>
>> >> I’m temporarily serving as my department’s scheduler (don’t ask).
>> >> Currently, the planning for the future schedule is done using an Excel
>> >> spreadsheet. I try not to hate Microsoft products for knee-jerk reasons, 
>> >> but
>> >> the simple fact is that this format is completely not git-versionable.
>> >>
>> >> This file has to be shared with non-programmers, though it doesn’t
>> >> necessarily have to be *edited* by non-programmers, just read.
>> >>
>> >> I’m currently thinking that the best compromise may be YAML. E.G.
>> >>
>> >> # 2017-2018 schedule:
>> >> alincoln : {fall: [304, 428], winter: [409, special], spring: []} #
>> >> maybe theater?
>> >> gwashington: {fall: [224, 287, 110], winter: sabbatical, spring: [789]}
>> >> # might be able to hire stuffy?
>> >> stuffy: {fall: [234,234,234], winter: [235, 235, 235]}
>> >> …
>> >>
>> >> It looks like a fairly dense format, it’s a text file so it’s
>> >> versionable in a sane way, and you could be fairly flexible in your 
>> >> parsing.
>> >>
>> >> To be fair, sexprs also look pretty good:
>> >>
>> >> ;; 2017-2018 schedule
>> >> ((alincoln ((fall (304 428)) (winter (409 special)) (spring ( ;;
>> >> maybe theater?
>> >> (gwashington ((fall (224 287 110)) (winter sabbatical) (spring (789
>> >> ;; might be able to hire stuffy?
>> >> (stuffy ((fall (234 234 234)) (winter 235 235 235
>> >>
>> >> Also note that there’s no need for this file to contain any information
>> >> about times and rooms, just a mapping from instructor/quarter
>> >> to classes taught, with room for comments.
>> >>
>> >> I thought hard about scribble and JSON (and xml, yecch), but I think
>> >> that YAML and sexps are the two viable candidates, and I’m guessing that 
>> >> if
>> >> non-programmers have to edit it, they’ll be less likely to botch the YAML
>> >> one.
>> >>
>> >> Any opinions?
>> >>
>> >> John
>> >>
>> >>
>> >>
>> >>
>> >> --
>> >> 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.
>>
>> --
>> 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.



-- 
Jay McCarthy
Associate Professor
PLT @ CS @ UMass Lowell
http://jeapostrophe.github.io

   "Wherefore, be not weary in well-doing,
  for ye are laying the foundation of a great work.
And out of small things 

Re: [racket-users] opinions on YAML as communication tool

[Ben Greenman]

I vote that you stick with Excel & change the version control protocol.

Maybe:
http://stackoverflow.com/a/17106035/5237018

On Fri, Oct 21, 2016 at 9:22 AM, Matthias Felleisen 
wrote:

>
> See Claire’s paper on cKanren. Scheduling is one of her examples (though
> small scale).
>
>
>
> > On Oct 21, 2016, at 7:18 AM, Robby Findler 
> wrote:
> >
> > Wh? You're not going to design your own language and implement a
> > syntax colorer in DrRacket for it so they can tell immediately when
> > something goes wrong?  ;)
> >
> > Robby
> >
> >
> > On Fri, Oct 21, 2016 at 12:21 AM, 'John Clements' via Racket Users
> >  wrote:
> >> Yet another totally off-topic question for you extremely smart people.
> Well, it’s a language design question, so it’s not *too* off-topic.
> >>
> >> I’m temporarily serving as my department’s scheduler (don’t ask).
> Currently, the planning for the future schedule is done using an Excel
> spreadsheet. I try not to hate Microsoft products for knee-jerk reasons,
> but the simple fact is that this format is completely not git-versionable.
> >>
> >> This file has to be shared with non-programmers, though it doesn’t
> necessarily have to be *edited* by non-programmers, just read.
> >>
> >> I’m currently thinking that the best compromise may be YAML. E.G.
> >>
> >> # 2017-2018 schedule:
> >> alincoln : {fall: [304, 428], winter: [409, special], spring: []} #
> maybe theater?
> >> gwashington: {fall: [224, 287, 110], winter: sabbatical, spring: [789]}
> >> # might be able to hire stuffy?
> >> stuffy: {fall: [234,234,234], winter: [235, 235, 235]}
> >> …
> >>
> >> It looks like a fairly dense format, it’s a text file so it’s
> versionable in a sane way, and you could be fairly flexible in your parsing.
> >>
> >> To be fair, sexprs also look pretty good:
> >>
> >> ;; 2017-2018 schedule
> >> ((alincoln ((fall (304 428)) (winter (409 special)) (spring ( ;;
> maybe theater?
> >> (gwashington ((fall (224 287 110)) (winter sabbatical) (spring (789
> >> ;; might be able to hire stuffy?
> >> (stuffy ((fall (234 234 234)) (winter 235 235 235
> >>
> >> Also note that there’s no need for this file to contain any information
> about times and rooms, just a mapping from instructor/quarter
> >> to classes taught, with room for comments.
> >>
> >> I thought hard about scribble and JSON (and xml, yecch), but I think
> that YAML and sexps are the two viable candidates, and I’m guessing that if
> non-programmers have to edit it, they’ll be less likely to botch the YAML
> one.
> >>
> >> Any opinions?
> >>
> >> John
> >>
> >>
> >>
> >>
> >> --
> >> 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.
>
> --
> 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] Better? or less good?

[David Christiansen]

Hi again,

> The latter has the same meaning as this:
>
> (let ((v #t))
>   (if v v fnord))
>
> This is not even a program, because "fnord" has no meaning.

Robby pointed out off-list that I should point out that this is a
feature of Racket, not programming languages in general. In many other
languages, variable references are a runtime feature rather than a
part of the syntax. Here's some Elisp, which makes the other decision:

el> (let ((v t)) (if v v fnord))
t

Similar results are obtained in many languages. Others, however, work
as Racket does in this respect, like Idris:

Idris> let v = True in if v then v else fnord
When checking argument val to constructor Delay:
No such variable fnord

/David

-- 
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] ACM/SPEC ICPE 2017 - Call for Workshop Proposals

[Andrea Rosà]

   ICPE 2017
8th ACM/SPEC International Conference on Performance Engineering

   Sponsored by ACM SIGMETRICS, SIGSOFT, and SPEC RG

L'Aquila, Italy
 April 22-26, 2017

  https://icpe2017.spec.org/



IMPORTANT DATES

Workshop Proposals:
Nov 5, 2016

Workshop Proposals Notification:
Nov 19, 2016



SCOPE AND TOPICS

The goal of the International Conference on Performance Engineering (ICPE) is 
to integrate theory and practice in the field of performance engineering by 
providing a forum for sharing ideas and experiences between industry and 
academia. Nowadays, complex systems of all types, like Web-based systems, data 
centers and cloud infrastructures, social networks, peer-to-peer, mobile and 
wireless systems, cyber-physical systems, the Internet of Things, real-time and 
embedded systems, have increasingly distributed and dynamic system 
architectures that provide high flexibility, however, also increase the 
complexity of managing end-to-end application performance.
ICPE brings together researchers and industry practitioners to share and 
present their experiences, discuss challenges, and report state-of-the-art and 
in-progress research on performance engineering of software and systems, 
including performance measurement, modeling, benchmark design, and run-time 
performance management. The focus is both on classical metrics such as response 
time, throughput, resource utilization, and (energy) efficiency, as well as on 
the relationship of such metrics to other system properties including but not 
limited to scalability, elasticity, availability, reliability, and security.



CALL FOR WORKSHOPS

Workshop proposals are invited for ICPE 2017 on specific aspects of performance 
engineering, particularly relating to the subject areas indicated by the 
conference call for papers. We encourage workshops that will discuss 
fundamental research issues driven by academic interests or more applied 
industrial or commercial concerns. The format of the workshop will be 
determined by the organizers and can include invited talks, panel discussions, 
work in progress, and fully refereed papers. Workshops can vary in length from 
a half day to a full day. Having more than one co-organizer for a workshop is 
strongly advised. The workshop proceedings will be published by ACM.

More information can be found at 
https://icpe2017.spec.org/submissions/workshops.html



PROPOSAL GUIDELINES

Proposals for workshops should be no more than 2 pages in length. They should 
contain the following information:

- Title and brief technical description of the workshop, specifying the goals 
and the technical issues that will be its focus.
- Data about previous instances of the workshop including links to the 
corresponding websites.
- The names and contact information (web page, email address) of the organizing 
committee; a short bio and the qualifications of the main organizers with 
respect to organizing this workshop.
- Estimated number of attendees.
- Link to a preliminary web site of the workshop and a preliminary call for 
papers.
- A list of committed and proposed PC members.



RESPONSIBILITIES

Each workshop organizing committee will be responsible for:

- Producing a web page and a "Call for Papers/Participation" for their 
workshop. The URL should be sent to the workshop co-chairs for ICPE 2017.
- Providing a brief description of the workshop for the conference web page and 
program.
- Selecting the participants and the format of the workshop.
- Ensuring that suitable quality measures have been taken to ensure that the 
accepted papers are of high quality.

The ICPE Organizing Committee will be responsible for:

- Providing a link to a workshop website.
- Providing logistics support and a meeting place for the workshop.
- Providing copies of the workshop proceedings to attendees.



SUBMISSION PROCESS

Workshop proposals and inquiries should be sent by email to the workshop 
co-chairs Catia Trubiani (catia.trubi...@gssi.infn.it) and Hanspeter Mössenböck 
(hanspeter.moessenbo...@jku.at). Proposals should be sent in PDF format.



WORKSHOPS CHAIRS

* Hanspeter Mössenböck, Johannes Kepler Universität Linz, Austria
* Catia Trubiani, Gran Sasso Science Institute, Italy

Please feel free to contact the workshops chairs if you have any questions 
regarding potential ICPE 2017 workshops.

Re: [racket-users] Better? or less good?

[David Raymond Christiansen]

Hello,


   I noticed that Racket detects the variables used without any value.
But let us consider the expression:

(or #t Gor)

   Since "or" evaluates as few arguments as possible, the result is #t,
but this expression is rejected by Racket because "Gor" is unbound. So
the rule would become: some arguments of "and" and "or" may be not
evaluated, for example:

(and #f (/ 0))

but do not use this feature with unbound identifiers... From my modest
point of view, that is not homogeneous... What do you think, please?


There are (at least) two kinds of bad program texts out there: those 
texts that encode programs that will crash when run, and those texts 
that are not even programs. Here are some examples of the former:


(error "oops")

(/ 1 0)

Here are some examples of the latter:

(/ who-knows 2)

-

(- ")

The latter category are not even programs, because they cannot be 
translated to a binding tree. The first example in the second group is 
not a binding tree because it has a name that doesn't point at any 
binding location, while the latter two have mismatched delimiters.



Now let's look at two putative program texts:

(or #t (error "oops"))

and

(or #t fnord)

The former has the same meaning as this:

(let ((v #t))
  (if v v (error "oops")))

This is a program that will not crash.

The latter has the same meaning as this:

(let ((v #t))
  (if v v fnord))

This is not even a program, because "fnord" has no meaning.

Does this make sense?

/David

--
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] Better? or less good?

[Robby Findler]

Hi Jean-Michel: the determination that "Gor" is a free variable
happens as part of the compilation of the program, much in the same
way that this expression:

  (or #t (lambda x))

is rejected.

Robby


On Fri, Oct 21, 2016 at 9:12 AM, Jean-Michel HUFFLEN
 wrote:
>Dear Racket users,
>
>I noticed that Racket detects the variables used without any value. But
> let us consider the expression:
>
> (or #t Gor)
>
>Since "or" evaluates as few arguments as possible, the result is #t, but
> this expression is rejected by Racket because "Gor" is unbound. So the rule
> would become: some arguments of "and" and "or" may be not evaluated, for
> example:
>
> (and #f (/ 0))
>
> but do not use this feature with unbound identifiers... From my modest point
> of view, that is not homogeneous... What do you think, please?
>
>Cheers,
>
> J.-M. Hufflen
>
>
> 
> This message was sent using IMP, the Internet Messaging Program.
>
> --
> 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.

[racket-users] Better? or less good?

[Jean-Michel HUFFLEN]

   Dear Racket users,

   I noticed that Racket detects the variables used without any  
value. But let us consider the expression:


(or #t Gor)

   Since "or" evaluates as few arguments as possible, the result is  
#t, but this expression is rejected by Racket because "Gor" is  
unbound. So the rule would become: some arguments of "and" and "or"  
may be not evaluated, for example:


(and #f (/ 0))

but do not use this feature with unbound identifiers... From my modest  
point of view, that is not homogeneous... What do you think, please?


   Cheers,

J.-M. Hufflen



This message was sent using IMP, the Internet Messaging Program.

--
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] opinions on YAML as communication tool

[Matthias Felleisen]

See Claire’s paper on cKanren. Scheduling is one of her examples (though small 
scale). 



> On Oct 21, 2016, at 7:18 AM, Robby Findler  
> wrote:
> 
> Wh? You're not going to design your own language and implement a
> syntax colorer in DrRacket for it so they can tell immediately when
> something goes wrong?  ;)
> 
> Robby
> 
> 
> On Fri, Oct 21, 2016 at 12:21 AM, 'John Clements' via Racket Users
>  wrote:
>> Yet another totally off-topic question for you extremely smart people. Well, 
>> it’s a language design question, so it’s not *too* off-topic.
>> 
>> I’m temporarily serving as my department’s scheduler (don’t ask). Currently, 
>> the planning for the future schedule is done using an Excel spreadsheet. I 
>> try not to hate Microsoft products for knee-jerk reasons, but the simple 
>> fact is that this format is completely not git-versionable.
>> 
>> This file has to be shared with non-programmers, though it doesn’t 
>> necessarily have to be *edited* by non-programmers, just read.
>> 
>> I’m currently thinking that the best compromise may be YAML. E.G.
>> 
>> # 2017-2018 schedule:
>> alincoln : {fall: [304, 428], winter: [409, special], spring: []} # maybe 
>> theater?
>> gwashington: {fall: [224, 287, 110], winter: sabbatical, spring: [789]}
>> # might be able to hire stuffy?
>> stuffy: {fall: [234,234,234], winter: [235, 235, 235]}
>> …
>> 
>> It looks like a fairly dense format, it’s a text file so it’s versionable in 
>> a sane way, and you could be fairly flexible in your parsing.
>> 
>> To be fair, sexprs also look pretty good:
>> 
>> ;; 2017-2018 schedule
>> ((alincoln ((fall (304 428)) (winter (409 special)) (spring ( ;; maybe 
>> theater?
>> (gwashington ((fall (224 287 110)) (winter sabbatical) (spring (789
>> ;; might be able to hire stuffy?
>> (stuffy ((fall (234 234 234)) (winter 235 235 235
>> 
>> Also note that there’s no need for this file to contain any information 
>> about times and rooms, just a mapping from instructor/quarter
>> to classes taught, with room for comments.
>> 
>> I thought hard about scribble and JSON (and xml, yecch), but I think that 
>> YAML and sexps are the two viable candidates, and I’m guessing that if 
>> non-programmers have to edit it, they’ll be less likely to botch the YAML 
>> one.
>> 
>> Any opinions?
>> 
>> John
>> 
>> 
>> 
>> 
>> --
>> 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.

-- 
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] opinions on YAML as communication tool

[Robby Findler]

Wh? You're not going to design your own language and implement a
syntax colorer in DrRacket for it so they can tell immediately when
something goes wrong?  ;)

Robby


On Fri, Oct 21, 2016 at 12:21 AM, 'John Clements' via Racket Users
 wrote:
> Yet another totally off-topic question for you extremely smart people. Well, 
> it’s a language design question, so it’s not *too* off-topic.
>
> I’m temporarily serving as my department’s scheduler (don’t ask). Currently, 
> the planning for the future schedule is done using an Excel spreadsheet. I 
> try not to hate Microsoft products for knee-jerk reasons, but the simple fact 
> is that this format is completely not git-versionable.
>
> This file has to be shared with non-programmers, though it doesn’t 
> necessarily have to be *edited* by non-programmers, just read.
>
> I’m currently thinking that the best compromise may be YAML. E.G.
>
> # 2017-2018 schedule:
> alincoln : {fall: [304, 428], winter: [409, special], spring: []} # maybe 
> theater?
> gwashington: {fall: [224, 287, 110], winter: sabbatical, spring: [789]}
> # might be able to hire stuffy?
> stuffy: {fall: [234,234,234], winter: [235, 235, 235]}
> …
>
> It looks like a fairly dense format, it’s a text file so it’s versionable in 
> a sane way, and you could be fairly flexible in your parsing.
>
> To be fair, sexprs also look pretty good:
>
> ;; 2017-2018 schedule
> ((alincoln ((fall (304 428)) (winter (409 special)) (spring ( ;; maybe 
> theater?
>  (gwashington ((fall (224 287 110)) (winter sabbatical) (spring (789
>  ;; might be able to hire stuffy?
>  (stuffy ((fall (234 234 234)) (winter 235 235 235
>
> Also note that there’s no need for this file to contain any information about 
> times and rooms, just a mapping from instructor/quarter
> to classes taught, with room for comments.
>
> I thought hard about scribble and JSON (and xml, yecch), but I think that 
> YAML and sexps are the two viable candidates, and I’m guessing that if 
> non-programmers have to edit it, they’ll be less likely to botch the YAML one.
>
> Any opinions?
>
> John
>
>
>
>
> --
> 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] opinions on YAML as communication tool

[Stefan Schmiedl]

'John Clements' via Racket Users (21.10. 01:21):

> I thought hard about scribble and JSON (and xml, yecch), but I think
> that YAML and sexps are the two viable candidates, and I’m guessing
> that if non-programmers have to edit it, they’ll be less likely to
> botch the YAML one.

My timesheet and invoice backend have been yaml files for 10 years now.
If you intend to let "non-programmers" work on it, I'd go for the
vertical layout:

---
alincoln:
  fall:
  - 304
  - 428
  winter:
  - 409
  - special
  spring: # maybe theater
gwashington:
  fall:
  - 224
  - 287
  - 110
  winter: sabbatical
  spring:
  - 789
# might be able to hire stuffy?
stuffy:
  fall:
  - 234
  - 234
  - 234
  winter:
  - 235
  - 235
  - 235

That being said, sexps have less "magic", which comes in handy if you
end up dealing with strings made of digits which promptly lose leading zeros due
to being converted to integers.

---
bond, james: 007

might well end up with the integer 7, like in the following ruby
example:

>> YAML.load("bond, james: 007")
=> {"bond, james"=>7}

So YAML "looks" easier, but sexps are more consistent.

s.

-- 
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.