AltME groups: search

Why would you write

a,


? Comma is not allowed in words. I wondered about this some months 
ago, like if Carl had some future idea for the use of comma!?

Brian, ah ok.


As : is not allowed in words, that url example should be ok. But 
I'm wondering, why comma isn't allowed in words, as point is.

>> a.: 1
== 1
>> a,: 1
** Syntax error: invalid "word" -- "a,:"


I don't see the reason, other than if Carl has some special future 
idea for comma.

The comma is so bad syntactically that throwing an error every time 
someone tries to use it is considered a valuable feature.

Plus, having something as difficult-to-see as a comma in any syntax 
role is considered a bad thing. REBOL syntax didn't come out of nowhere 
- these choices were maade for good reasons. It's why we don't use 
periods as well.

If you get it, like to describe in #537, what should this return 
then?

transcode "a,0"

[a ",0"]

and

reduce [a,0]

ok, I'm not too familar with transcode. Let me make another example. 
This works today:

>> load "a ,0"
== [a 0.0]

What should this return:

load "a,0"

Sounds like it should return [a 0.0].

Steeve, a period is usable, but not used (in general). And the period 
being usable is likely why the comma is an error.

comma can be _used_ in words, but not in words that have to be serialised 
and then reloaded

    to-word "a,"    ;; this works  
    == a,

    to-word ",a"   ;; there are some limits
    ** Syntax error: invalid character in: ",a"

Don't serialise and reload O:
    o: make object! reduce [to-set-word "a," 1]
    == make object! [
        a,: 1
    ]

Sunanda, TO-WORD "a," being allowed sounds like a bug. Report it.

It's the general thing, we've talked a bit about before, that TO 
some datatype should put the result through LOAD or something, so 
valid REBOL comes out of it.

But it's R2 compatible :)

There are other edge cases -- Latin-1 chars that can be _in_ a word 
not not _start_ them, and do not serialise well.....I did a script 
and found them all once

We've already put restrictions on the character set of words - Sunanda 
just found a hole in those that needs repairing.

I could use 8-bit danish letters in my REBOL source, if I would:

>> æble: "apple"
== "apple"


But I don't do it. I'm not sure, if it's a good idea to allow this. 
I guess, 8-bit values are allowed, because it makes the lexer faster.

Sunanda, #1167 created for that to-word "a," error.

{Is there a problem with getting operators?

>> get to word! "="
** Script error: = word is not bound to a context}


This is not operator-specific, no variable can be handled like that:

a: 1
get to word! "a"
** Script error: a word is not bound to a context

{>> get to-word '=
== op!}

- in the above code the usage of TO-WORD is just a no-op

{so making string to words and making lit-words to words isn't quite 
the same, it seems!?
>> (to word! '=) = (to word! "=")}

- again, the first TO WORD! is just a no-op

{What's the need for QUOTE, when we have the get-word syntax?} - 
it serves a totally different purpose, e.g.:

quote (1 + 1) ; == (1 + 1)

for comparison:

first [(1 + 1)] ; = (1 + 1)

(1 + 1) ; == 2

another QUOTE:

quote  'a ; == 'a

(another way how to obtain that would be e.g.):

first ['a] ; == 'a

I *really* like the new :a parameter behavior in R3 that makes QUOTE 
possible :)

{while other operators work ok as lit-words:
>> '=
== =}


- just a note; in the above example there is no operator, just a 
lit-word, that is handled as "valid" by Rebol loader in this case 
(as expected)

I wasn't aware, that this doesn't work in R3:

get to word! "a"


So it's not a problem with operators, but a general change. The above 
code is valid R2 code. I can't judge, if it's a needed change or 
not, but it will trigger thoughts about R2 compability. I guess, 
the change will break a lot of R2 code!?

I see. Does it make sense to not bind words by default? I feel, Carl 
might have a blog about this. :-)

I think this was quite a big topic a while ago. It has something 
to do with modules.

I came across another funny thing. Are << and >> planned as operators?

>> ? >>
No information on >>

So >> is a valid word. But >>> is not:

>> ? >>>
** Syntax error: Invalid "word" -- ">>>"

Yes, it makes sense to not bind words by default. Carl has written 
many blogs about this, going back more than a year.

There is no one shared global context anymore, so which context to 
bind to is a policy decision. Default needs to be unbound to do this

>> and << are likely allocated for user-defined operators. Please 
don't allocate >>> and <<< - it would be too hard to discourage their 
use if they are allowed syntax. We don't want REBOL to become a write-only 
language like Perl.

Any reason why NONE acts as an honorary empty block in each of these 
under R3:
    a: none forskip a 1 [print a]
    a: none forall a [print a]
    foreach a none [print a]
R2 would not be happy!

Logical, maybe. Harmless, perhaps. But odd ..... and inconsistent 
with REPEAT:
    repeat a none [print a]

    ** Script error: repeat does not allow none! for its value argument
So I am wondering if it is a deep feature, or an oversight.

Thanks -- I'll add a curecode so the possible oversight is on the 
checklist.

I'm wondering now if there will be easy ways to check whether a char! 
is: lowercase, uppercase, a number or an international char.

Carl seems to have done a great job with Latin characters:

>> uppercase to string! #{C3A0}
== "À"

>> lowercase uppercase to string! #{C3A0}
== "à"

>> uppercase to string! #{C48D}           
== "\u010c"

There seems to be some problems with other alphabets though:

>> uppercase to string! #{E382A1}         
== "\u30a1"


\u30A1 is a small katakana letter A. The unicode for a caplital katakana 
A is \u30A2

Pekr - it is actually an a with a grave accent over it in UTF-8

hmm, should uppercase and lowercase really work with katakana and 
hiragana? the "small" versions have a completely different meaning 
and usage than our "lowercase" has.

I think it's mostly a sign that we are reaching the end of this tunnel 
on plugins :)

Since the plugins only export 3 functions from their library, and 
dispatch calls to commands from a single function, I could add new 
commands at runtime as long as that function has some way to make 
sense of their indexes. Then I could make a plugin that wraps a JIT 
compilation library like libjit or libtcc.

http://tlt.its.psu.edu/suggestions/international/bylanguage/japanese.html


To elaborate on what Gabrielle said, in most languages, there is 
a large and small version of letters for use usually in sentence 
case, and also for abbreviations, etc.  Over time these began to 
be written differently, so the large and small actually look different.


But in Japanese, small letters have a completely separate meaning, 
sometimes used to elongate a sound, or form a subtle guttural stop.

Here is a sample, it is VERY subtle.


http://christopherfield.com/translation/images/hashiriame/story_a.gif


In this image look for all the symbols that look like a backwards 
letter "C" (or letter "U" that fell to the left).

Sentence 1 - 3rd from the right.
Sentence 6 - 3rd from the left.

Notice they are very subtle different sizes.

That is an example.

Bottom line, as stated, don't mess with caps with Japanese.

(it was hard to find a GOOD example of this in the same image).

This could be an advantage - there are many languages that support 
capitalization as a concept, but many that don't. The ones that don't 
have more characters than the ones that do (I'm guessing). This means 
that we could use smaller tables/code to do the capitalization in 
LOWERCASE and UPPERCASE - valuable space savings for a tiny language 
like REBOL.

Is the a replacement for read/lines?

I will reword my question.  In R3 how can I read in one line of unicode 
text at a time to process it?

ah, damned, read/lines. What a crap :-)

Louis, there may be a solution to your problem that involves direct 
port access, rather than a READ refinement...

Annoying isn't it? Have you submitted a wish to curecode.org?

For now, I use something like this:
    reduce [x: now/time x/hour x/minute x/second]
    ==[12:30 12 30 0]

I think its a good idea!

I just spent a few hours trying to debug someone else's code ... 
and this was the cause.

to-itime is only really good for consistently printing time, for 
example for a running clock.

How can I check if a word exists without incidently creating an entry 
in the word table for it?
eg this does not work as the act of finding creates the word:
    find words-of system/contexts/user 'no-such-word
    == [no-such-word]

Sunanda, I haven't checked, but to word! with a string might work, 
as it does not bind.

Slowly like this :

>> probe words-of system/contexts/user
[system a words-of contexts user to string! find context probe]

== [system a words-of contexts user to string! find context probe]

>> find to string! words-of system/contexts/user "no-such-word" 
== none

>> probe words-of system/contexts/user                          
[system a words-of contexts user to string! find context probe]

== [system a words-of contexts user to string! find context probe]

Thanks for the clarification.

Can we test if a word exists without creating a junk entry in the 
internal table?

You probably don't need to worry about creating entries in the symbol 
table though. Word lookup is constant-time, and there is no effectve 
upper limit to the number of words it can hoid - you'll run out of 
memory in a 32bit address space first :)

Thanks Gabriele. 32K is getting useful. Sadly, for me. I support 
an elderly View system with a limit of 4100 (or so) words. It gets 
tricky at times :) (I guess we;re off topic for R3 here)

I just discovered that rebol3 can escape a forward curly brace as 
in  str: {text^{}

Is there any way to get  ^{ as an escape comparable to ^}  into rebol2.7.6 
?  2.7.7 ?  Otherwise generating string comtaining both dbl-quote 
" and curly-braces seems quite maddening ...  when using REBOL on 
server-side what is easy in PHP or PERL is suddenly a challenge ... 
or am I missing something about wrapping strings in curly braces 
?

I see no change recorded at http://rebol.com/r3/docs/datatypes/string.html
   Is there really no hope of   {" folowed_by_space then whatever 
chacters I please _ending_with_space _before "}   or some such as 
  {~ space_before_text_then_ending_space_before ~}     It is so odd 
that for our emphasis on value that a string containing  a linefeed 
and an odd number of braces is an error.  After all,   an odd number 
of colons is not an error !   Why MUST we escape characters rather 
than allowing true LITERAL string values ?  We even allow semi-colon 
within braces without an escape !  ;comment anyone?

Sounds interesting. A few comments:

- Colons and semi-colons don't have special meaning within REBOL 
string literals - { and " do (depending on how they are specified).

- String literals in programming languages almost always have escaping, 
though the capabilities vary from language to language. Escaping 
is done to include data in the string that would otherwise break 
the syntax. Without escaping you will never be able to include certain 
characters or character sequences.


There's a lot of terms and methods for what you are asking for, such 
as here docs (from Perl), CDATA sections (from XML), etc. An interesting 
idea, though it is usually cause for concern when we look to Perl 
or XML for syntax ideas - that's usually a bad road to take. Remember, 
when you get rid of escaping you limit the characters (or sequences) 
that you can include, though with here docs that limit can be minimal.

Robert, don't be fooled by R2's buggy console. R2 can escape { just 
fine - it's the console that will wrongly think you have an open 
string. Try that in a .r file.

For literal string delimiters, {~ followed by a space seems safe 
as I am unaware of where ~ is used followed by a space and at the 
other end I cannot think of where tilde is used followed by a closing 
curly brace.  Having Rebol always test for nested curl-braces in 
curl-brace values makes Rebol as difficult for my project as is Tcl 
- for the same reason.  Worka-arounds abound but the result has such 
poor usability and readability as to be unusable.

if they are not, you just need a ^

I think they want a multi-char delimiter so that the text inside 
needs much less escaping (or none?).

For example, I think RobertS might be happier if a new special type 
of string which is delimited by ~{ and }~ was added to Rebol.

In the content, single braces } or single tildes ~ would not need 
any escaping unless they happened to be together so that they look 
like the ending delimiter.
Or maybe no escaping is possible/necessary in such a string.

But now I'm also thinking of the start and end unique key strings 
used to delimit email attachments...

Hmm, scripts would too easily get "messed up" (that is, very unreadable) 
with Heredoc or similar stuff. maybe we could use #[{   .....    
}]# for that... I'd still rather use external files for long strings, 
and use escaping for short strings (in other languages you have \" 
everywhere, so why bother with a couple ^{ ?)

Gabriele:
Heredoc was suggested *because* RobertS's script was messy.

Maybe *you* would rather use external files for the situation you 
imagine RobertS is in, but I think you're not really trying to put 
yourself in his shoes. Moving stuff out into external files can create 
its own problems. The advice to "just use an external file" suggests 
a deficiency in the language. (One day we may not be using files. 
I hope sooner rather than later.)

A server-side scripting language which cannot handle literal strings 
- and especially one that claims to be Unicode - has to be excluded 
from consideration for templating web content which is expressed 
in any other langauge which uses curly braces.  I told BrianH that 
the red flag here should be Tcl as Rebol shares this with Tcl.  Literal 
string are literal strings.  Period.  No if's and's or "that might 
be my curly brace in there" ...  Unless you dream of a Rebol-only 
world - and that fantasy should have passed some years back.    This 
falls under the heading of folly - a topic too often neglected.  
Folly in a meritocracy usually requires some individual to speak 
up.  But the folly of meritocracies is that  to be heard taht individual 
would already have to be playing within those constraints.  We see 
this in schools which graduate top people distinguished for inidividual 
effort who then do not fit well into teams.  They did group work 
in college by being the one who saved the group from failure by ... 
their individual effort.  For me this will be what makes or breaks 
my involvement with REBOL.  I could not wait for REBOL4 and hope 
for change then by getting into the merit circle.  My outside voice 
would have to be heard before it is too late. Tcl as the do-all is 
folly.  As nuch as I admire OOTcl, the XOTcl IDE and Expect.  I cannot 
use Tcl with "balanced brace" foolishness.  Of course if we all adopt 
XML and abandon scripting in non-XML languages ... So  We have comment 
{  }  and that was a mistake: it should have been symmetrical as 
in c{ comment here as literal with } or whatever }c   And that is 
water under the bridge.  We cannot be UNICODE and claim that  we 
must escape a certain pair  of characters if ithey are in a literal 
string.  That is silly. Ludicrous. Folly.  A literal string is a 
data value where you do not get to peek.  Imagine a proxy object 
that said: "I will be your proxy only if you promise that when the 
real object appears it does not contain [ folly happens here ] " 
  Many forms of "catch-22" in the world of beaurocratic regulation 
have a similar pattern.  I am no expert on unintended consequences, 
but requiring that some pair of characters be escaped in otherwise 
literal content has consequences for TEMPLATE value TEMPLATE  There 
should be a lesson there: some markup must be arbitrary and the choice 
will matter.  { and } are the wrong choice.  At least the terminal 
markup must be "sacrificed (it will always have to be escaped so 
pick carefully.   [{ is a bad combo for JSON so #[{ looks worrisome 
to me.  I propose lit |ls# and_content_then  #ls|    Someone shoots 
that down and we inch towards a suitable result.  Not perfect.  But 
usable.  { and } are not useable in the real world on the server-side 
if rebol is to play a role with other languages.  Play nice.  Please.

lit_str1: lit |ls#    the word lit  indicates that what follows is 
an unconditional literal string much as comment indicates ignore 
only this is a value ; when necessary use the UNICODe equiavaled: 
note that the markup is symmetrically reversed as we end here #ls|

excuse me, but what is wrong by escaping by ^{  and ^} ? In R2, left 
curly brace escaping does not work in console only, but script being 
run from file (which is case on the server anyway) is OK. In R3, 
which soon will be ready to replace R2 for such scenarios, it works 
even in console. But probably I am too dumb to understand the issue 
involved :-)


Could someone please give me a snipped of some quoted JS or other 
code, in order to get the issue? Would like to try the headache myself 
:-)

What is obscure about a syntax which permits literal strings to be 
literal strings?  Try assigning  set lit "{test} {" in your favorite 
Tcl interpreter.  I am not a JSON expert but [{ looks like JSON to 
me so #{[ "looks worrisome to me"   JSON or YAML or something other 
than XML is going to be important whether REBOL likes it or not. 
 Take RDF as one exmaple ( I prefer Topic Maps - please do not attack 
the example, but the isea ).  The fact that most people seem to think 
that RDF is XML does not make it so.  Tim Berners-Lee prefers some 
form of Triple notation for RDF.  Not XML.  As soon as a notation 
uses curly braces we have a problem using Curl on the server-side. 
 Please don't point to QM.  IT is not just tightly coupled to HTML 
it is married to it.  The web is not HTML it is HTTP with Content-Type: 
 set in the response header.  If that content type uses curly braces 
we have to start escaping characters in Rebol.  Awkward templating 
is dooked templating.  Let me repeat: doomed.  Folly.

Pekr: take any peice of template code that ends with curly braces 
unbalance, then insert a value through templating and then clsoe 
off the curly braces.

Now try assigning those opening and closing pieces to variables so 
as to generate code.  If you try to use Rebol then there is an immediate 
problem because a great deal of real world code uses quoted strings. 
 So now you need a literal string.  But in Rebol that will be in 
curly braces. Sunk.  Now you are escaping chartacters when you are 
tyring to generate code.  No problem if code genrated by Rebol is 
consuked by Rebol.  But that is not realistic.  So now you are generating 
code with Rebol but then preporcessing hte code with Perl to strip 
out the escaping carets on the ^{ and ^} ???

real world code

 ... then why using REBOL, if there is plenty of  real world much 
 better code much better languages around. I can accept anything, 
 maybe the fix is easy, and then we should just submit a ticket, or 
 - the worse case, it could affect REBOL internal parser, making it 
 more complicated, slower. Dunno ...

A scripting language on the server must tolerate literal strings. 
 Python at google is one example.  Rebol is not at google. Dave Hanson 
is.  But ICON is not. So it is not some conspiracy.  No one is out 
to subvert Rebol.  JSON was an example.  Examples abound.

A nightmare if Rebol's output is to be another langauge's input.

So what you are asking for is to use some really weird combination 
of chars, which could not by accident happen inside your string (unless 
someone is crazy), and use them as a string delimiter?

A literal string has an indiated start and an indicated end and between 
you do not hiccup - how could we break comment on another forward 
curly brace?

Can we not use a word such as lit ?  ( as I dare not suggest the 
word 'ls

I see it as a failure to evolve.  They see the problem as an indication 
of their strength (their unique interpreter strategy )

What about using a word which requires three paramaters the first 
and third of which must be those delimiters ( smart might be to have 
3 sets of delimiters which need not even be paired - or to have what 
counts as a delimiter set for the user context with one pair of system 
defaults.

couldn't we somehow use some rebolish combinations to identify a 
lit string? e.g. your's suggested ~{, or gab's #[{     }]#  (more 
easily noticeable)

OOps, I left a right parenthesis stranded - luckily the text widget 
did not reject  my input ... ;-)

I thinkt he answer is to have Carl open a post on his R3 blog and 
get some comments - somefeedfack can get us to toptimal choices - 
maybe the anser is to have 3 pairs avaialbe - I don't know ( I'm 
just a Rebol user, not a Rebol guru )  Okay, Okay, I'm also a pain-in-the-neck 
 ( I really do have cervical osteop. in real life - not usually funny, 
but that's life ;-)

I think that in UNICODE raw string is now meaningless to end users; 
Americans ignore that European languages often have variant opening 
quote from closing quote ( as did British English in my youth, as 
I recall )  this is a new phenomenon in America: educated Americans 
spoke French, read French and if they were mean, had often spent 
time at a German university,  The North American shool system was 
of Prussian insoiration, as I recall.  But atleast Carl is learning 
French ... but does he use << and >>  ... that I woulldn\'tt know 
\"  ;-)   So that leave literal strings  such as @"  "@  I still 
use a language with a character count delimiter pair

a mirror-terminator of "@ is my idea of a bad idea

some string literals should be un-preprocessed and un-processed verbatim 
content.  "Verbatim string" might be less confusing than "literal 
string" which sould like "string literal".  "pristine string" has 
a nice ring.   vs{  virgin string  }sv

August is short, we are almost at the middle of August. I expect 
some bugfixes, BrianH syncing his module related work, maybe new 
additions/fixes to extensions, I think GUI can wait a bit :-)

RobertS, you said that similarity with TCL is a red flag, but that 
is not the case. TCL, like Ruby, is known to be bad because of its 
internals and semantics, not its syntax. XML and Perl are the ones 
with bad syntax.

What is obscure about a syntax which permits literal strings to be 
literal strings?
 - Most languages don't support it.

So now you are generating code with Rebol but then preporcessing 
hte code with Perl to strip out the escaping carets on the ^{ and 
^}

Completely unnecessary. REBOL escaping is only a REBOL syntax trick 
- in memory the escaping carets don't exist. If you don't want carets 
in your output use PRINT, FORM, WRITE, or anything but MOLD. There 
is no interoperability argument for heredocs whatsoever.

I am not saying that heredocs are a bad idea (and have given some 
advice on them in the CureCode ticket). However, they are not *needed* 
for any of the reasons that you have stated. The only reason we would 
want them is for minor ease-of-use improvements, and because several 
other languages in roughly the same category as REBOL has something 
similar.

A server-side scripting language which cannot handle literal strings...
 (the long message)

I had a little difficulty finding any criticisms of REBOL or its 
string literals in this message that actually apply to REBOL 3 even 
now.


- { } balancing exists make generation of brace languages like JS 
and CSS easier. You only have to escape { and } if they are unbalanced 
in the syntax; most of the time they aren't. R3 already fixed the 
^{ console bug, so that isn't a problem. And the escaping only applies 
to REBOL syntax, and is resolved by LOAD - there is no escaping in 
the data once loaded.

- COMMENT is a function, not syntax, and that function doesn't even 
need to be there most of the time. REBOL doesn't have block comments 
at all. And doesn't need them for the most part - COMMENT works when 
they are needed.
- The meritocracy argument doesn't apply here (or make sense).

- Unicode is supported just fine (at least within the BMP). String 
escaping doesn't affect Unicode support.

- String escaping doesn't affect string data - it's just a syntax 
thing.

- JSON is supported just fine in R3, better than in R2 since the 
R3 data model is a better match. String escaping doesn't affect JSON.


The one part that made sense is that #[{ }]# would be bad for specifying 
JSON data - true that. Something starting with # for the start delimiter 
would be good, but not starting with #",  #{ or #[  since those would 
conflict.


I suggested in the CureCode ticket that the last character of the 
start delimiter and the first character of the end delimiter be newline 
- this would make the heredocs really distinct. There would not be 
a need for single-line heredocs because there could only be a small 
number of characters in them, small enough to escape. Just a suggestion 
though.

I'm seeing a bad conversion for alpha-77 under Windows Vista 32-bit:

    system/version
    == 2.100.77.3.1
    9200000000000000000
    == 9200000000000000000   ;; good
    9300000000000000000
    == 9223372036854775807   ;; bad  
    9999999999999999999
    == 9223372036854775807   ;; stays bad up to here 

Brian is not seeing this problem under a different Windows.

Could you try it on your rig and see what happens?
Thanks. That'll help narrow down the problem area.

I am going to wait for answers to the questions in R3 chat #5126 
to finalize my changes. I've already worked out the integration, 
but a few policy/informational matters need to be addressed.

You can also statically link SQLite into your extension DLL, and 
just export your extension wrapper code, or the whole of SQLite if 
you want to do the trick like tclsqlite or System.Data.SQLite. The 
real trick is making a proper database access model that fits into 
R3. This might be tricky with extensions v1 because we don't have 
device support yet.

With extensions v1 it's much easier to make a compiler than it is 
to provide SSL or database access.

I thought I'd need user-defined function types to make a JIT compiler, 
and those are much further down the road than devices. It turns out 
tthat the command! type is sufficient, today. I could start adapting 
a JIT next week.

I've traced through the RX code (there isn't much of it - extensions 
are *simple*). It's a great model. I have a few low-level questions 
and one or two requests, but the overall model is pretty solid. There 
are GC considerations that still need addressing though.