created in the future in
their place.
Meanwhile, the above GitHub org or its projects can be followed, and I can still
be directly reached at dar...@darrenduncan.net indefinitely.
Thank you.
-- Darren Duncan
___
muldis-db-users mailing list
This is a test.
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
includes a lot of Low_Level
routines needed for a normal language but not for a "get something running"
release. Then other projects in the ecosystem such as ports to other languages
or other / eg SQL backends.
Until then or afterwards, you can follow some of my progress on Github.
Than
As to my actual implementation of the Muldis D language as a language, as the
Muldis::D::RefEng Perl module initially, I'll have that out as soon as I can, later.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darren
ctions, and so users can more easily define a
variety of concurrency behaviors or isolation levels etc).
The above places have some significant chunks but most of the important stuff is
still missing, hopefully to be filled in during the next few weeks. My next
intended area of focus is
FYI,
Since mid-2008 I've had a GitHub account which served as my public repository
for Muldis database projects.
The original account was username "muldis" and account name "Darren Duncan", and
such personal accounts were the only kinds available at the time.
More
nd to make announcements too frequently, probably not more than once
per 1-2 months, depending on when there have been significant improvements or
you can run something.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrendunca
#x27;ll
have all the relation and tuple types and relational operators etc, but the
tuples and relations will be in-memory values in the same way as integers and
strings and arrays in typical languages. The persistence is largely orthogonal
to this anyway, and I'll be adding that in th
mpiler for the first time,
after which the former would then be able to compile itself from then on.
I don't know if any database-centric language has done this before,
bootstrapping, but if not, then this may be an innovation for the industry.
-- Darren Duncan
P.S. Despite being boot
h the same 4 letters.
Note that Muldis D provides symbolic infix notation to select interval values
and so neither keyword would actually be used there; rather it would mainly be
used in defining types or declaring the types of things or in descriptions.
So, should I stay with "interv
ational projects, themselves independently useful, and can move on.
I am sharing these design ideas with the best academic or open source intent, so
you can benefit from them in projects you might make before mine gets going.
And so please give me appropriate credit, should you adapt any of these ideas
either because you learned them from me or because you consider them novel.
Thank you.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
Darren Duncan wrote:
For a loose DBI-alike example:
use FooDB;
my $dbms = FooDB->select(); # the DBMS is a singleton
my $sth = $dbms->prepare(); # also "connect" with
query code
$sth->execute();
...
From an initial response, I see that this
are no longer in use as an API feature. Another benefit is that Perl 5 programs
that prefer to run leaner and otherwise not use Moose can then use MDRE more
easily. To be clear, I won't be replacing Moose with any other sugar module;
any external d
ad : Boolean
{ go_ahead := foo < bar and baz != 'quux' }
if go_ahead then doit() else dont()
More change details can be found in the Changes file.
Many other similarly large or significant language design changes are pending,
to make the language
Good day. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
o separate routines. After this change, writing code will be an
experience more like in other languages which don't have the seemingly-arbitrary
restrictions that I have prior to the consolidation.
I won't declare further evolution plans now, but bring them up as they happen or
become imminen
" and "N*N^N"
formats/expressions where N is any of the prior 5 numeric formats.
That should keep things a bit simpler.
If anyone actually needs more they can instead make a case for addition and/or
define a user function.
-- Darren Duncan
__
Jonathan Leffler wrote [on the TTM list]:
On Tue, Nov 16, 2010 at 12:34, Darren Duncan wrote:
One of the oldest-defined features of Muldis D, intentionally
supported from the beginning, is the idea of trying to be
radix-independent; so you could write all of your numerics in any
h 2a and 1.
So what do you think or is there another option you care to mention.
No matter what, I plan to keep the 5 N, O[bodx]N options. And 0N will never be
supported to mean octal, even if it is well known, because its a bug magnet.
-- Darren Duncan
_
in particular?
Note that all of the above, for bases 2,4,8,16 anyway, applies to blob literals
also.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
laring things that has precedents.
Thank you in advance for any further feedback.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
ace but
rather says how to interpret what comes after the "cube".
I'm currently on the fence and probably wouldn't make the change barring more
advantages to doing so.
Thank you in advance for any feedback.
-- Darren Duncan
_
r to moving to implementation. Some are in the TODO file
and many aren't, to keep it from growing too large. When I have more time I'll
get to specifying those. One of the first items is expected to be externalizing
most of the details of character data types from the language core, such as
everything related to Unicode, similarly to how I externalized nearly all dates
and times details, so the core is more pure and lacks such immense and
time-variant complexities.
Good day. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
the
glossary. I have yet to discover whether any other parts of the book have mentions.
I feel honored that this has happened. And its another degree of reputation.
The publication date is 2010 July, but I mention this today because today is
when I received my copy, and discovered the
---+---+-
Assignment | non | := :=++ :=-- :=foo
I am actually satisfied with this arrangement, and so will put off any attempts
to split levels until after I've made some other language changes, such as those
concerning par
on the argument
side.
My current plan is to apply the ideas in this email prior to the ones I
mentioned before, concerning meta-operators.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
Terrence Brannon wrote [to mdb-users]:
On Sat, Jul 31, 2010 at 5:57 PM, Darren Duncan wrote:
The primary reason for this change is to let user code be simpler,
because for the majority of the times when they just want to have 2
arguments for a function, they can supply them directly
des the same hyper-meta functionality. But this alternate hyper-operator
type syntax may be useful for sets/arrays/bags, if not relations in general.
See http://github.com/muldis/Muldis-D/commit/460f936 for my ramblings on these
plans as TODO file items; some of this I've reworded in this email.
Feedback on this plan is welcome, but not required.
Thank you. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
an Acmeist project and he
has added it to the projects list page. I also added a sentence to the Muldis D
spec (and the intro page) declaring the same:
http://github.com/muldis/Muldis-D/commit/10ecacf .
You may know of other projects that could be appropriate to
oking at
them as to how these naturally fell out.
After this, I would be more hard-pressed to consolidate further.
Feedback still appreciated, as previously mentioned!
-- Darren Duncan
PTMD_STD has 17 precedence levels when the C
pragma is C; if it is C instead, then 13.5
of the l
ous fixes, such as combining levels that don't need to be
separate, or splitting or reordering etc. The 4 small groups I consider
rigorous and not in any need of changes, though feedback is still welcome.
Thank you. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
programming convention, and
everything else with "implies".
5. Any other correctness or cleanup feedback is appreciated, including better
names for the levels if any.
Thank you in advance.
-- Darren Duncan
==
=head1 NESTING PRECEDENCE RULES
This documentation section
ts
argument is now optional. So, for examples, you can now say "!is_foo" or
"#people" or "%relvar" and not have to be "# people"/etc. This change is a
stopgap measure and later a more generic solution should be found for making
whitespace optional around o
Darren Duncan wrote:
Note that SQL's "in" I believe corresponds to the T/R version if I'm not
mistaken.
Er, actually, that doesn't matter because usually SQL's "in" is used in a where
clause, and hence the canonical way to do what we want in Muldi
L's "in" I believe corresponds to the T/R version if I'm not
mistaken.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
{;...}", the ".{}" (Just) was renamed to ".{*}", and any other
renames simply removed the sigils, such as "group", "cmpl_group", "ungroup", etc.
5. Renamed the ASCII variants of all 8 dyadic
Sam Vilain wrote:
On Thu, 2010-07-15 at 17:21 -0700, Darren Duncan wrote:
To follow-up,
Considering the feedback I got on the TTM list, my current proposal is to use
this new mapping
means "proper subset" or "subset or equal
to", and so the symbolic version should be easier for people to disambiguate.
So, barring any argument to do differently, the above is what I've decided on.
Thank you. -- Darren Duncan
_
, whatever is done with the infix syntax, users always have the option
as well to use standard function call syntax for all of the same operators, such
as "is_subset( x, y )" for "x ⊆ y" or "x sub y" for example.
-- Darren Duncan
_
:4{}a blob2, 2 bits per column
:8{5235 0437 6} a blob3, 3 bits per column
:16{A705E} a blob4, 4 bits per column
Whitespace and underscores are allowed but ignored.
This Perl 6 update is reflected in version 0.134.0 of my HDMD_
re now identical to the format used in
maths and maybe some programming languages.
I also intend soon to change the syntax for how non-base-10 numeric literals or
Unicode codepoint numbers or blob literals are written; this update didn't make
it for 0.133.0, but in the form of a new TODO file item.
Good day. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
stand?
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
addition to the older
syntax, which is staying unchanged, so users have a choice, what do you think
about these proposed changes? Should I alter anything about the plan?
Which syntax would you rather use, personally, the abbreviated version or the
more descriptive version? Or if both, which types' literals would you prefer to
spell out with the explicit "Type" and which would you prefer not to?
Note that these shorthands may very likely only be available in the PTMD_STD
dialects (which all above examples are in) and none in the 2 HDMD_Perl dialects.
Thank you in advance for your feedback.
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
',",`,#]; the first 2 are for Text and Name literals, respectively,
and the last 2 are for Comments.
I may consider further changes to matters of character escaping.
Good day. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
5.12.x.
Both versions would, of course, use the same database file formats.
Also of course, the Perl 5 version is the more important one in the near term
since that is still by far the most heavily used application language.
So that is my current
as possible) tested in isolation from any large complex
dependencies that a typical DBMS would be. Sort of like how SQLite can be used
except that MREE has all the features which SQLite lacks but big DBMSs have.
Any thoughts on anything here?
[]
-- Darren Duncan
_
NULL AND col2 != 42
col2 = Nothing # col2 IS NULL #
col2 != Nothing# col2 IS NOT NULL #
--
Good day. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
e a translation layer for the Postgres DBMS so that
you can use Muldis D to write anything you currently write in SQL or PL/pgSQL.
Collaboration is always appreciated.
Good day. -- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
ty string, and so on.
A "$>foo" is meant to be a mnemonic shorthand for a "foo => $foo",
and hence ">foo" is short for "foo => foo". It is analogous to the
":$foo" of Perl 6 being shor
nd the $ look more odd there.
So my current thought is to change PTMD_STD to drop the $ sigil, but I'm going
to wait a little while before doing so, leaving things unchanged for now, while
I think it over.
Further feedback on the matter, specifically along the lines of which single
fo
tituting a different dialect name for PTMD_STD, maybe PTMD_NS_STD or
something, so they are more clearly separate? The PTMD_NS_STD spec would be a
small delta document.
Terrence Brannon wrote:
On Thu, Jun 17, 2010 at 2:44 PM, Darren Duncan wrote:
I wanted to let you know that I plan ASAP
t;-- $baz : Baz, $quux : Quux) {...}
... vs:
function foo (Bar <-- baz : Baz, quux : Quux) {...}
-- Darren Duncan
___
muldis-db-users mailing list
muldis-db-users@mm.darrenduncan.net
http://mm.darrenduncan.net/mailman/listinfo/muldis-db-users
owever, since all entity
names can be delimited with double-quotes (like in SQL), users can quote any
otherwise-bareword names to clarify that they are not keywords, in the
appropriate circumstances; so `foo`, `$foo`, `"foo"`, `$"foo"` all refer to the
variable/etc named "fo
53 matches
Mail list logo
