AltME groups: search

One interesting related trick: The EXPORT keyword in R3 modules is 
done with a similar preprocessor in the MAKE-MODULE function. Just 
a few lines, and it works like magic :)

Bringing it back to dialects, I am serious with the Rebmu thing. 
 I'm fully aware it *looks* like a joke but it is not.

I'm not compressing random digits here, I'm trying to make a domain 
demo of a domain that people are (for reasons better or worse) rather 
interested in.

That's why I like the idea of unrebmu as an implementation strategy 
- it makes for a more impressive demo :)

I probably spent less than a week on that Rubol thing, which I think 
isn't a bad idea either: http://hostilefork.com/rubol/

I've a notion to build a business rules parser in Rebol. But as a 
self-taught hacker with no background in computer science, I'd welcome 
any advice on flattening the learning curve. The docs cover the low 
level parsing details well enough, but I'm looking for enlightenment 
on the higher level issues involved in designing a little domain 
level language. Given that Carl is pushing Dialects as the Big Idea 
in Rebol, it's surprisingly difficult to find much on the topic in 
the Rebol community. Or am I missing something? I'd welcome any Rebol 
specific or generic resources to help me get up to speed on the whole 
DSL thing...

For me, it is usually more difficult to design a meaningful dialect, 
than to parse it.

The thing that's interesting about business rules is the need to 
mix declaratory configuration with some functional-style code. So 
you end up with chains of reasoning involving a mix of data and code. 
Which is why I though Rebol might be a good way to go.

I guess I should take a look, at the existing dialects, but they're 
a bit intimidating for a newbie. What would you suggest as Best of 
Breed examples? Something not too huge, for preference.

Where are Carl's examples - you mean the stuff in the overview? It's 
pretty minimal. If there's something I've missed I'd appreciate a 
link

forth is a language ...  which also specialises in creating domain 
specific languages

Ah - I see what you mean. Thought that you meant that someone has 
implemented a Forth like dialect in Rebo.

A Dialect is not  related with specific coding  practices. You can 
use parsing or not.
It's just an interface. You should read the theory to begin with.

funny that most dialect start small then grow quickly, so there probably 
aren't a lot of smalish dialects around.

Gregg has a LOGO dialect I think ...

there is an exensive BASIC interpreter dialect, but that's also quite 
large as a learning curve.

Also, there's one on reboforces.com on a screen control dialect

there's a SQL dialect too

A dialect is an interface to hide code complexity. It's only that.

Screen control sounds good - not too big or wooly - I'll take a look. 
SQL would be directly relevant to my project, so I'll definitely 
dig that one out. Do you mean SQL-PROTOCOL or is there something 
more recent?

Maxim - thanks for the tip on the datattypes - the kind of in-the-trenches 
technique that a newbie like me would overlook.

another thing which helps is to be (rather) fluent or at least aware 
in how REBOL handles the evaluation of words and how to bind words 
to different blocks.


mastering this will help you go at a new level in your dialecting. 
 keep this for your second pass at learning if you're still new to 
REBOL itself.

Well, you guys have given me a good starting point, which is what 
I was hoping for. Have to sign off but I'll get my hands dirty over 
the next couple of weeks and maybe come back with some more specific 
questions. Thanks to all!

Geoff, don't be afraid to sketch out ideas of your ideal language, 
with different approaches and tradeoffs, and then posting them here 
for people to comment on. Language design isn't easy, and you can 
paint yourself into a corner, or make it too hard to implement easily 
by making it do too much. 


Start small and come up with the core ideas that define the feel 
of your language, and keep other questions in mind. What are you 
descrbing? What are the things and what are the actions? Do you need 
to refer to things you've defined within the dialect, or does it 
just pre-process and build structures for regular REBOL processing?

In fact, I suggested SINGLE? (see R3 chat #4330) and Carl took it 
up immediately. I use SINGLE? a lot.

Originally I thought, that the FUNCT function was quite adventurous 
doing a deep search for set-words. But, after using it a couple of 
times, it really looks like it does what is useful most of the time.

and you can specify a list of words, thus being entirely independent 
of the code inside.

So, you can define a global variable without using set 'xxx = yyy.

Here is my benchmarks:

benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]] ; == 0:00:01.094
benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]] ; ==0:00:01.484
my benchmark function runs the block 1.000.000 times.

I get different results
>> benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.455
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:03.753

strange..
>>  benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.468
>> benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.469
>> benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.469
>> benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.5
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.093
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.094
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.094
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:01.094

>> benchmark [context [a: 1 b: "xyzdddddddd" c: 3 d: a * c]]
== 0:00:14.423


>> benchmark [use [a b c d] [a: 1 b: "xyzdddddddd" c: 3 d: a * c]]
== 0:00:37.302

very strange.. I guess it's because of OS, hardware etc.
>> benchmark [context [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:15.048
>> benchmark [use [a b c d] [a: 1 b: "xyz" c: 3 d: a * c]]
== 0:00:11.11
for 10.000.000 times.

USE is a wrapper around a closure!. CONTEXT creates an object. Very 
different.

USE is just a helper function in R3. We use modules as the primary 
structuring model now.

Now if you created the closure yourself ahead of time, instead of 
creating a new closure every time (as USE does) then it would be 
faster.

blah: closure [a b c d] [a: 1 b: "xyzdddddddd" c: 3 d: a * c]
benchmark [apply :blah []]

HTML of new R3 doc pages has similar problems on most pages due to 
no urlencode of ampersand in urls and invald <th> declarations using 
old <tr> attrib values for vertical-align in a <th> element.  I would 
gladly fix ad hoc and you can fix your page gen tools (?) later

test: 42 ;  test:none  ;  comment { test remains 42 but no error 
unlike, say, simple undefined  testnone   That missing space looks 
nasty when test:none should have been    test: none           Is 
this a bug in R3?    test:none does not return none but instead returns 
  test:none

that's a bug:
>> test:none: 1
== 1

>> test:none
== test:none

I don't think it is a bug, test:none: is a url.
>> test:none: print "x"
== x

if it would a set-word then it should give an error like "test:none 
needs a value"
x: print "a"; == x needs a value
>> ? test:none:
== test:none: is an url

a tolerated bug in R2 becomes a revered feature in R3, no?   If that 
is not a bug, then I may be the pope.  Or is it "the caprice of the 
colon", otherwise known as 'the big C" ?  You must excuse me, Jon 
Stwarrt just explained that science is faith and I am still in awe.

RobertS, it's not a bug even in R2.

has find/all been discussed in relation to R3?  I think its a huge 
gap in REBOL.   maybe there's another function for this, but I'd 
rather have it "close to the source".

No conversion functions yet, if that is what you mean. No struct! 
type as well, but that was a given. You can pass pointers to structures 
around as the handle! type, structure data in the binary! type, and 
convert using extension functions, or even REBOL code for binary! 
data.

If you want a great set of conversion functions start writing them, 
and get others involved for the advice and help. You might consider 
starting with the conversion blog here: http://www.rebol.net/cgi-bin/r3blog.r?view=0317#comments

A quick poll .. who is actually working on end user projects using 
R3 now??

GUI: This will result in a bunch of styles we need.

DB: Either we use SQLApi+ or OpenDBX to get access to a bunch of 
databases through the same interface.

Did you create a sqlite3 binding for R3 ?

We will publish this extension as soon as we have used it in a real 
life (internal) app to be sure it works.

Not using R3 for anything.

Reason: lack of energy. Illness took me down to about 1% of my programming 
capacity since about a year ago. Just starting to increase again 
recently.

a textfield? ;-)

Peter, agreed, there are a bunch of related TRY and unwind bugs that 
need fixing. It's not blocking me as much as the PROTECT bugs, but 
it's there.

Anton, that explains a lot, sorry to hear about the illness. Glad 
you are recovering :)

Fork mentioned FUNC vs. FUNCT naming issues.


As far as I am concerned, I am quite content with FUNC instead of 
LAMBDA as other languages using this construct "promote". Regarding 
the FUNCT name - as far as I remember, the FUNCTOR alternative was 
considered, but it looked impractically long for a common usage.

lambda/functor

 are better choices than "func/funct" because they aren't totally 
 made up.  But while they are not "warty" they are still "scary". 
  And most of Rebol is not that scary...with a few standouts (the 
 "re-" functions like rejoin and repend, and the /only refinement)

for you lambda is not "totally made up"? for me it is, it does not 
have any sense except in a narrow community

fork, I undertand your gripe with /only.   but I'd rather have 'Only 
one refinement name to remember for all of the less processing fringes 
cases, than a different one for each of them... even in my code I 
use /only..... everytime I do other wise, I end up cursing, cause 
after a while I forget the refinement name and loose time looking 
it up.

macro

 is a bit of a loaded term in languages (as some people would assume 
 "preprocessor macro" and not something more like "application scripting 
 macro").  But it looks friendlier and people would be less surprised 
 when set-words wrote into containing contexts.

The existing FUNCTION is a waste of the word and does nothing you 
can't do with /LOCAL so I really wish the mistake of using that word 
for it would be admitted and give it to FUNCT.

Just to ease anybody's statements, that R3 will "require complete 
rewrites of existing code" - the change from R1 to R2 was much more 
"disruptive", as everybody can easily find out, and even then, a 
lot of code did not cease to work.

Rebol has a unique power to rework such things retroactively.  It 
would be possible to do a search/replace of FUNCTION in existing 
files with LOCALFUNC and then define it to behave appropriately in 
your R1/Forward, R2/Forward, etc.  My question is whether the unwillingness 
to bite such a bullet is worth the speed bump of explaining to every 
single user of Rebol in the future what a "FUNCT" is, forever... 
and ever... and ever...

People have to start using systems before they completely understand 
them.  The knowledge comes in bits.  Understanding of FUNCT (by whatever 
its name) is indeed necessary, but you often want people to be able 
to smile and nod as if they understand parts of a codebase that aren't 
immediately relevant to the point you're demonstrating.

The only function name I hate in R3 is FUNCT.   it doesn't read well, 
its not a proper abreviation, its not cute... its just look like 
a truncated word and is totally obscure in meaning.

I'd rather use something purposefully obscure like FCT.


if you're going to make a name shorter for the sheer reason of making 
it shorter... at least make it different.  


I would much prefer FUNCTOR.  its obscure, yes, but caries a sense 
of "find out what is the difference".  'FUNCT will go unnoticed for 
the majority of users.

I wouldn't mind if FUNCT was a shorthand for FUNCTOR.

Rebol doesn't make a habit in general of short names, and when it 
does I always wonder "why those".  Found some odd ones while working 
on Rebmu:

I like to feel like there's some matter of principle driving why 
the language doesn't define "app" for append or "rev" for reverse 
by default.  So yes, I'd use natural language as the reference in 
this case, but only because it seems like a convention which is *almost* 
followed but with these few exceptions that do not seem necessary.

I feel like it's almost possible to teach people non-idiomatic Rebol 
and have it make sense from the get-go, where you can really focus 
on the code.  There are ways to keep from triggering "WTF" responses, 
like putting in parentheses when they're not strictly necessary. 
 And it seems so close that it's a shame the last little bit isn't 
done.

experienced programmers have learnt to accept idioms like the requirement 
of parens on function calls.


they have to understand a different set of idioms.  "unlearning" 
that some of what they perceive as "fundamental" in programming is 
hard.


new programmers will have it the other way round if they learn REBOL 
first... why do we needs comas, and parens everywhere.... seems like 
waste.

Depending on how you are presented with something, the "unlearning" 
can be either a joy or a suffering.  Put a kid on a bicycle with 
no training wheels and they fall and get hurt and they might not 
appreciate bicycles very much.  Give them some training wheels and 
let them get comfortable and be happy the day it comes off.

yes, but its still a bicycle. start them of on a tricycle and none 
of what they learned there it is usefull.  on a tricycle, if you 
lean you fall. on a bike, if you don't lean you fall.

Since I was unable to get an answer to my question:


I want to ask you a question related to your refinement-arguments 

initialization" (actually, it is not initialization, but "unused 
refinement arguments", like the /local arguments are usually preferences 
(see the wording of my answers at http://stackoverflow.com/questions/3168226/how-value-function-really-works
)"


from RebolTutorial messing the thing up with a purported incompatibility 
between FUNCT and FUNC, I guess, that this is the place where the 
question would be at least understood. So, is there anybody actually 
preferring the "unused refinement arguments" to be unset, than to 
be set to #[none] at every function call?

so many coding patterns depend on it
 - is that a general sentiment here?

I have a counter question.  why would be set them to unset!  ?

though I (and many others) often use none, to indicate the use of 
a default or fallback value.

ah, but here you actually supplied unset to the function.

in a way, its not the same as not specifying the /refinement.

but the use of  any-type! is what specifically allows this "trick".

R3 removed the ability to not supply arguments...

>> a: func [x [any-type!]][value? 'x]
>> a
** Script error: a is missing its x argument

R2's behavior has always worked well for me. Unset is the special 
case I avoid unless I really, REALLY think there's a need to leverage 
it. I very rarely use any-type! for that reason. I like declared 
locals being NONE. I can't think of a time I tripped over using a 
refinement without passing its arg, but there unset would have to 
be intentionally expected as well.

Well, anyway, because of this, RebolTutorial completely ignoring 
any explanation makes a bad publicity to Rebol stating that "FUNCT 
and FUNC are incompatible", which is just nonsense.

ok, but that is a fringe case which probably got put there specifically 
to allow that specific pattern so that some command-line functions 
can be simplied... 
its not the intended use of Rebol.


argument passing by reference is rarely used (a few mezzanines and 
highly specialized situations)

Agreed. And things like the R3 behavior for a missing arg when using 
a lit-word! param versus a word! param would be good to note in the 
FUNC docs.

I think Ladislav dislikes lit-word params anyway, as they are a pain 
when generating code, but they make for good examples and thought 
experiments.

yes, I agree completely.  this is now an intended setup, not an interpreter 
loophole leveraged as a feature.

And, in my opinion, this actually *is* a gotcha for beginners

so yes... the value?  help string makes sense... its defined as a 
local within the function, as 'FUNCT is supposed to do automatically.

defined as a local

 - yes, that is true, but in my example below, 'x is clearly defined 
 as "nonlocal", yet the function yields #[false], in accordance with 
 its help string:

>> g: func [] [[x:] value? 'x]
>> g
== false

A little note about FUNCT vs. FUNCTOR: The word "functor" has a specific 
meaning in computer science, and that meaning is *not* what FUNCT 
does. There is no standard CS term for what FUNCT does, nor is there 
a standard English term. Any word we use would therefore have to 
be made up. FUNCT is not a bad made-up word: it's short, which is 
good for a function that will be used often in user code, and it 
starts with the same letters as FUNC and FUNCTION without being either 
one of those words.

actually Lad, if a word is defined but stores a value of unset!  
(like what happens above with the [x:]  value? returns false.

We actually had a function called FUNCTOR for a while, and it really 
created functors. And it went unused for more than a year, so we 
dropped it. It turned out that what FUNCT does is really useful, 
even though the concept is unique to REBOL. Apparently functors aren't.

FUNCTs and FUNCs are both procedure builders. Neither create functions. 
It's a common naming mistake in imperative languages.

Then it isn't like FUNC, and people are more likely to misunderstand 
the difference. It really is a unique concept, certainly nothing 
like the proc concept in other languages that have that term.

I think proc would make things even worse. Nothing would indicate 
that FUNC and PROC are basically the same, except for a minor (but 
important difference). And choosing which does which is absolutely 
arbitrary.

I'd probably stop using func most of the time, and I can't see myself 
typing funct  20 times a day.


everytime I write it, I feel like I'm writing a less savory femal 
genital word in a strange dialect of german ;-)

Maxim, nothing in REBOL corresponds to a closure, though the closure! 
type is closer than other function types, and many other languages 
call something similar to that a closure too. We don't have contexts 
(though "dialects" are close). Neither FUNC nor FUNCT build real 
functions, but they both build what other imperative languages incorrectly 
call functions, so people won't get confused.

Which is also its most prominent shortcoming, as readers pattern-match 
better at the beginning of a word then at the end.

I have two reasons why I like keeping FUNC the way it is:

- FUNC is the simplest function-creating function, so giving it the 
shortest name seems appropriate.

- As a rule, we prefer to not rename old functions and then give 
their old names to new functions. That would be user-hostile.

yes, but its a refinement, and even then, it still acts "locally" 
within that object (I'm assuming its using function locals on words 
in didn't bind to).

(And FUNCT/WITH would warrant a discussion on it's own.)

OK, nevermind, it is a detail anyway