Smalltalk syntax can rule them all

Some time ago I read an interesting blog-entry by Michael Lucas-Smith
on his blog at:

http://www.cincomsmalltalk.com/userb...511#3392796511


I did leave a response, but that has not been included in the comments
section so far. So here, for what it's worth, is my input, about whether
we should write inline-SQL in Smalltalk, and what could be the
alternatives... I'll be happy to see any responses posted on this forum.
Here goes:


One reason not to write SQL inline in Smalltalk-code is the well-known
"impedance mismatch" between relational and OO data-models. I'd rather
describe my search-conditions as (Smalltalk) blocks than SQL. I'd
rather have some hidden encapsulated layer that does the mapping from
Smalltalk to SQL for me. I'd rather not create a dependency in my code
to a specific data-representation scheme used by a specific relational
database.

Instead I'd argue that Smalltalk(-like syntax) really is the one syntax
to rule them all!

To explain why I believe this, would take more space than can be
possibly used here. But for those who are interested, the path to
explore is actually Groovy's "builder-syntax" - which is really based on
the block-closure syntax of Smalltalk. Why is this important? Because it
gives us a natural programmatic way of dynamically writing "XML-like"
structures in Smalltalk, or Groovy. This combines the best of two
worlds: programmatic control of dynamical execution, and hierarchical
representation of recursive data-structures - which can then later be
*interpreted* as anything we want: XML, HTML, XSL, SQL etc.


-Panu Viljamaa

> Instead I'd argue that Smalltalk(-like syntax) really is the one syntax to
> rule them all!
>
> To explain why I believe this, would take more space than can be possibly
> used here. But for those who are interested, the path to explore is
> actually Groovy's "builder-syntax" - which is really based on the
> block-closure syntax of Smalltalk. Why is this important? Because it gives
> us a natural programmatic way of dynamically writing "XML-like" structures
> in Smalltalk, or Groovy. This combines the best of two worlds:
> programmatic control of dynamical execution, and hierarchical
> representation of recursive data-structures - which can then later be
> *interpreted* as anything we want: XML, HTML, XSL, SQL etc.

Look at Roe, by Avi.

On Jul 17, 9:13*am, "Malbs" <ssefl...@somewhere.com> wrote:
> > Instead I'd argue that Smalltalk(-like syntax) really is the one syntaxto
> > rule them all!
>
> > To explain why I believe this, would take more space than can be possibly
> > used here. But for those who are interested, the path to explore is
> > actually Groovy's "builder-syntax" - which is really based on the
> > block-closure syntax of Smalltalk. Why is this important? Because it gives
> > us a natural programmatic way of dynamically writing "XML-like" structures
> > in Smalltalk, or Groovy. This combines the best of two worlds:
> > programmatic control of dynamical execution, and hierarchical
> > representation of recursive data-structures - which can then later be
> > *interpreted* as anything we want: XML, HTML, XSL, SQL etc.
>
> Look at Roe, by Avi.

What is Roe ? Can you provide the link ?

Thank you.

>> Look at Roe, by Avi.
>
> What is Roe ? Can you provide the link ?
>


http://www.cincomsmalltalk.com/userb...try=3246121322

http://lists.squeakfoundation.org/pi...il/002851.html

http://map.squeak.org/package/81c025...1-15819cd25366

http://www.cincomsmalltalk.com/publi...E(Bundle).html

R
-

On Jul 17, 7:15*pm, Reinout Heeck <rein...@soops.nl> wrote:
> >> Look at Roe, by Avi.
>
> > What is Roe ? Can you provide the link ?
>
> http://www.cincomsmalltalk.com/userb...howComments=tr....
>
> http://lists.squeakfoundation.org/pi...4-April/002851...
>
> http://map.squeak.org/package/81c025...1-15819cd25366
>
> http://www.cincomsmalltalk.com/publi...E(Bundle).html
>
> R
> -

Thank you very much Sir.

There is already a product that allows one to describe search conditions,
etc. as st blocks, it is called Gemstone.

For reasons known only to the db companies, they have opted to stick with
tables and rows/columns.

Everything else is just a poor man's Gemstone.

--g

geoff a écrit :
> There is already a product that allows one to describe search conditions,
> etc. as st blocks, it is called Gemstone.

There is also something like Glorp which gives total SQL control over
very complex structures all within the Smalltalk syntacs.


@+Maarten

I looked at some of the links and it says
there's so far not much documentation. So
I would be glad if someone has the time to
give a bit of a description on this forum.

This design pattern may be developing as
we speak into multiple different directions.

I haven't looked at the groovy Builder source-
implementation yet because I think I know
approximately what is going on. I came up with
a similar idea some years ago. In Smalltalk-
syntax it means that rather than saying something
like

output := '<html><head>... </head><body> ... </body>' .

we can more simply say:

output :=
[HTML
addComponent: [HEAD ... ]
addComponent: [BODY ... ]
]


This pattern has the capability of
rendering JSP & ASP moot. There's no
longer any need to mix-and-match
procedural code with declarative
XML-like syntax. One syntax (of
Block-closures) is enough. One
Syntax to rule them all.


I know Seaside does something similar.
Replace the syntax that requires a closing
tag-name with one that simply requires closing
your block parenthesis.

I hope I'll be able to put my Smalltalk
implementation online at some point, but
at this time I would just encourage everybody
to explore this pattern of using (block-) closures
in this manner to make dynamically executing
lazy-evaluating code to represent expressions
in a language of completely different semantics.

The Groovy online docs mention that 'Builder'
is based on the Gang-of-4 -pattern with the same
name but at this point it seems to me they were
able to add something to it.


-Panu Viljamaa

> rather than saying something like
>
> output := '<html><head>... </head><body> ... </body>' .
>
> we can more simply say:
>
> * output :=
> * * *[HTML
> * * * * addComponent: [HEAD ... *]
> * * * * *addComponent: [BODY ... *]
> * * *]

this is more or less how you describe pages in seaside, actually.

Paolo

On Jul 21, 1:20 am, paolo.bonz...@gmail.com wrote:
> > rather than saying something like
>
> > output := '<html><head>... </head><body> ... </body>' .
>
> > we can more simply say:
>
> > output :=
> > [HTML
> > addComponent: [HEAD ... ]
> > addComponent: [BODY ... ]
> > ]
>
> this is more or less how you describe pages in seaside, actually.
>
> Paolo

How are nested elements handled?
<body>...<OL>...<LI>item <EM>one</EM>...</OL>...</body>

ed