[racket-users] Re: Little language design/implementation guidance

[George Neuner]

On Wed, 6 Feb 2019 16:25:47 +, Stephen De Gabrielle
 wrote:

>Dave Herman recently tweeted[1] that consulting a PL specialist was a
>good idea for little languages to avoid common foundational mistakes,
>specifically mentioning templating systems and configuration files.
>
>So when designing(or evolving) a little language:
>
>  - what beginners mistakes should you avoid?
>(some in the subsequent tweets I’ve copied below)
>  - When should you consult a PL specialist? 
>(and how do you identify a PL specialist?)
>
>More generally, can you recommend resources a developer (without a
>background in language design) should refer to if they are building a
>simple templating system, application configuration file, etc. - that
>may grow into a little language?
>
>Kind regards,
>
>Stephen 
>
>PS please forgive me if this is the wrong list for this question.


No offense to Herman, but I think the problem with consulting experts
is that there are relatively few language experts who are available to
consult.  Certainly there are those who are willing to answer
questions (at least well defined questions) but most likely are busy
with their own work and can't be expected to devote a whole lot of
time to helping someone design a new language.


I agree with all the pitfalls Herman mentions, and to them I would
add:

 - fascination with C-like or natural language syntax

 - avoidance of parser tools/libraries

 - picking a programming paradigm that is not well suited to 
   the problem domain

 - not using an IR - trying to interpret or compile straight
   from source text

 - forgetting about debugging

These are just off the cuff - if I were to think about it for a while
I probably would come up with more.


I think every *serious* developer should read at least an introductory
text on compilers.  Even if you never try to implement your own
language, understanding what happens to your code when its compiled
makes you a better programmer.

A developer serious about creating DSLs might want deeper study of
both compilers and virtual machines [keeping in mind that programming
languages always are defined over a "virtual" machine (that then is
implemented on a real machine)].

YMMV,
George


 -
>[1] https://twitter.com/littlecalculist/status/1092160821944213504?s=21
>
>> It's frustrating that PL is considered such a specialization that PL
>> people only get brought in for big languages. There are vastly more
>> little languages everywhere. People often don't realize their little
>> language needs better underpinnings until very late, if at all.
>
>
>Common mistakes tweeted by Dave Herman in subsequent thread;
>
>> Scenario-solving: language design at its heart is figuring out what
>> your composable primitives are. Too often, people think of use cases
>> one scenario at a time and just sort of glue them together w/o
>> generalizing and simplifying.
>
>> Reinventing lexical scope: many systems start by using string
>> concatenation as their core model, instead of composing modules with
>> a rationalized notion of scope. Another common scoping mistake is
>> exposing variables as mutating a global scope.
>
>> Lack of abstraction mechanisms: when you don't think of yourself as
>> designing a language, you put up with boilerplate and copy-pasta.
>
>> Lack of strategy for general-purpose logic: ultimately most DSLs end
>> up needing general-purpose programming language—often it's in a
>> minority of cases but when you need it you really need it. The best
>> ones IMO have clear extension points and contracts with a
>> general-purpose PL

 

-- 
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: Some concern about ChezScheme...

[George Neuner]

On Wed, 6 Feb 2019 12:50:21 -0500, Matthias Felleisen
 wrote:

>> On Feb 6, 2019, at 12:30 PM, 'Paulo Matos' via Racket Users 
>>  wrote:
>> 
>> I was quite surprised to read these nanopass ideas have been around for
>> so long.
>
>
>1. The educational idea came first: 
>
>A Nanopass framework for compiler education. • Volume 15, Issue 5 • September 
>2005 , pp. 653-667
>
>https://www.cambridge.org/core/journals/journal-of-functional-programming/article/educational-pearl-a-nanopass-framework-for-compiler-education/1E378B9B451270AF6A155FA0C21C04A3
>
>2. The experience report of applying the idea to a commercial compiler came 
>about 10 years later: 
>
>A Nanopass framework for commercial compiler development. ICFP ’13 , pp 343-350
>
>https://dl.acm.org/citation.cfm?id=2500618 
>
>
>— Matthias


The idea that a compiler should be structured as multiple passes each
doing just one clearly defined thing is quite old.  I don't have
references, but I recall some of these ideas being floated in the late
80's, early 90's [when I was in school].

Interestingly, LLVM began (circa ~2000) with similar notions that the
compiler should be highly modular and composed of many (relatively
simple) passes.  Unfortunately, they quickly discovered that, for a C
compiler at least, having too many passes makes the compiler very slow
- even on fast machines.  Relatively quickly they started combining
the simple passes to reduce the running time.


George

-- 
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: Little language design/implementation guidance

[Neil Van Dyke]

George Neuner wrote on 2/7/19 12:43 PM:
No offense to Herman, but I think the problem with consulting experts 
is that there are relatively few language experts who are available to 
consult.


I suspect there's so very little *market* for such little language 
experts.  Some non-exhaustive suggestions of why:


* Reasons like you suggest.  (Is this person going to be sufficiently 
engaged to do it well.)


* Egos/opinionatedness/fun.  (What developer thinks they can't design a 
language and doesn't have some ideas about that?  And possible morale 
hit to team if pushed by manager?)


* How do you even evaluate skill in little language design, to find the 
expert.  (This doesn't seem to be as easily objective as "have added a 
new target architecture to GCC or LLVM".  It's soft/vague, and industry 
even has trouble vetting developer candidates for skills that supposedly 
the organization does understand, like basic software development.)


We can talk all day about how industry people should value some 
intellectual niche for consultants, but it might just be easier to just 
get a professorship instead (also nontrivial). :)  If you solve the 
consulting market problem, "https://www.neilvandyke.org/racket-money/; 
wants to know.


(Also, if someone has expertise in some niche technical 
(non-management-consulting) area, do they really want to be running a 
niche technical consulting business, or would they rather focus on doing 
great work in those technical areas, and just have gobs of money appear 
in their bank account (without dividing attention to constantly drumming 
up business, invoicing and work reports, tax accounting, professional 
insurance, sector compliances, solo 401k, etc.).)


I think every *serious* developer should read at least an introductory 
text on compilers.  Even if you never try to implement your own 
language, understanding what happens to your code when its compiled 
makes you a better programmer.


Definitely.  (Do pretty much all CS undergrad curricula currently 
include some kind of compilers/translation-to-arch?  And it's accessible 
to all CS undergrads, not an elective, nor a hated weedout?)


Separate from compilers and underlying architecture, and perhaps 
especially with "little languages" and DSLs, there's also the 
linguistics or even HCI side.  Which (depending on the language intent) 
is possibly entirely orthogonal to implementation.  What makes a good 
language for a purpose.  One thing that I suspect helps with this is 
experience with many different languages and approaches, so you have a 
breadth from which to draw, and some insight into them (not just 
book-learnin').  I assume it also helps to understand users of your 
language, what they know and want to do, and what you can convey


For the linguistic side, evaluation criteria might be hard.  (Do people 
qualitatively like using it?  What's the adoption, and how is that 
involved in merit or telling us what's good or bad about it? Controlled 
productivity/maintainability/defect metrics?  Does a particular employer 
use it, for whatever reason?   Does some quality of formal semantics or 
syntax say people should like this little language, and if they don't, 
they don't deserve such a fine language?  etc.).


--
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] Guide and reference

[David Storrs]

For what it's worth, I like having the Guide and the Reference be
separate things.  They have different purposes and trying to mash them
together is likely to make them worse at both.

The Guide is designed to introduce new concepts, give the reader basic
familiarity, and clarify edge cases.

The Reference is intended to be, well, a *reference*.  It is concise
and exhaustive.  It requires a certain degree of familiarity to
provide full value but once you have that familiarity it becomes
invaluable.  Perhaps there are places where a few more examples
wouldn't hurt, but folding pages of soft-walk introduction into each
section would be a waste.  Either it's at the top and gets ignored
when you're trying to look something up or it's inline and gets in the
way.

Perl has a philosophy that I think makes a great deal of sense:
Everyone is a beginner at some point, but no one is a beginner forever
and there are generally more non-beginners.  It makes sense to
optimize functionality and references for non-beginners and then
provide separate materials to help beginners become non-beginners.

On Wed, Feb 6, 2019 at 8:29 PM Hendrik Boom  wrote:
>
> On Wed, Feb 06, 2019 at 06:33:11PM -0500, Neil Van Dyke wrote:
>
> > I think RnRS came across as "too academic", like "Holy crud!  A
> > function return is a call!  OMG, we're all, like, cosmically connected,
> > man...  And a return is... a first class object?!  WTH!"  And the formal
> > semantics -- which a PL grad student might interpret as rigor in
> > underpinnings, could also just be intimidating and inaccessible to most
> > practitioners, or give the impression of an impractical academic exercise --
> > that might've been the lethal finishing move, blocking earlier mainstream
> > adoption.
>
> I was interested in Scheme a few decades ago as a small Lisp which I'd
> have to implement myself.  I could do tail-recursion.  But returns
> being first-class objects -- ouch.  I did not have the resources or
> methods to implement that efficiently.  Machine too small, and
> garbage-collection time wa already critical.
>
> Better methods are known now.
>
> I'd have an easier time of it now, but now, I wouldn't have to.
>
> -- 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.

-- 
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: Little language design/implementation guidance

[George Neuner]

This is a repost of a message sent through Gmane that seems to have 
gotten lost.  The original may show up at some point - apologies if you 
see this twice.




On Wed, 6 Feb 2019 16:25:47 +, Stephen De Gabrielle
 wrote:

>Dave Herman recently tweeted[1] that consulting a PL specialist was a
>good idea for little languages to avoid common foundational mistakes,
>specifically mentioning templating systems and configuration files.
>
>So when designing(or evolving) a little language:
>
>  - what beginners mistakes should you avoid?
>    (some in the subsequent tweets I’ve copied below)
>  - When should you consult a PL specialist?
>    (and how do you identify a PL specialist?)
>
>More generally, can you recommend resources a developer (without a
>background in language design) should refer to if they are building a
>simple templating system, application configuration file, etc. - that
>may grow into a little language?
>
>Kind regards,
>
>Stephen
>
>PS please forgive me if this is the wrong list for this question.


No offense to Herman, but I think the problem with consulting experts
is that there are relatively few language experts who are available to
consult.  Certainly there are those who are willing to answer
questions (at least well defined questions) but most likely are busy
with their own work and can't be expected to devote a whole lot of
time to helping someone design a new language.


I agree with all the pitfalls Herman mentions, and to them I would
add:

 - fascination with C-like or natural language syntax

 - avoidance of parser tools/libraries

 - picking a programming paradigm that is not well suited to
   the problem domain

 - not using an IR - trying to interpret or compile straight
   from source text

 - forgetting about debugging

These are just off the cuff - if I were to think about it for a while
I probably would come up with more.


I think every *serious* developer should read at least an introductory
text on compilers.  Even if you never try to implement your own
language, understanding what happens to your code when its compiled
makes you a better programmer.

A developer serious about creating DSLs might want deeper study of
both compilers and virtual machines [keeping in mind that programming
languages always are defined over a "virtual" machine (that then is
implemented on a real machine)].

YMMV,
George


 -
>[1] https://twitter.com/littlecalculist/status/1092160821944213504?s=21
>
>> It's frustrating that PL is considered such a specialization that PL
>> people only get brought in for big languages. There are vastly more
>> little languages everywhere. People often don't realize their little
>> language needs better underpinnings until very late, if at all.
>
>
>Common mistakes tweeted by Dave Herman in subsequent thread;
>
>> Scenario-solving: language design at its heart is figuring out what
>> your composable primitives are. Too often, people think of use cases
>> one scenario at a time and just sort of glue them together w/o
>> generalizing and simplifying.
>
>> Reinventing lexical scope: many systems start by using string
>> concatenation as their core model, instead of composing modules with
>> a rationalized notion of scope. Another common scoping mistake is
>> exposing variables as mutating a global scope.
>
>> Lack of abstraction mechanisms: when you don't think of yourself as
>> designing a language, you put up with boilerplate and copy-pasta.
>
>> Lack of strategy for general-purpose logic: ultimately most DSLs end
>> up needing general-purpose programming language—often it's in a
>> minority of cases but when you need it you really need it. The best
>> ones IMO have clear extension points and contracts with a
>> general-purpose PL

--
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: Is anyone using package 'handy'?

[David Storrs]

I should add that the changes are things that likely won't affect most
code.  For example, removing the deprecated functions and getting rid
of a number of places where a function "helpfully" flattens its
arguments, which often means changing the '*' version of the function
to be the primary version.

And yes, Greg H and James P, I know you're using it in the BMTC code.
You don't count, because I can verify that the changes won't affect
you. :P

On Thu, Feb 7, 2019 at 12:19 PM David Storrs  wrote:
>
> tl;dr  If no one is then I'm going to make a couple of breaking
> changes.  If someone is, I won't.
>
> Secondarily, is there a way to install a specific version of a package?
>
> Long:  handy is a collection of utilities that I've accumulated since
> I started working with Racket.  Due to lack of experience with Racket
> principles, I made some poor design decisions along the way, mostly by
> getting too clever with adding special-case handling.  I've been
> fixing some of these things as they got in my way and, in order to
> avoid breaking code, I've been doing it by creating alternate versions
> of functions (e.g. hash-aggregate* instead of hash-aggregate).  This
> is getting on my nerves and I'd like to sweep out some of the cruft
> and make it all more sensible.  If anyone is using handy, please let
> me know.  If no one pipes up within 48 hours then I'll release a new
> major version without backwards compatibility.

-- 
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] Is anyone using package 'handy'?

[David Storrs]

tl;dr  If no one is then I'm going to make a couple of breaking
changes.  If someone is, I won't.

Secondarily, is there a way to install a specific version of a package?

Long:  handy is a collection of utilities that I've accumulated since
I started working with Racket.  Due to lack of experience with Racket
principles, I made some poor design decisions along the way, mostly by
getting too clever with adding special-case handling.  I've been
fixing some of these things as they got in my way and, in order to
avoid breaking code, I've been doing it by creating alternate versions
of functions (e.g. hash-aggregate* instead of hash-aggregate).  This
is getting on my nerves and I'd like to sweep out some of the cruft
and make it all more sensible.  If anyone is using handy, please let
me know.  If no one pipes up within 48 hours then I'll release a new
major version without backwards compatibility.

-- 
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] How to start a program in pretty big

[orenpa11]

Ok
So there is no need to add   #lang  before I am writing the code.
Thanks,
Or


On Thursday, February 7, 2019 at 7:00:52 PM UTC+2, Matthias Felleisen wrote:
>
>
> As several people have mentioned in the past, you go into DrRacket and use 
> the Language menu to choose Pretty Big. 
>
>
>
> > On Feb 7, 2019, at 11:57 AM, orenpa11 > 
> wrote: 
> > 
> > Hi, 
> > If I would like to write a code in pretty big what is the first line 
> that need to be written ? 
> > Can I use  #lang  ? 
> > 
> > Thanks, 
> > Or 
> > 
> > 
> > 
> > -- 
> > 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...@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] How to start a program in pretty big

[Matthias Felleisen]

As several people have mentioned in the past, you go into DrRacket and use the 
Language menu to choose Pretty Big. 



> On Feb 7, 2019, at 11:57 AM, orenpa11  wrote:
> 
> Hi,
> If I would like to write a code in pretty big what is the first line that 
> need to be written ?
> Can I use  #lang  ?
> 
> Thanks,
> Or
> 
> 
> 
> -- 
> 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] How to start a program in pretty big

[orenpa11]

Hi,
If I would like to write a code in pretty big what is the first line that 
need to be written ?
Can I use  #lang  ?

Thanks,
Or


-- 
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] Fully expanded programs grammar: print-values

['Paulo Matos' via Racket Users]

On 06/02/2019 21:09, Shu-Hung You wrote:
> 
> 
> On Wed, Feb 6, 2019 at 9:42 AM 'Paulo Matos' via Racket Users
> mailto:racket-users@googlegroups.com>>
> wrote:
>>
>>
>>
>> On 06/02/2019 16:00, Shu-Hung You wrote:
>> > print-values is a normal identifier introduced by the racket/base's
>> > macro module-begin. It is a (private) function defined in
>> > racket/private/modbeg.
>> >
>> That's sort of surprising. I actually expected fully expanded programs
>> to be evaluable by the user. This obviously can't happen if it expands
>> to private functions.
>>
> 
> Actually, the fully expanded programs _can_ be evaluated by the users.
> It is possible to first expand an input program then pass the result to
> eval. The identifier has the right binding information, referencing to
> the private function in racket/private/modbeg, and that module will be
> instantiated because racket/base depends on it.
> 

Thanks for the clarification and reference. Actually after reading what
you said, it makes total sense and what I tried to do was completely
ridiculous. :)

-- 
Paulo Matos

-- 
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: read-from-string(-all)

[Laurent]

aha, here it is!
The closest form is then `(call-with-input-string str (λ(in)(port->list
read in)))'.
Thanks Sam and Alex!

On Wed, Feb 6, 2019 at 10:01 PM Sam Tobin-Hochstadt 
wrote:

> Also, almost that `read-all` function is provided as `port->list` from
> `racket/port`.
>
> Sam
>
> On Wed, Feb 6, 2019 at 6:25 AM Alex Harsanyi 
> wrote:
> >
> > (read-from-string "123") is equivalent to `(call-with-input-string "123"
> read)` while read-from-string-all can be replaced by:
> >
> > (define (read-all in)
> >   (let loop ([result '()])
> > (let ((v (read in)))
> >   (if (eof-object? v)
> >   (reverse result)
> >   (loop (cons v result))
> >
> > > (call-with-input-string "123 456" read-all)
> > '(123 456)
> >
> > although I am not sure it is a good idea to call read on strings
> received from the user...
> >
> > Alex.
> > On Wednesday, February 6, 2019 at 6:49:57 PM UTC+8, Laurent Orseau wrote:
> >>
> >> read-from-string and read-from-string-all are convenient functions, but
> they belong to the mzlib/string library, which is deprecated. I can't find
> an existing replacement in racket/string or racket/base. Is there one with
> a different name?
> >
> > --
> > 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.