Could Rebol syntax adjustments attract newcomers?

Development
1

In the category of "rebol language design" - curious if this has ever been discussed:

I myself am somewhat new to Rebol though I've done some Racket and played a little with Clojure etc. so I have a tiny leg up learning lispy style languages.

But for those that don't have such a background I've always felt these languages are difficult just cause they're so different, and the syntax is part of that (not all but part right).

It strikes me that Rebol is already more approachable than a classic lisp/scheme - that there's truly fewer brackets than there are parens in lisp. I guess that's because of not using them for function application plus they're often implicit at the top level right.

But was there ever a thought at making some small syntax adjustments to align more with the C/java/javascript syntaxes that are most popular so easier to read for greater numbers of people?

The first thought along these lines is the use of curly braces for multiline strings - that to me seems a lost opportunity when having allowed { } as an alternative to [ ] for code blocks would have helped the readability to newcomers from these other languages.

(Racket allows { }. ( ), and [ ] as equivalents btw so there is precedent out there fwiw)

Following on that, if commas were treated as whitespace (Clojure does this), then along with the curly braces, unless I'm missing something (I might be) it seems to me you'd be able to paste JSON directly in Rebol... I work with RESTful JSON services all the time so maybe I'm biased but I'd think it would be appealing to be able to be able to say that Rebol supports "JSON on steroids" (i.e. a superset of JSON when you consider the other types Rebol allows beyond the basic ones in standard JSON).

Anyway I could go on (I played with these ideas in an open source project I'd started called "SugarLisp"), but you get the idea. :slight_smile:

I know amoungst Lispers these ideas are not welcome but I always feel bad these languages never seem as popular as they deserve to be.

A similar idea I've been looking at recently is called "ReasonML" it's a new language from facebook where they did an alternative javascript-like syntax on OCAML to try and make it more appealing to JS people...

I'm assuming these ideas aren't easily done as a Rebol Dialect alone right. I'm assuming it would either be a preprocessor or a variation on one of the Rebol implementations with a different file extension or something in that Rebol header since such changes (i.e. the curly brace one) wouldn't be backward compatible?

Partly just wondering what people think. I'm guessing people who know Rebol well wouldn't like the idea, but again - it's not for them, it's for their java/javascript swilling cousins. :slight_smile:

2

I'm not sure how well-received syntax changes would be to the core language, but I am interested in an aspect of dialects where a user or programmer can interact with a different syntax/semantic facade while rebol/red interprets and executes the expressions behind the scenes. I think custom DSLs for workflow tracking and process control could benefit from an approach like this.

3

I do not think that this is necessary. A really good ide will that gives users a powerful first impression will be all that is required, imo. Few programmers are willing to fire up the command line and mess around with text editors. Ren Garden is the answer, and that is going to be a simple download kiss solution very soon.

4

Hello Darren,

The first thought along these lines is the use of curly braces for multiline strings - that to me seems a lost opportunity when having allowed { } as an alternative to [ ] for code blocks would have helped the readability to newcomers from these other languages.

I'm a pretty big fan of having asymmetric string delimiters.

print {"It's actually the case that curly braces for strings,"
    said @HostileFork, "give Rebol some of its unique character
    in terms of cutting down on escaping."}

 print { int foo(int x) { if (x > 10) { printf("foo"); } } }

It lets you use the full range of quotes and apostrophes, and even to use curly braces in your strings so long as they are paired.

If anything, our problem is that there aren't enough asymmetric delimiters in ASCII, so we end up having to create "dictionary" literals with things like #(a: 10 b: 20). I've wondered if <<a: 10 b: 20>> would be better, perhaps even tolerating the unicode form « a: 10 b: 20 ». :-/

So making equivalences just for a new user's visual comfort would be wasting an already scarce resource. I think once people observe the value of the asymmetric string delimiters, they'll be happy enough to learn the brackets.

One thing that has been on the table, which I like, is the idea of using # pound plus space as a comment character. The ; is too hard to notice, and workarounds for that people use aren't great:

;; too fractured and dotty/noisy
;-- not much better, and doesn't mix with code

Syntax highlighting helps, but I think the high level of success # has experienced for this purpose indicates that it could be a good change.

5

Welcome to the board! :slight_smile:

So, if the advantage is fewer brackets, why add them back in again? Javascript is popular because it's the only language that one can program web applications. It's popular by necessity.

We have looked at the comma question and haven't been able to resolve it yet

6

I'd rather see Rebol's core language continue with simple syntax, but along with @BlackATTR I would welcome "language toolkit" features that help with loading/manipulating/interpreting/resaving non-native syntax/formats.

Rebol2's load/markup was perhaps a small step in this direction but it was quite underdone. The C token scanning in the Ren-c build process shows that even if you don't load an entire language, loading some of it is still useful.

Perhaps newcomers would be attracted to a language that could access other syntaxes while at the same time quietly convincing them to transition to a more human friendly syntax?

7

Thanks Jacob I'll keep an eye out for Ren Garden. I watched some of a youtube video showing it, it does look good I esp. like some of the variable watch stuff.

(which reminds me - I've not seen a single step debugger for Rebol is there one stepping code has helped me learn new languages in the past)

8

@hostilefork re:

I'm a pretty big fan of having asymmetric string delimiters.

print {"It's actually the case that curly braces for strings,"
    said @HostileFork, "give Rebol some of its unique character
    in terms of cutting down on escaping."}

 print { int foo(int x) { if (x > 10) { printf("foo"); } } }

It lets you use the full range of quotes and apostrophes, and even to use curly braces in your strings so long as they are paired.

For a moment I thought your examples showed I'd missed something about curly braces in Rebol that they are truly a "block" of strings or something.

e.g. that they would let you escape out and inline rebol code expressions in the middle of the strings. like the quote/quasiquote stuff in lisp/scheme, or (simpler) the ES6 "template strings" like hello ${nameVar}

Rebol doesn't have those right - but I guess it's not needed since ["hello" name] is just as short right.

9

@all I enjoyed all the comments it really makes me want to learn Rebol much much better I'm truly just a beginner. I've mostly just been skimming the surface feeling I see Rebol's potential.

e.g. I do see the value in the GUI dialects I've done a lot of "back office" internal-use-only apps in my career where the UIs just had to function they didn't have to be super super pretty - so I love how short the Rebol GUI programs are! Even if they're not always the most pretty. I do see them as a practical solution to a real problem that many businesses I've worked for have. Esp if the cross platform support (ideally including browser) were fully there (and if there was maybe a little of a UI makeover with some of the default look).

But all your comments also made me recognize I should confess: for me personally the languages I've used most in my career have been C/C++/Java/Javascript, and I've most often been surrounded by people who likewise were most familiar with those languages as well.

So I'm sure I have a bias that makes me like these syntax sugar ideas.

I imagine myself getting better with Rebol, falling in love with it even, and the next thought is - will I be able to persuade my coworkers to use it?

So I'm admitting - for me curly brace for code blocks, // or /* */ for comments would be most beneficial. Not so much for me since I'm motivated but for persuading others.

OTOH I've heard syntax compared to "fashion" right.

And regarding @Brett and @BlackATTR - I love how the Parse stuff lets you extend and customize what Rebol gives as standard.

But I'm just a Parse beginner - is it capable enough to do a full blown arbitrary syntax "language" transpiled to Rebol?

e.g. Doesn't it separate text parsing versus the more grammar like approach that assumes you're dealing with "words" i.g. that are pre-tokenized using Rebol's mostly white space delimited syntax rules?

Or can it handle truly arbitrary syntax e.g. where things aren't always white space delimited?

10

I'm not the best person to respond from a Red/Rebol programming perspective-- I'm not a programmer. This topic is highly subjective but I'll share my personal thoughts.

As much as I love the rebol lineage, I don't think much about Rebol/Red in terms of rising popularity. Most programmers are taught the ALGOL/curly-brace languages. Those languages are fast, compiled in some form or static. It's where the biggest communities are, the $ is, the marketplace ecosystem is. The IT production toolchain is designed to work with these languages in IDEs and with large global dev teams in mind where devs can wire-together libraries of code or frameworks without understanding the code. Outside that circle there are others interested in pure functional languages, usually for parallel/concurrent programming-- again something that Red/Rebol are not really targeting.

Red/Rebol are so different as to be largely off-the-map. You know how the above programmers complain about Javascript -- it's too dynamic, no compiler, too much happening at run-time? Well Red/Rebol take a calculated "Damn the torpedoes!" approach: How far we can push dynamic interpretation? How far is too far? And what can we do with a language that slippery, a language that gooey and melty?

And I think that's what makes these languages so interesting. I think the Red/Rebol evaluation model + Parse should make it the most dev-friendly language for DSLs ever produced. Apart from its basic utility, I think that's the most unique benefit of its radical ideas. Red takes that further and trains its sights on full-stack development and Android programming. Ren-C embraces the "how far is too far?" ethos like a rabid maniac. I can't wait to see the jaw-dropping witchcraft that project produces. (You want curly braces? HostileFork is the guy you wanna talk to.)

I doubt Red / Rebol will play well with teams of (modern) factory-style software devs. Redbol is more about empowering individual developers and putting a simple syntax over as much compact power and utility as possible. I have hundreds of Rebol scripts for file munging/data-wrangling that I use at work, but I'm in the process of writing an extensible SQL-like dialect in Red to provide a more business-friendly syntax so my teams can take more ownership.

I'll let the Redbol gurus answer about transpiling. I think the answer is "Yes", but suitability depends what you're trying to achieve and how much work you're willing to put in. Could a Redbol dialect be used, for example, to compile to Javascript, or another language -- or act like a vm a la Elixir for Erlang (or Kotlin, Scala, Closure for Java)? Depending on the syntax, you may need to parse source from strings because the code/syntax is un-loadable in Redbol. That's doable, but there's probably a spectrum where some things are much harder than others, at which point you need to ask if the juice is worth the squeeze.

11

See this help example on reword on how to use template strings.

12

Before I used Rebol I'd never parsed anything - didn't know much about it. Rebol's Parse made the concept accessible and easy to play with.

is it capable enough to do a full blown arbitrary syntax "language" transpiled to Rebol?

I don't know about any language but one can do a lot with Parse. "if the juice is worth the squeeze" is the right answer and I'd like the squeeze to be a little easier :slight_smile: because sometimes beyond utility, it can actually even be fun to extract information from other formats into homoiconic Rebol.

Yes Parse has a text parsing mode and a block parsing mode. One can use the text mode for scanning tokens into Rebol values a block and re-process that, or other strategies.

Some years ago I wrote a script to extract and transpile (well 90%) Augmented Backus–Naur form (ABNF) rules embedded within internet RFC documents into Rebol parse rules. I don't pretend that my method is the best way to do this, but I think it demonstrates that one can do some sophisticated things with Parse including dealing with arbritrary syntax.

1 Like
13

Thanks for all the interesting replies seems like you guys have a really great helpful community around Rebol and Red!!

atm you guys motivated me enough to put aside my pie-in-the-sky ideas and learn more of the basics re the Rebol/Ren-C/Red differences and just basic tutorials with the GUI and Parse dialects.

14

Parse itself is just another dialect of rebol. With parse, you can execute arbitrary rebol code at any given point, in any given rule. You can redefine how parse is parsing on the fly by redefining the rule it is using. You can build a parser on top of parse... basically, your imagination is the limit here. If you have the will power, you can make it work with anything.

15

I think Rebol does need some literals for OBJECT! and MAP! datatypes. So perhaps Rebol may adopt Red's #() map literal? At moment the Rebol jury is out on that one!

Like @hostilefork I do like Rebol/Red's {} multi-line balanced string literal. I did once have idea perhaps using {{ ... }} (can use any number of multiple matching curly braces) for multi-line STRING! to free up {...} for OBJECT!. It's a big change though and haven't even convinced myself yet!

COMMA! datatype has been discussed a few times before and is something i do like look of. So [1,2,3] would PARSE has [integer! comma! integer! comma! integer!] but would be treated as whitespace by DO evaluator: [1 2 3]

16

re: unicode literals

I'm certainly not against using unicode characters for new literals.

Perl6 uses « ... » literals. But for each unicode choice it has an ASCII fallback called Texas. So << ... >> can be used to mean same thing here.

Another unicode block Perl6 makes use of is: ｢ ... ｣

re: semi-colon comment

I'm very happy with semi-colon for comment. In Lisp world there is a clear convention on how to use them - http://mr.gy/ansi-common-lisp/Semicolon.html

17

I would prefer that the map data type be #[] instead of #(), however, I have no objective reason for this. I like regular syntax constructs if we are using special character designations, otherwise I like for the data structure to have a unique way of being written. Since the block is the most commonly used structure, it "feels better" for it to be used with a map, unless someone can figure out a unique syntax for maps.

18

That hasn't stopped others from commenting! :slight_smile: It seems to me you have a firmer grasp on the lay of the land than most. So no worries.

There's a lot. I give the examples like:

+: enfix function [a [<end> any-value!] b [any-value! <...>]] [
    if set? 'a [ ;-- there's a value on the left, not <end>
        add a (take b) ;-- normal add of one right hand value
     ] else [ ;-- nothing on left, switch to variadic sum
        sum: 0
        while [not tail? b] [
            sum: add sum (take b)
        ]
    ]
]

Woo. Now you have:

>> 1 + 2
== 3

>> (+ 1 2 3)
== 6

Please do come chat if you have not yet, the witchcraft continues developing...



Programming is a large market, and it's only going to grow more.

If you observe the history of things, increased productivity and task specialization creates more leisure time. "leisure programming" is something of a niche today...though of course I am one of the weirdos who is into it:

...but I theorize that AI, especially, is going to love this kind of thing. It's a sport of the future. (Maybe just dumb AIs, but note a lot of people watch NASCAR today. Why couldn't this be wildly popular too?)

Bingo.

I spent my early career in software in a "let's formalize the world" mindset... wanting better tools. For everything: I'd blame pencils for why I couldn't draw, noticing how much more you can do with a computer when you just give your specification and let it draw. When I thought about how drawing programs should work, what I envisioned is a lot like how SolidWorks acts, you give it constraints and intents that can adjust as your thought process changes:

And the slow tendency of things to formalize brings more and more of this to programming, as C evolved to C++, or as people try and make Haskell "do things".

When you think about projects worked on by multiple people, these abilities are critical. I used to work on trying to get this aesthetic into the editing environment for code, itself:

But to continue the drawing analogy: I got more interested in aspects other than psychic tools...what it meant to not use software at all, or to use software that was focused differently. The ability to draw unconstrained and know what that was. I think that there may come a day when all the conventional wisdom about what it takes to do "correct" software engineering would feel restrictive...

So in my mind, the job here is to give future Picassos who have been working in SolidWorks their whole lives their first paintbrush. Rebol was the first interpreted language I didn't hate (time and circumstance meant I kind of missed Lisp)...and I think it can be bent to have a timeless character, if people are patient enough with it.

I don't know. But I do know that I appreciate Rebol most when I'm being forced to use something else.

3 Likes
19

Unfortunately #[] is currently used for the construction syntax and I expect it will take a lot of work to change this :frowning:

But like you #() just doesn't seem right for MAP!. Based on above restriction I'd prefer %[] for MAP! and perhaps ![] for OBJECT! (and I'd be happy with these even without Plan -4)