relative expressions
[1/21] from: brett:codeconscious at: 29-Mar-2003 15:39
I feel that the process of authoring of REBOL scripts and messages is
habitually thought of as programming and I wonder if there are other ways to
design and think about scripts that more usefully exploit REBOL's
flexibility.
As a start, has anyone got any examples that they feel explain, demonstrate,
exploit or point to the benefits/qualities of the "relative expression"
concept in REBOL?
Thanks
Brett.
[2/21] from: tim:johnsons-web at: 30-Mar-2003 13:04
Hello Brett:
* Brett Handley <[brett--codeconscious--com]> [030328 21:14]:
> I feel that the process of authoring of REBOL scripts and messages is
> habitually thought of as programming and I wonder if there are other ways to
<<quoted lines omitted: 3>>
> exploit or point to the benefits/qualities of the "relative expression"
> concept in REBOL?
I honestly don't know what is meant by "Relative Expression". I
thought maybe RT like the word "rebol" and reversed-engineered
the acronym :-)
I use rebol to dynamically produce javascript (which is another
programming language, of course) - would that be an example?
What about dialects? Andrew, feel free to jump in here...
--
Tim Johnson <[tim--johnsons-web--com]>
http://www.alaska-internet-solutions.com
http://www.johnsons-web.com
[3/21] from: antonr:iinet:au at: 31-Mar-2003 12:36
I had a long email ready to send, but at
the end, I decided I wasn't sure I was
answering the question or providing a
decent example. But, anyway, I reckon
relative expression
just means that the
same word can have different values
depending on the context. We are so used
to it that we don't notice how comprehensive
that is.
Maybe it should be: Relative Expression Based Context Language.
Anton.
[4/21] from: greggirwin:mindspring at: 30-Mar-2003 20:47
Hi Brett,
BH> I feel that the process of authoring of REBOL scripts and messages is
BH> habitually thought of as programming and I wonder if there are other ways to
BH> design and think about scripts that more usefully exploit REBOL's
BH> flexibility.
I agree. I think REBOL development really benefits from separating the
requirements (i.e. problem definition) space from the construction
aspect. With most development models, you have to translate the
problem into some "requirements model" for development and then you
have to build the program from those specs, which may have lost
or obscured semantic meaning in the translation.
REBOL can remove the middle-man. First, think about stating the
problem you are solving in terms that fit it best. Next, define a
dialect that understands the problem domain. Finally, implement the
dialect.
This moves us from a model of reusable function libraries and generic
components to a model of (potentially) reusable problem definition
languages. I can think of lots of reasons this could be a *very* good
thing, not the least of which is that if shifts our focus away from
code for code's sake
.
BH> As a start, has anyone got any examples that they feel explain, demonstrate,
BH> exploit or point to the benefits/qualities of the "relative expression"
BH> concept in REBOL?
I wish I had some good examples handy, that were functional. I have
ideas sketched out just waiting for the day I win the lottery. :)
One example is a screen-layout/hard-copy-report situation. In both
cases you're saying "Here's the data I want, and how I want it
formatted". One dialect can serve both needs.
Another example would be workflow/async process definition. "Send
<this-message> to <this-recipient> [at <this-address>]. If no-response
within <this-timeframe>, <take-evasive-action. When response arrives,
ensure <this-response> is valid, log <this-response>, forward to
<this-recipient>, and notify <this-recipient>".
-- Gregg
[5/21] from: brett:codeconscious at: 1-Apr-2003 10:30
Hi Tim, Anton, Gregg,
Thank you for responding.
Tim wrote:
> I honestly don't know what is meant by "Relative Expression". I
> thought maybe RT like the word "rebol" and reversed-engineered
> the acronym :-)
... REBOL was designed to solve one of the fundamental problems in
computing: the
exchange and interpretation of information between distributed computer
systems.
REBOL accomplishes this through the concept of relative expressions (which
is
how REBOL got its name as the Relative Expression-Based Object Language).
I'd hoped that RT would have provided more direction in this area. I doubt
that
many of us have had much experience design languages/grammars before, yet
the Dialect concept (relative expression) is fundamental to REBOL's reason
for existence. It wouldn't have needed to be created if we could have just
used
other languages to solve the same problems we are already solving.
Anton wrote:
> But, anyway, I reckon
> "relative expression" just means that the
<<quoted lines omitted: 3>>
> that is.
> Maybe it should be: Relative Expression Based Context Language.
I think that is a key to the whole concept. But I have difficulty whittling
down the most useful ways to choose good words, good expressions and ways of
establishing the required contexts. Maybe I'm trying too hard. :)
Gregg wrote:
> I agree. I think REBOL development really benefits from separating the
> requirements (i.e. problem definition) space from the construction
<<quoted lines omitted: 6>>
> dialect that understands the problem domain. Finally, implement the
> dialect.
That is the promis and what I try to target, but I find the actual process
of doing that very hard. It is not easy to develop the terms that fit the
problem in the first place, there are few examples to understand and follow
in the REBOL world (VID is
my current reference).
I also wonder how multiple dialects can be usefully mixed together. I mean,
lets say we have solved two problems plotting (qplot) and pdf making
(pdfmaker) - shouldn't we aim to be able to mix them so that we could graph
the number of
words per section of a pdf file, or more usefully put a graph into a pdf?
Is this latter combination something that should be easy to solve using yet
another dialect or should it be viewed as a specific "lets hack a solution
together".
> This moves us from a model of reusable function libraries and generic
> components to a model of (potentially) reusable problem definition
<<quoted lines omitted: 4>>
> cases you're saying "Here's the data I want, and how I want it
> formatted". One dialect can serve both needs.
Yes I had been toying with the idea of using the exact same methods of VID
(stylesheet, local style words) to create a markup generator. So that the
same VID source [h1 "An example" text {This will appear on screen and in
print}] would
appear on screen and as xhtml. I suspect Carl had this in mind when creating
VID and make-doc. But I haven't seen any example of this usage. I'm not sure
yet whether make-doc-pro "honors" this latent feature.
You put it well Gregg, I wonder what other "reusable problem definition
languages" there are out there, what they might look like and how well they
mix together.
Maybe a metric for a resuable problem definition language is how many
different useful interpreters can read it?
--Brett
[6/21] from: greggirwin:mindspring at: 31-Mar-2003 21:00
Hi Brett,
REBOL is targeting new ground. This can be tough because people have
to see the true target, and appreciate how important it is. What we do
today, myself included, is largely to apply REBOL like we would other
languages. If it were really awful in that regard, it might make it
easier to look at it as something different. Instead, it's really
good, even when applied that way.
I think RT has worked hard to provide this "conceptual compatibility
layer" and done a very soft sell on dialecting, perhaps wisely so.
It's something that you can't explain to most people; they have to
experience it. I know it took me a while to realize just how important
dialects are and, IIRC, it was CHARSET that made it hit me; not PARSE,
not VID, but CHARSET. Funny, huh? :\ It's easy to be in awe of the
PARSE and VID dialects, but all the tiny little dialects are just as
important, if not moreso, IMO.
BH> I think that is a key to the whole concept. But I have difficulty whittling
BH> down the most useful ways to choose good words, good expressions and ways of
BH> establishing the required contexts. Maybe I'm trying too hard. :)
I think it *is* hard. I know I have a hard time with it too. It's easy
to create really stinky dialects and lots of work to create elegant
ones. I think the more we do it, the easier it will get.
I know I still sometimes find myself designing a dialect so it's easy
to parse, which often makes them clunky and programmerish. That, and
I'll think it's not worth it unless the dialect is substantial. Both
ideas are wrong. Small dialects are important and powerful and
dialects should *not* be designed only in a bottom-up manner. Top-down
is the way to design you dialects. Not with a grammar specification,
but with sample text.
BH> That is the promis and what I try to target, but I find the actual process
BH> of doing that very hard. It is not easy to develop the terms that fit the
BH> problem in the first place, there are few examples to understand and follow
BH> in the REBOL world (VID is my current reference).
Have you tried playing "telephone code" to do it? That helps me
sometimes. I have to think like a user. Imagine I'm telling someone
else what I want, without regard for how they're going to do it. We
should probably also get users to help us. Pick a problem domain, find
some non-programmers, and ask them to explain the solution in their
own words.
BH> I also wonder how multiple dialects can be usefully mixed together. I mean,
BH> lets say we have solved two problems plotting (qplot) and pdf making
BH> (pdfmaker) - shouldn't we aim to be able to mix them so that we could graph
BH> the number of words per section of a pdf file, or more usefully put a graph
BH> into a pdf?
Good example. I think a good plotting dialect would become a standard;
then people take that dialect and change the actions behind the rules
to do what they want in a new context. That brings up an important
design point. How to implement dialects so that kind of thing is as
easy as possible.
BH> Yes I had been toying with the idea of using the exact same methods of VID
BH> (stylesheet, local style words) to create a markup generator. So that the
BH> same VID source [h1 "An example" text {This will appear on screen and in
BH> print}] would
BH> appear on screen and as xhtml. I suspect Carl had this in mind when creating
BH> VID and make-doc. But I haven't seen any example of this usage. I'm not sure
BH> yet whether make-doc-pro "honors" this latent feature.
That's what we're doing with the library project, at least partially.
All the static pages were generated from the VID layouts in the REBOL
librarian script.
BH> You put it well Gregg, I wonder what other "reusable problem definition
BH> languages" there are out there, what they might look like and how well they
BH> mix together.
BH> Maybe a metric for a resuable problem definition language is how many
BH> different useful interpreters can read it?
How many can you think of? I'll take a couple minutes and see what I
can come up with.............about 40, but hard to say how "reusable"
some of them would be. :)
Recently had cause to look at the GEDCOM file format - used for genealogy
data interchange - and there are probably at least 5 or 6 different
things you could do with it, just off the top of my head. Probably the
same for many data formats. Some needs will be very small but, again,
those little things can make a big difference.
-- Gregg
[7/21] from: g:santilli:tiscalinet:it at: 1-Apr-2003 14:57
Hi Gregg,
On Tuesday, April 1, 2003, 6:00:25 AM, you wrote:
BH>> I also wonder how multiple dialects can be usefully mixed together. I mean,
BH>> lets say we have solved two problems plotting (qplot) and pdf making
BH>> (pdfmaker) - shouldn't we aim to be able to mix them so that we could graph
BH>> the number of words per section of a pdf file, or more usefully put a graph
BH>> into a pdf?
GI> Good example. I think a good plotting dialect would become a standard;
GI> then people take that dialect and change the actions behind the rules
GI> to do what they want in a new context. That brings up an important
GI> design point. How to implement dialects so that kind of thing is as
GI> easy as possible.
This is something I've been thinking about too; actually, my
custom-types ides came out from this thinking.
If you think about REBOL's function interpreter, you see it is
based on values. An expression is just a sequence of values, and
depending on the type and the content of these values you get a
result when it is evaluated. When we implement dialects using
block parsing, we are using the same REBOL values to describe
something, and the parser to interpret this and make actions or
translate to something else.
Now imagine if we had types of values that were designed
specifically for our problem domain. In such a case, you would not
even need PARSE rules, but only something that makes the correct
actions for these values. (Notice that in REBOL the "methods" for
datatypes are called "actions". I wonder if this is a
coincidence.) This would solve the reusability problem, because
you just have to change the actions.
However, you still don't have an easy way to "write down" the
values; this is where PARSE comes. You design a dialect with the
rules to parse it and translate it to a (sequence of) (custom)
value(s). It is like VID, that just translates to a FACE, which is
then used by View.
I really think that having custom types helps a lot with this;
just having objects is fine with things like View, because you
only have one kind of object, i.e. the FACE. In domains that are
more complicated (maybe just because we are not smart enough to
make them simpler...) you can easily have the need for many kinds
of objects.
So you get three layers:
Language (dialect)
------------------
Values
------------------
Actions
The "values" layer is something that you don't have in languages
other than REBOL (at least that I know of). It is the layers that
allows dialecting, and that gives REBOL all of its simplicity and
flexibility; I think we should use this approach too!
What do you think?
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[8/21] from: greggirwin:mindspring at: 1-Apr-2003 9:11
Hi Gabriele,
Yes, I think you're right. I *still* have to go back and look at your
latest dialect builder stuff (sorry I've dropped the ball on that)! I
bet there's a great deal of leverage to be applied between this
concept and the "teaching REBOL" thread as it relates to dialects.
Sometimes the best way to find the answer to a problem is to explain
it to someone else.
-- Gregg
[9/21] from: ingo:h-o-h at: 1-Apr-2003 20:24
Hi Gabriele,
Gabriele Santilli wrote:
<...>
> Now imagine if we had types of values that were designed
> specifically for our problem domain. In such a case, you would not
<<quoted lines omitted: 8>>
> value(s). It is like VID, that just translates to a FACE, which is
> then used by View.
<...>
You are right, I wrote a webbased calendar using pliant. I wanted to be
able to write dates, but with some added sugar.
2003-01-01 would be the first of January 2003
01-01 First of january in whatever year
03/-1 the lasst of february in whatever year
and some more like this.
I missed my 'parse badly, but then I found the possibility to create new
types, along with the to/from string rules - in a way it's even more
powerfull then parse, because it is saved in the corresponding variable
_as_this_new_datatype_. Having real userdefinable datatypes on the Rebol
level would be great.
Kind regards,
Ingo
[10/21] from: maarten:koopmans:surfnet:nl at: 1-Apr-2003 22:16
I think we may end up in an operator overloading discussion. But then
-as always- more elegant in Rebol.
--Maarten
[11/21] from: g:santilli:tiscalinet:it at: 2-Apr-2003 9:58
Hi Maarten,
On Tuesday, April 1, 2003, 10:16:20 PM, you wrote:
MK> I think we may end up in an operator overloading discussion. But then
MK> -as always- more elegant in Rebol.
REBOL natives are highly overloaded; in particular, ACTION!s are
basically methods that can be applied to values, and whose action
depends on the type of the value.
Of course, this can get confusing. However, having a different
function for each different type would be even more confusing: if
you are doing the same action, use the same ACTION!. :-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[12/21] from: Maarten:Koopmans:surfnet:nl at: 2-Apr-2003 12:20
Hi Gabriele,
I agree and am on your side. I was just warning for these kind of
discussions in general ;-)
You should browse some Java and C++ mailing lists!
--Maarten
[13/21] from: brett:codeconscious at: 2-Apr-2003 19:40
Hi Gabriele,
> If you think about REBOL's function interpreter, you see it is
> based on values. An expression is just a sequence of values, and
<<quoted lines omitted: 3>>
> something, and the parser to interpret this and make actions or
> translate to something else.
It took me ages (over a year) to come to realise this about REBOL despite
the fact that it is fairly plainly described as you have just done (good
work!) and that it is described in the Core manual!
> Now imagine if we had types of values that were designed
> specifically for our problem domain. In such a case, you would not
<<quoted lines omitted: 3>>
> coincidence.) This would solve the reusability problem, because
> you just have to change the actions.
So, custom types would allow the REBOL interepreter to interpret these
expressions directly. Another benefit is that our normal understanding of
how REBOL interprets values is used when thinking about these custom values.
But I don't think that changing the actions will be entirely sufficient for
reusability, although I do agree it could be very powerful.
> However, you still don't have an easy way to "write down" the
> values; this is where PARSE comes. You design a dialect with the
> rules to parse it and translate it to a (sequence of) (custom)
> value(s). It is like VID, that just translates to a FACE, which is
> then used by View.
Agreed, though VID does more than create FACEs, it also arranges them
(layout). VID is building/maintaining state (e.g offset) as it processes the
dialect. I know this seems obvious but I feel it is important to highlight
that dialects may have this extra "between the lines" - value adding aspect.
I think this relates to Nørretrander's "Exformation"
concept(http//www.quinion.com/words/turnsofphrase/tp-exf1.htm).
Also in relation to parsing dialects, I'd like to see a methodology for
designing dialects so that they can be usefully mixed together (as I
mentioned). Some sort of grammar convention might help here.
> I really think that having custom types helps a lot with this;
> just having objects is fine with things like View, because you
> only have one kind of object, i.e. the FACE. In domains that are
> more complicated (maybe just because we are not smart enough to
> make them simpler...) you can easily have the need for many kinds
> of objects.
Yes custom types could be very important. Though they may not be so good for
message passing between distributed systems because they might introduce
unwelcome dependencies ("do you have custom type xyz-floating-graphic?").
> The "values" layer is something that you don't have in languages
> other than REBOL (at least that I know of). It is the layers that
> allows dialecting, and that gives REBOL all of its simplicity and
> flexibility; I think we should use this approach too!
That's a really interesting observation. Deserves more reflection :^)
Regards,
Brett
[14/21] from: g:santilli:tiscalinet:it at: 2-Apr-2003 15:39
Hi Brett,
On Wednesday, April 2, 2003, 11:40:50 AM, you wrote:
BH> So, custom types would allow the REBOL interepreter to interpret these
BH> expressions directly.
Maybe not directly from the function interpreter, but directly in
the same way as you can now handle blocks, dates, urls, and so on.
You can have a set of generic functions that work on any new type
you happen to add to your application in the future...
BH> But I don't think that changing the actions will be entirely sufficient for
BH> reusability, although I do agree it could be very powerful.
Of course we'd really require that creating new datatypes was
allowed by the interpreter, and not just by using "hacks" like
custom-types.r.
BH> VID is building/maintaining state (e.g offset) as it processes the
BH> dialect. I know this seems obvious but I feel it is important to highlight
BH> that dialects may have this extra "between the lines" - value adding aspect.
Yes, and in some cases you'd need to make this "information"
explicit in some way, if you want to push reusability. However,
since dialects are domain specific languages, usually this
between the lines
is part of the specific domain too, so it
doesn't necessarily have to be made explicit.
Take a FACE as an example: it has everything it is needed to
render it, and you could render it on a PDF file instead of on a
window. If you had something that translated to PDF starting from
a FACE, you could use LAYOUT to create graphics for a PDF file.
You don't need to know how LAYOUT works internally etc. You just
need to know the concept of a "face".
BH> Also in relation to parsing dialects, I'd like to see a methodology for
BH> designing dialects so that they can be usefully mixed together (as I
BH> mentioned). Some sort of grammar convention might help here.
Maybe, but it is very dialect-specific anyway. I don't think it is
possible to have a solution that is so general to allow you to mix
any two dialects, mainly because mixing does not have any sense
for most two dialects.
BH> Yes custom types could be very important. Though they may not be so good for
BH> message passing between distributed systems because they might introduce
BH> unwelcome dependencies ("do you have custom type xyz-floating-graphic?").
Of course, and that is the reason why we have View as a single
executable. However, as soon as we try to modularize, we get to
this problem. A good solution is probably that of having all
instanced well synched, so that it is not possible to have two
different versions of the same application at the same time. (With
IOS you have this automatically, because your reblets are synched,
and if you change a reblet the change is reflected to all the
users.) Another way is to always provide fallbacks and default
behaviors in case of failure.
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[15/21] from: greggirwin:mindspring at: 2-Apr-2003 10:54
Gabriele and Brett,
Not much time, but a couple thoughts:
1) Combining dialects isn't something I see as simpy a UNION of two or
more, but what we do is build up phrases, idioms, and dialect
nesting
. E.g. maybe there's a dialect for medical terminology. Now,
you have messages from people that contain "my doctor said I have..."
or "my doctor told me..." which could be used like a switch to jump
INTO another dialect (like INTO being used with sub-blocks). In this
case, you jump from your main messaging dialect to the medical
dialect; maybe even try a list of alternate dialects.
Where messages go, and how they are used, will also vary widely. There
will likely be cases where a message header will contain metadata that
will help tell processors what to do, or what can be done,
with them. Think how things like JINI and WSDL are used as an example.
2) The dialect/action combination is a many to many relationship.
We may want to replace the actions behind a dialect, but we may *also*
want to put a different dialect over basically the same set of
actions, or at least achieve the same end result (e.g. parse the data
for values, build up a record, put it in a DB).
3) If you've looked at the "programming by example" paradigm, imagine
designing dialects by using example text.
A sentence contains a subject, a verb, an object, and
sometimes some adjectives.
"Mr. Morton walked down the street."
In this sentence
Mr. Morton is the subject
walked is the verb
the street is the object
---
A data record contains 3 fields: first name, last name, and
phone number. E.g.
Gregg, Irwin, 000.000.0000
Brett, Handley, (00) 00.000.0000
For something like English, or other natural langugages, this could
obviously be a bit of work, but there is a lot of text out there that
could be used as examples. :)
PARSE itself is amazing, but imagine what we can build on top of it!
-- Gregg
[16/21] from: tbrownell:L3TECHNOLOGY at: 2-Apr-2003 14:55
I've found that all data and functions have a natural language "definition",
much like pseudocode....
Take all the numbers from the group N, multiply each by 3 and print the
result.
Becomes...
TakeAllNumbersOfN-MultiplyBy3AndPrintFunction: Func [N] [Foreach val n
[print val * 3]
Every sentence has a subject and a predicate. In the sentence above, the
subject is N and the predicate is the function.
As I mentioned in earlier posts, there should be a "standard English" (any
symbols would do as long as we all agree) to represent the predicates, in
this case functions, and what I call LFReD names to represent subjects...
which is why 'everything needs an LFReD name"
http://LFReD.L3Technology.com/LFReD
This concept can carry into other areas;
NLP...
(Rebol) (rocks the house).
Subject: =RebolPredicate: Excellent
Semantic Networks...
=Rebol= IsA ProgrammingLanguage
=Rebol= hasPart GUI
Terry
[17/21] from: brett:codeconscious at: 3-Apr-2003 16:54
Hi Gabriele,
> Maybe, but it is very dialect-specific anyway. I don't think it is
> possible to have a solution that is so general to allow you to mix
> any two dialects, mainly because mixing does not have any sense
> for most two dialects.
I'm not looking for a general way to mix any two dialects, I'm looking for a
more general way to design dialects so that they can be easily mixed. Such a
thing may not solve all problems but if it solves many problems it has
value. I know a solution exists already - write a REBOL script, though I
hope for something with a little more leverage. On the other hand maybe the
REBOL script is the best solution and I just don't know how to leverage it
in the best way.
Here's a situation I'm looking/hoping for. Assuming I have the components,
it should be easier/faster for me to describe using dialects a given
application than using Excel. For example, lets say I want to do a
discounted cash flow, calculate an internal rate of return and show me the
workings in a grid. Right now, despite having an IRR and NPV functions, I
would do this in Excel because it is a non-trivial ad-hoc application and I
am confident that I'll achieve the result this way without spending too much
time. But then I end up with a non-reusable application (ignoring highly
complex MS technology to make it reusable). I would prefer to describe the
application using dialects and for that process to be cheaper (in time and
effort) than the Excel solution and still end up with an application where I
can reuse most of my work in another situation.
In fact using VID and a pre-existing function I did write an ad-hoc
options-valuation program (for myself) that was faster to do in REBOL than
Excel. I want more wins like this - all the time - it should be the default
case. I want a quantum leap in productivity using dialects. But I'm
susceptible to dreaming ridiculous things :^)
Regards,
Brett
[18/21] from: brett:codeconscious at: 3-Apr-2003 17:41
> 1) Combining dialects isn't something I see as simpy a UNION of two or
> more, but what we do is build up phrases, idioms, and dialect
> "nesting".
I agree, and that building up is real work of real value that is leveraged
by people but much less easily in programs.
> E.g. maybe there's a dialect for medical terminology. Now,
> you have messages from people that contain "my doctor said I have..."
> or "my doctor told me..." which could be used like a switch to jump
> INTO another dialect (like INTO being used with sub-blocks). In this
> case, you jump from your main messaging dialect to the medical
> dialect; maybe even try a list of alternate dialects.
Yes establishing a useful context for the data is critical. If we were to
parse this information in REBOL we would possibly need a system that could
switch in
dialect interpreters as required. Of course then we need to know
*what* to switch in.
Yes, perhaps our alternative dialects select themselves via relevance
(validation) process.
> Where messages go, and how they are used, will also vary widely. There
> will likely be cases where a message header will contain metadata that
> will help tell processors what to do, or what can be done,
> with them. Think how things like JINI and WSDL are used as an example.
I'm not really familiar with either of those two technologies, though I
suspect wsdl is a resource discovery system. A message header is just data
for a "higher up" context so I see the processing of metadata as the same
issue just moved 1 level. E.g in your description above "my doctor said I
have" is metadata for whatever followed but is data at the same level as
whatever preceeded that phrase. Such thoughts can lead quickly to confusion
as I try to refocus attention on the levels of meaning. :^)
> 2) The dialect/action combination is a many to many relationship.
> We may want to replace the actions behind a dialect, but we may *also*
> want to put a different dialect over basically the same set of
> actions, or at least achieve the same end result (e.g. parse the data
> for values, build up a record, put it in a DB).
I can certainly understand replacing the actions behind a dialect, but if we
were to put a different dialect over the same set of actions would it be
better to call the set of actions a library or module or api?
> 3) If you've looked at the "programming by example" paradigm, imagine
> designing dialects by using example text.
Yes I've tried. Unfortunately the amazing number of unlimited possibilities
is somewhat of a block. I found, for me, it was more practical to reflect on
VID then try things out. Then reflect on VID again and my attempt and try
more things out. But now I'd rather pick up a template to fill in - but no
one seems to have one.
> PARSE itself is amazing, but imagine what we can build on top of it!
I am, thats the problem, my imagination far exceeds my ability and my
current reality!
Regards,
Brett.
[19/21] from: g:santilli:tiscalinet:it at: 3-Apr-2003 9:47
Hi Brett,
On Thursday, April 3, 2003, 8:54:48 AM, you wrote:
BH> I'm not looking for a general way to mix any two dialects, I'm looking for a
BH> more general way to design dialects so that they can be easily mixed.
That's why I suggested the "values" layer. Whether this is done
using something like "custom types" or just objects, once you have
it you just need, in one dialect, to get the values outputted by
the other dialect and process them. This, as opposed to studying
the parser for the other dialect and replacing anything you find
in parens. :-)
Regards,
Gabriele.
--
Gabriele Santilli <[g--santilli--tiscalinet--it]> -- REBOL Programmer
Amigan -- AGI L'Aquila -- REB: http://web.tiscali.it/rebol/index.r
[20/21] from: brett:codeconscious at: 3-Apr-2003 18:23
> BH> I'm not looking for a general way to mix any two dialects, I'm looking
for a
> BH> more general way to design dialects so that they can be easily mixed.
> That's why I suggested the "values" layer. Whether this is done
<<quoted lines omitted: 3>>
> the parser for the other dialect and replacing anything you find
> in parens. :-)
?! :^)
So maybe you are focussing at the values layer and I'm focussing and the
language layer. I totally accept that a values layer will be part of any
implementation, I used the something of the approach some time ago
(.../rebkit/tmd* on ios dev), but I don't feel it is enough by itself.
Now where is my discounted cash flow custom type ?! ;^)
Regards,
Brett.
[21/21] from: greggirwin:mindspring at: 3-Apr-2003 13:15
Hi Brett,
BH> Yes establishing a useful context for the data is critical. If we were to
BH> parse this information in REBOL we would possibly need a system that could
BH> "switch in" dialect interpreters as required. Of course then we need to know
BH> *what* to switch in.
Right, which is where REBOL saves us again. These dialects can be
passed around and shared as data. Now, maybe we create a
dialect-interchange dialect that various processes can use, so the
header/meta part of a dialect is loaded by the main processor and that
gives him the clues to look for about when to apply that dialect. I'm
not sure, though, how you'd handle things like a "confidence" rating
of how well something parsed versus just pass/fail.
BH> I can certainly understand replacing the actions behind a dialect, but if we
BH> were to put a different dialect over the same set of actions would it be
BH> better to call the set of actions a library or module or api?
Probably so. The dialect is just a friendly interface to some
underlying functionality.
>> PARSE itself is amazing, but imagine what we can build on top of it!
BH> I am, thats the problem, my imagination far exceeds my ability and my
BH> current reality!
Me too. :\
-- Gregg
Notes
- Quoted lines have been omitted from some messages.
View the message alone to see the lines that have been omitted