[new-line new-lines] NEW-LINES dialect wrapper for NEW-LINE func

Anton said: AR> and NEW-LINE bugs me more, where you have to wrap the AR> thing you're modifying in a sandwhich of 2 arguments. Yeah, you're never going to get it things right for everybody; and I've thought, too, that NEW-LINE doesn't read particularly well, so...what do you think of something like this (watch for wrap): new-lines: func [ input [block!] /local set clear insert remove other ords keys =ord =state =all =skip =block ][ insert: set: on remove: clear: off other: 2 ords: [first second third fourth fifth sixth seventh eigth ninth tenth] keys: append copy ords [in from every all marker markers item items] input: reduce/only bind/copy input 'ords keys =ord: =state: =all: =skip: none ord=: [ set =ord ['first | 'second | 'third | 'fourth | 'fifth | 'sixth | 'seventh | 'eigth | 'ninth | 'tenth] (=skip: index? find ords =ord) ] rule=: [ any [ 'all (=all: true) | [set =state logic!] | ['every [set =skip integer! | ord=]] | [opt ['in | 'from] set =block block!] | ['marker | 'markers | 'item | 'items] ] ( if all [=block not none? =state] [ either =skip [new-line/skip =block =state =skip] [ either =all [new-line/all =block =state] [ new-line =block =state ] ] ] ) ] either parse input rule= [=block] [none] ] Examples: b: [1 2 3 4 5] new-lines [all on in b] new-lines [all off in b] new-lines [every other on in b] new-lines [every other in b off ] new-lines [in b every third item on] new-lines [in b off every 3] new-lines [insert marker in b every 2 items] new-lines [remove marker in b every 3 items] new-lines [set all markers in b] new-lines [clear all markers in b] new-lines [set every other marker in b] new-lines [clear marker every other item in b] new-lines [b all off] new-lines [b on] new-lines [b off] --Gregg

Hi Gregg, Well, I suggested a dialect when NEW-LINES was being designed, but they were in too much of a hurry. Your dialect seems easy to read but I think it could be more concise. It doesn't really need 'marker(s), 'in or 'item(s). I would also probably move the block to be modified outside the dialect block, as the second argument, to facilitate directly specified (anonymous) blocks. (Yes, I need to do that sometimes.) Otherwise, I'm back to the situation I was in before, with some of the NEW-LINES specification trailing the block to be modified. ("eigth" is also missing an 'h') I certainly appreciate your effort in this direction. Regards, Anton.

Hi Anton, AR> Well, I suggested a dialect when NEW-LINES was being AR> designed, but they were in too much of a hurry. That's too bad. I'm always pushing for dialects where they make sense...and sometimes where they don't I suppose. AR> Your dialect seems easy to read but I think it could AR> be more concise. It doesn't really need 'marker(s), 'in or AR> 'item(s). I often allow optional words that make a sentence more complete. It's something I'd like to see discussed more; Carl once mentioned that he considered it for REBOL in general, but didn't include it. My concern is that allowing extra words as filler makes them part of the grammar, so they aren't available later, if you extend the dialect. AR> I would also probably move the block to be modified outside AR> the dialect block, as the second argument, to facilitate AR> directly specified (anonymous) blocks. I thought about that too. If we do that, should the block be the first or second arg? If second, it's backwards from new-line. Including it in the dialect has the negative effect of possible conflict with a keyword, forcing you to use COMPOSE; but, like filler words, it can make for more complete sentences. Does anyone else have thoughts on this? AR> ("eigth" is also missing an 'h') Thanks! In both blocks, too, because I copied it. -- Gregg

Hi Gregg,=0A=0AYour dialect is potentially very useful. The syntax I prefer is:=0A=0Anew-lines blk spec-block=0A=0Awhere spec block is something more like the forthcoming rebol printf-like functionality, but where you can specify the layout of multiple lines=0A(I usually have a file with a bunch of data repeating and what is useful is to be able to layout the say 5 repeating lines in a meaningful way so=0Athat the file can be inspected)=0A=0AThanks=0Ajose=0A=0A----- Mensaje original ----=0ADe: Gregg Irwin <gregg-pointillistic.com>=0APara: Anton Rolls <rebolist-rebol.com>=0AEnviado: viernes, 18 de mayo, 2007 17:21:10=0AAsunto: [REBOL] Re: [new-line new-lines dialect] NEW-LINES dialect wrapper for NEW-LINE func=0A=0A=0AHi Anton,=0A=0AAR> Well, I suggested a dialect when NEW-LINES was being=0AAR> designed, but they were in too much of a hurry.=0A=0AThat's too bad. I'm always pushing for dialects where they make=0Asense...and sometimes where they don't I suppose.=0A=0AAR> Your dialect seems easy to read but I think it could=0AAR> be more concise. It doesn't really need 'marker(s), 'in or=0AAR> 'item(s).=0A=0AI often allow optional words that make a sentence more complete. It's=0Asomething I'd like to see discussed more; Carl once mentioned that=0Ahe considered it for REBOL in general, but didn't include it. My=0Aconcern is that allowing extra words as filler makes them part of the=0Agrammar, so they aren't available later, if you extend the dialect.=0A=0AAR> I would also probably move the block to be modified outside=0AAR> the dialect block, as the second argument, to facilitate=0AAR> directly specified (anonymous) blocks.=0A=0AI thought about that too. If we do that, should the block be the first=0Aor second arg? If second, it's backwards from new-line.=0A=0AIncluding it in the dialect has the negative effect of possible=0Aconflict with a keyword, forcing you to use COMPOSE; but, like filler=0Awords, it can make for more complete sentences.=0A=0ADoes anyone else have thoughts on this?=0A=0AAR> ("eigth" is also missing an 'h')=0A=0AThanks! In both blocks, too, because I copied it.=0A=0A=0A-- Gregg=0A=0A-- =0ATo unsubscribe from the list, just send an email to =0Alists at rebol.com with unsubscribe as the subject.=0A=0A=0A=0A=0A=0A=0A=09=09=0A______________________________________________ =0ALLama Gratis a cualquier PC del Mundo. =0ALlamadas a fijos y m=F3viles desde 1 c=E9ntimo por minuto. =0Ahttp://es.voice.yahoo.com

Hi Jose, j> Your dialect is potentially very useful. The syntax I prefer is: j> new-lines blk spec-block Yes, that's the main alternative I think. j> where spec block is something more like the forthcoming rebol j> printf-like functionality, but where you can specify the layout of j> multiple lines (I usually have a file with a bunch of data j> repeating and what is useful is to be able to layout the say 5 j> repeating lines in a meaningful way so that the file can be j> inspected) So, more of an example driven approach? Can you post some examples of what you're thinking it might look like? -- Gregg

=0ASo, more of an example driven approach? Can you post some examples of=0Awhat you're thinking it might look like?=0A=0AHi Gregg,=0A=0ABased on future printf - http://www.rebol.net/r3blogs/0066.html=0A=0Afields: [book-id title author publisher price]=0Ab-data is a block containing repeating fields=0A=0Anew-lines b-data [ =0A ["---------------" 15] [book-id]=0A [50 " " 30] [title author]=0A [20 " " -5] [none price] =0A ["----------------------------------------------------"] []=0A ]=0A=0AThe block pair (spec values) in the new-lines spec should be handled via printf. I think this give the most flexibility to layout the data and skip any data that you don't want. There should also be some options either cut long string fields or let the fields expand.=0A=0ARegards=0Ajose=0A=0A=0A=0A=0A=0A=0A =0A____________________________________________________________________________________=0A=A1Descubre una nueva forma de obtener respuestas a tus preguntas!=0AEntra en Yahoo! Respuestas.=0Ahttp://es.answers.yahoo.com/info/welcome

Hi Jose, Your mail client doesn't seem to get along with the ML, WRT new lines; I've reformatted as best I could. ---------------------------------------------------------------------- fields: [book-id title author publisher price] ;b-data is a block containing repeating fields new-lines b-data [ ["---------------" 15] [book-id] [50 " " 30] [title author] [20 " " -5] [none price] ["----------------------------------------------------"] [] ] The block pair (spec values) in the new-lines spec should be handled via printf. I think this give the most flexibility to layout the data and skip any data that you don't want. There should also be some options either cut long string fields or let the fields expand. ---------------------------------------------------------------------- I think I understand what you mean, but I don't think printf should be implied in new-lines; APPLYing printf should be a separate step IMO. -- Gregg